Agile Estimating: The Secret To Delivering On Time
by Kelly Waters
For decades, delivering on time has been the holy grail of software development.I've been doing agile software development for quite a few years now. I've seen many benefits, but one of the most remarkable things of all, is how so many teams can quickly get good at delivering on time.
It's the art - and/or science - of predicting what can be delivered in a given timeframe, even if the same team was hopeless at estimating before!
This, for me, is one of the most compelling reasons to do agile development. Here is the secret:
- Estimate features, rather than tasks.
- Keep your estimates high-level intuitive guesses (don't analyse the details).
- Estimate in points to indicate the relative size of each feature.
- Consider estimating using a number sequence like Fibonacci. Fibonacci numbers get less precise as they get bigger, which builds a natural distribution curve into your estimates.
- Estimate as a team. Consider playing Planning Poker to facilitate this.
- At the end of your Sprint (or iteration), score the points for all features you managed to deliver. Only score points for features 100% complete, tested and potentially shippable. This is your Velocity. Count zero for incomplete features.
- Track your Velocity over time on a graph. You can also track your Reliability, i.e. the number of points delivered as a percentage of the number of points committed to at the start of the Sprint.
- At the start of each Sprint, look back at your Velocity for recent Sprints to decide how much to commit to for the coming Sprint.
- Don't try to reconcile points with hours or days.
- Commit as a team.
You'll need to give it several Sprints before you pass judgement on it. You will find your Velocity bounces all over the place for the first 3-4 Sprints. But then it will settle down, as your team discovers its norm.
Trust me, it works. I have seen it work in many different teams, time and time again. It's a statistical approach to estimating. And statistically, if you estimate with relativity, everything is average in the end.
Kelly.
Originally published on agilesoftwaredevelopment.com
2 September 2009 18:57
Good post Kelly. People could do worse than spending £7.70 in the DSDM Atern Estimating Pocketbook - http://www.dsdm.org/webshop/details.asp?prodid=book07&cat=1
2 September 2009 19:20
Completely agree. The only difference is that I normally like the checkpoint to be relatively short rather than a looser definition of a "sprint". Since I am in a businss of being more deterministic, I also rate features in high, medium and low to allow for re-prioritization based on velocity to be built into the plan. One more thing is I correlate velocity and points with defect reports to confirm "shippability" and coveage on committed features for larger sized projcts.
3 September 2009 03:58
Pivotal Tracker has all of the above, even Fibonacci scale:
http:://www.pivotaltracker.com
4 September 2009 17:53
I agree with the approach and do agree it will work if we give enough sprints to establish the team's velocity. One of the challenges I face is that we don't have those few sprints before committing.. the team is formed with a timeline in mind and sometimes if we are lucky we get to play a bit with scope but, more often the timeline and general scope are fixed and we need to resort to some sort of detail estimation and planning to line them up. But, the sprints execution and tracking velocity ultimately helps us in being more proactive and determining if we can make it or need to adjust one of the three - scope, people, timeline along the way
5 September 2009 20:49
Good post Kelly - This is good advice on delivering sprinted work on time.
Would be interesting to hear your thoughts on keeping a project on track.
In fact you've inspired me to write a post over at www.testertroubles.com
30 September 2009 09:46
Good article, I have some questions though on your first item in the list.
"Estimate features, rather than tasks."
Developers must then break the feature into tasks because a feature can be huge in scope and could takes several months to complete. Estimating a feature that is big is hard, that's why it's divided into tasks in the first place. Stuff like upgrading your development environment or changing the basic data access layers are not something that can be measured in weeks.
3 March 2010 08:30
The reason it is better to estimate features rather than tasks is that you don't normally know what the tasks are until you are part way through implementing the feature. The number of features in a project tend to stay much more consistent than the number of tasks - so it is better to extrapolate against them.