
Hi, I'm Kelly Waters, author of the popular blog,
All About Agile. I've agreed with Artem to guest over here at ASD and be a regular contributor - this is my first post...
I've been doing agile development for quite a few years now, and seen many benefits. But one of the most remarkable things of all, is how so many teams can quickly get good at predicting what they can deliver, and deliver on time, even if they were hopeless at estimating before!
For decades, delivering on time has been the holy grail of software development. So this, for me, is one of the most compelling reasons to do agile development. Here is the secret to consistently delivering on time:
- 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.
- Commit as a team.
Like most great things in life, it's actually very simple. That's really the beauty of it. It seems a bit abstract, so many people might be retiscent to give it a try. I would urge you to try it.
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.
Bookmark/Search this post with:
Comments
I don't understand the
August 20, 2009 by Giorgio Sironi (not verified), 2 years 23 weeks ago
Comment id: 2997
I don't understand the Fibonacci thing. The sequence of numbers tends to a fixed ratio between one number and the next, so you'd better use simply 1,2,4,8,16...
Fibonacci
August 20, 2009 by Kelly Waters (not verified), 2 years 23 weeks ago
Comment id: 2999
Each number in the Fibonacci sequence is the sum of the previous two, ie 1,2,3,5,8,13,21...
Kelly.
Velocity
August 22, 2009 by Channing Walton (not verified), 2 years 23 weeks ago
Comment id: 3038
I agree completely although I have found that the term "velocity" often has managers looking for an accelerator. Instead, I use "capacity" which seems to enable people to see the number in terms of what the wider team is capable of producing. Discussions about increasing capacity seem to be more holistic and reasoned rather than just looking at developers. It shouldn't make a difference but it seems to.
Post new comment