I've always loved Joel Spolsky's common sense approach to the software development lifecycle, and his latest article on evidence based scheduling is no exception. It has a realistic approach to quantifying unpredictable elements of team development such as interruptions, meetings and the odd rebuild of your development environment. Estimating is always a big problem, and most developers (including myself) are usually quite optimistic about how long it will take for them to write a particular piece of code. This leads to an un-ending conflict between managers who want to know when something will be delivered, or how much a feature will cost to create. I think Joel offers a real practical approach to this dilema, and I am now trying to think of ways to integrate some of these ideas into a TFS project template.
The only thing i don't think Joel covered is how to go about predicting for the very first iteration, the very first time you start using EBS. I think that you probably need to pick a number or range of numbers to seed your velocity history. You probably need to be a bit pessimistic to begin with, but by the next iteration you'll have some better numbers to work with.
Subscribe to:
Post Comments (Atom)
Posts
Joel recommended to start with the worst historical data, i.e. with randomly picked velocities. They will result in a very inaccurate prediction of the ship date in the first iteration, as you dont know how good your estimates are. If you have some historical data on your developers velocity, you should put that numbers in of cause.
ReplyDeleteNevertheless i just had that same idea to put the EBS idea into some piece of software to use it with a TFS. It should be not much more than adding the fields for timetracking to the workitem-template and write some reports :)