We asked our Agile Coaches:
"Why do we estimate in Agile?"
And they answered:
Eva:
It is not mandatory to estimate in an agile environment, but it is done in almost every project I was part of. My TOP 5 arguments why we estimate:
- get a common understanding within the Scrum Team, especially within the Dev team, about the work which needs to be done
- create a common understanding and alignment of how we in the team evaluate risks, effort, uncertainties
- get insights about how clear the requirement is (e.g. very high estimation --> a lot of open questions, big risks, uncertainties; more “exact” estimations --> more concrete plan about the requirement, maybe we already know what and how to do something in detail)
- be able to compare different requirements with each other and set them in relation (relative and absolute estimations)
- get information about our team performance to gain new insights and foster learning within the Scrum team (data not for management, more for team learning)
Franziska:
- Estimations are helpful to keep the Dev Team aligned and avoid misunderstandings or individual assumptions not being shared with the Dev Team. There are all kinds of ways how to estimate (T-shirt sizes, Story Points, Animals,…). But what I really like about Planning Poker is that the Dev Team gets an impression of whether they are on the same page or not at the very moment when the estimations are being revealed. In case estimations differ it clearly points out that the Dev Team needs more time for discussion.
- Estimations are helpful to discover the readiness of a story. From a Product Owner's point of view, the estimations help to gain insights if the User Stories were really in status “Ready for Refinement”, meaning clear and refined enough. Very high estimations are typically an indication that the User Story needs to be refined even further, perhaps be split as it might entail too many uncertainties or risks.
- Estimations are not a control tool to compare different teams with each other as every team has its own estimations and references. Especially no management tool or contractual element that is legally binding or being used to control the Dev Team.
- Estimations are not set in stone and can change if the environment, circumstances, or complexity changes. It is not a prediction of the uncertain future, just the best guess from what we know at the moment. Thus it should be avoided that “old” estimations are never being touched again, if changes occur that affect the estimation then they should be taken into consideration and new estimations needs to be made.
Christian:
First of all, the shared understanding from a proper refinement is the most important outcome while the corresponding estimation is more like an easy by-product to validate this point has already been reached. Once present, estimations can be useful to help us figure out how much we can fit into a Sprint, how long a certain task should take, or - most importantly - to get a rough forecast for mid-term and long-term release planning. As a Scrum Master, I always follow the rule to make estimations more abstract or even remove them from the process if they were being used to put pressure on the team or - even worse - on individuals to avoid this destructive misuse.
Tobias:
There is nothing in the Manifesto for Agile Software Development requiring you to estimate. So consequently not all frameworks and methodologies require you to estimate. There is even a whole zero-estimates movement. (As a further note: The 2020 version of the Scrum guide also no longer explicitly mandates Product Backlog Items to be estimated.)
So like with all additional practices you should always ask yourself what problem you are trying to address and if estimates are really the best solution to solve the issue.
Common uses:
- get an estimate on what amount of work could be finished in the next few weeks (do not extrapolate beyond that based on the estimates)
- Do all members of a group think similarly about the amount of work needed to implement something?
- Compare different solutions to find the one that can be implemented sooner
Marco:
Estimation helps to understand the next steps of the complex product development. Estimated work packages help to plan the next steps (f.e. Sprint). But that is just the result of the estimation. The estimation itself as a process is very useful. If the estimation is discussed within the team it fosters a discussion within the team that increases the understanding of the working item and result in a better product. A backlog with estimated items helps the Product Owner to order it and decide which item is useful for the next product development step.
Jakob:
Estimations are a tool. They help on the way to create a shared understanding of the work to be done. This is broken down into smaller parts, that create increments of value. These stories are discussed / refined until it’s clear what needs to get delivered.
In the estimations, you share your guesses about the complexity of these stories and what needs to be done. This process serves you as a feedback loop within the team. Do we all have the same understanding of the problem, its complexity, and the work that needs to be done? It shows risks and uncertainties. It reduces the number of unknown unknowns.
It also helps with the planning, it provides additional input for answering the questions: Is it worth the effort? When should we do it? Now? Never?
Numbers are not the goal of the estimations! Estimations are no predictions of the future and no commitment on how long it’s gonna take.
Use estimations as a way of learning. Start it as a discussion, try simple tools and see how it’s helping you. Look back on how you estimated and how it turned out in the implementation. Use this feedback to keep improving on your estimations.
Amir:
I'm neither for nor against them. As stated by my colleagues, it's a tool. That you need or don't need, depending on the team. But the entire team; the PO and the Devs and the SM. It's entirely up to the team how they use it and for what they use it, every instance of a Team can use it and will use it differently - just as with every other aspect of Agile and Scrum.
The only issue I have with it is when it becomes corporate when it bleeds outside of the Team when it becomes a billing method or it becomes a measure like a KPI. This should never be done and it's counter-intuitive, there are better things than estimations for those.
Find what you need estimations for, if you need them at all, in the plethora of examples and options online.
Whether for aligning, for risk, for effort, or just for "shirts and giggles".
About #AgileSeven: We ask every month our Agile Coaches and will publish on the 7th of each month their answers. Why 7? It is a magic number.