Estimation in agile teams
Benefits of estimation
- The act of estimating allows a team to discuss, plan and understand upcoming features they will work on
- Estimations can give a customer an idea when a feature will be available
- Estimations can help break work down, and fit it into the next sprint. A record of this can inform a measure of the team’s velocity (the amount of completed work the team is producing each sprint). Knowing the velocity can allow the team to create a release plan as well as identify productivity peaks and troughs.
Estimating in points or in hours
If you estimate how long a feature will take to complete in hours or days, from some perspectives (even in your own subconscious) you’ve promised to deliver the feature within that time — rather than it being an educated guess of how long it will take to complete.
People are generally bad at estimating how much time a piece of work will take to complete, but are better at estimating a feature’s difficulty relative to work the team has completed before.
Much of the work in an agile team would involve multiple skill-sets collaborating (e.g. Developers, Testers and Designers all working to complete one feature). Estimating the days for each skill required will be complicated, and provide no added value over a relative size based estimate.
By giving the feature’s estimate a relative points total (using a technique such as planning poker), there is less temptation to rush a half-baked solution within the perceived deadline, nor are any people going to be able to complain that a promise to deliver within a number of days has not been kept.
This points total is best kept to a member of the Fibonacci sequence, lest it become a shorthand for days. The more complex the feature, the less likely the estimate will be accurate, so a sequence with bigger gaps will prevent conversations about one or two points difference for a large task.
Some teams use T-Shirt sizing (S, M,L , XL, XXL) instead of numbered points, which is a good way to introduce estimation with a lower learning curve, and this avoids introducing too many concepts at once when a team is starting a new practice.
Estimation fitting into sprints
Estimates of relative size can help the team decide what features to include in a sprint, based on how much was achieved in previous sprints. The team must commit to delivering that entire sprint of features in the next two weeks, otherwise you are not actually giving an estimate of the work that can be completed in that time — rather just a glorified task list of what to work on next.
Estimating a whole sprint’s work compensates for some tasks being more difficult than first thought, and some easier — a few estimates will be wildly wrong for reasons unknown until the work starts.
A team may not complete all features in a sprint, but if the amount of work estimated to be finished in each sprint is regularly too much, then the abilities to forecast future sprints and have a release plan diminish. Customers will lose faith in the team if they are promised work in sprints that regularly fails to be completed, and may lose faith in the agile approach as a result.
Disruption to estimates
When estimating as a team, any team personnel changes can make estimation more difficult or less useful.
Ideally the team members would remain fixed, but this is rarely the case in the real world. Changes within the team will mean that this new team may be able to complete more or less work within a sprint. Different specialities or experience may mean previous estimates are no longer relevant. Bringing new people into the team will have an initial drain on productivity as they are helped to gain tacit knowledge from the existing team members.
In a team with frequent personnel changes, or one that is rapidly expanding, estimations as a team would not be useful, and another approach would need to be considered. It’s questionable that any sort of estimation would be appropriate for these sorts of volatile teams.
No estimation
If you are not working in sprints of fixed length, or you do not need to inform customers when a feature will be completed, then it’s arguable that estimation is not worth the effort for your team. Without estimation, planning time can be spent on something more beneficial for the team. There are plenty of successful agile teams that do not estimate their work.
Above all, your estimates will likely be wrong
One of the theories that brought the agile manifesto into being was that teams are unable to accurately estimate how long work will take. The team learns this by doing the work. I’ve never known a team that were able to estimate features at the start of a project, they needed to start working in the problem domain and gain experience before estimates improved, and even then estimates would often be wrong.
Spending a lot of time and effort on estimating is rarely worthwhile. Spending more time on estimation techniques will not increase the likelihood of your estimates being more correct, but might make the process easier.
As with many of the agile practices, there is a balance to be struck with accentuating the practices that can have the most impact on productivity, and minimising the practices which have their place but are unlikely to make big team improvements, it’s up to those in the team to see what importance estimation can have for them.
