Agile Estimation: All Your Questions Answered
I’ve had a few people asking questions about estimation when doing agile software development so I decided I would write down some ideas in the hope that others may find it helpful.
Why?
Firstly, there are many who argue that estimation is not a good practice to apply in software development since it often doesn’t end up affecting prioritisation, moves the focus away from iteration, and is essentially guesswork applied to unpredictable and non-repetitive work and more. The key point is that not only does estimation not offer a good return on investment but that by doing it, the team shifts the focus away from better practices. Therefore, the very first question to ask is, “should we actually be estimating?”
Although the answer to this question may often be “no”, the perceived need for it may be too high in your organisation to not do it, or simply not a battle that you want to fight. If you do decide to use estimation, the key is to ensure the process is as valuable as possible. To understand that, let’s examine what parts of estimation are less valuable or not valuable at all.
- Not valuable: time spent estimating things that never get done. Time spent estimating things that are less likely to get done (a long way in the future, or are extremely low priority) is wasteful.
- Not valuable: Time spent arguing about a number. There are some valuable parts of the estimation discussion, but the part where people are just debating about numbers, and not clarifying scope or understanding, is just wasteful.
Ok, but what is valuable?
- Valuable: Refining, clarifying and getting a common understanding of the scope of a piece of work (that is likely to be done).
- Valuable: Uncovering that a piece of work is too big and then splitting it up into smaller increments, each of which delivers customer or business value. “Too big” is something that gets refined over time, and initially starts at “bigger than one sprint” and slowly reduces to “small enough that we don’t have wild variation when implementing stories of that size” and ideally reduces to “all our stories are roughly the same size when we implement them”.
- Valuable: Providing sizing information that affects the priority of work, and hence what work can be deferred.
But what about other reasons? Well there are other reasons that people use to argue for estimation, but whether or not they add value is less clear:
- Debatable: Planning the timing of a roadmap or releases. Unfortunately doing this often shifts the focus away from iteration. That is, the more the business focuses on dates and deadlines of features, the less likely they are to iterate over those features (return to those features and refine them) as doing that affects future deadlines that have been set.
- Debatable: Determining how much should go in a sprint. Does this give us a lot? I’ve seen many places where teams just keep working and finish as much as they can in a sprint, regardless of how much they forecast could be done in the sprint. Also, ideas like Kanban don’t even have a timeboxed time.
Therefore if you decide to estimate, it is important to focus on the value-add parts of the process.
When?
So now, understanding what is valuable and not valuable about estimation, when do we actually estimate? Should we estimate things in the current sprint, things one sprint ahead, the whole backlog?
There is a general concept usually applied: “Boulders, rocks, pebbles”. The idea is that things that are a long way in the future (therefore less likely to be worked on), should be left as a boulder size estimate — a larger and unrefined estimate since you don’t want to spend much time on it. Things that are not as far in the future, should be estimated at rock sizes. And things that will be done (current sprint or so), should be well defined and understood, and hence estimated at the size of a pebble. Distant future work should not be refined to pebble level of estimates, and boulders shouldn’t be attempted in a current sprint because the work is unlikely to be clearly understood.
What?
So what should we estimate? Absolute metrics like duration or effort? Or relative estimates (tasks relative to other tasks)?
Generally, teams tend to be more successful with relative estimates because it can be done quicker than absolute estimates, people tend to be better at estimating relatively, and it is more team focussed. The example often given is if you have a group of people estimate the height of a building in metres, they will often be wildly off, but if you have them estimate the height of one building relative to another, they tend to be much more accurate.
So what are we actually estimating? It’s not just about the effort (or how long it will take), it’s a combination of complexity, risk (uncertainty) and effort. All of those need to be factored in when estimating. For example, if something is a very minor change, but may catastrophically break your system, it will require significant testing and planning, making it a high relative estimate.
For more information, have a look at this article by Mike Cohn and this article by Ryan Key.
Then there’s the measurement. Often this is done in “velocity”, which is the number of story points per sprint. It is one of those unfortunately named things in Agile. A better name for it is stability. The goal is to get that number to be as stable as possible. If you can get that number to be fairly constant, then you are better able to predict your work. It is not something that you want to try to increase or use to measure productivity or compare between teams.
How?
Prior to doing any relative estimation, a baseline needs to be established (what are we estimating relative to). Usually, that involves picking a story which is clearly defined and assigning it a 2, then picking another story, which is approximately 4 times the size of the first story, and assigning it an 8. Those two will be the baseline stories against which others are estimated.
One way to do the estimation is to use a technique called planning poker. This is where each person in the team will silently declare their estimate for a story, and then if everyone estimates the same or similar number move onto the next story. But if estimates differ between people, a discussion is had to help clarify the scope, before more silent estimation occurs.
Another way to estimate, which is particularly effective when there are a significant number of stories to estimate is to use Affinity Estimation. This is where the team tries to quickly group many stories into buckets all at once, rather than focusing on each story at a time.
Who?
The people involved in taking the work and implementing it. But who exactly is that? Does it include product managers, product designers, etc. That usually depends on your entry criteria or “Definition of Ready”. If your Definition of Ready states that a story must have its scope clearly defined, designs complete, and Acceptance Criteria written, then the estimate applies to just the developers, testers, etc who will take the story from that point to delivery (or whatever your “Definition of Done” is). If your Definition of Done does not include the design, then whoever is involved in iterating that design should be included in that estimation. Rarely should the Product Manager be involved in estimation. Their goal should be to provide as much clarification as needed for the rest of the team to estimate.
The other part of the who should do the estimation is the team that does the actual work. It is generally not useful to try to standardise across multiple teams. This tends to be very time consuming and usually slowly gets out of sync. Also, often each team will be doing different types of work in different contexts, which means there is little value to standardising between teams.
Conclusion
Firstly, consider If you should be estimating at all. If you do decide to estimate (or cannot win the argument not to estimate), focus on the value-adding aspects of estimation which is about helping clarify the scope of work, and splitting up work into smaller increments. Then focus on a short time horizon and use relative estimates to size those stories.
