I sometimes hear people talk about how to do better estimates.
This often happens when the velocity for a team is going down and sometimes when it is going up too and when the estimated and actual velocity is much different.
Teams in these situations often seem to feel they have failed at estimating and thinks they should try to do a better job estimating.
In my view this stems from a misunderstanding of the purpose of agile estimating.
I believe as many others, that estimates are always wrong, especially if you try to make them in actual time rather than relative size.
But even if you make them in relative size (story points) they are never anything more than guesses.
And with velocity tracking this is not a problem. There is really no big win in trying to "improve" your estimates.
The purpose of velocity tracking is to automatically correct the inherent error in estimates.
So let the automation built into the process work.
Suppose your team actually could get real accurate estimates.
Then your team would be able to pick the right amount of work for each sprint, and have a stable velocity.
But then you can get this situation as easy with ordinary inaccurate estimates too, as long as the team makes about the same size of estimation error every time.
Which they usually will given the same team members and a well-known problem domain.
So what should we do then when actual velocity starts to differ much from estimated velocity, is that not a sign of that the team is doing a worse estimation job?
Not in my view. Yes the estimates are apparently more inaccurate, but what is the reason for that ?
That is good information!
The reason could be some of the following:
- There is a new problem domain which the team is not used to
- The team has got new members
- The team has lost members
- The team have moved or changed their physical environment
- The team have started with some new practice
- The team have stopped doing some practice
- The team have got a new product owner
- The team has grown tighter
- The team has lost its energy
- etc etc…
If you during a retrospective can try to find out why your estimated and actual velocity have started to differ you have good information to improve your effiency as a team and in the long run get more productive (not necessary higher velocity).
Just don’t try to estimate better.
And furthermore, don’t be *sorry* if your actual and estimated velocity differ! It is natural that it happens, and will happen to most teams in a changing world.
I would be more worried if I were in a team with constantly stable velocity.
That would to me be a warning sign of stagnation.
And if you really want higher velocity, just start multiply your estimates with any high number. In that way you can get as high velocity as you want.
Why you now would want that ? 🙂
Any good insight in this post I attribute to Mike Cohn.
He have taught me so much through his books "Agile Estimating and Planning" and "User Stories Applied" and his seminars.
His teaching has been one of the most influental for me.
Find out more at his site: www.mountaingoatsoftware.com
