To Estimate or Not to Estimate?
Very often I hear this question. The Agile community seems to be split when it comes to this question. Agilists around the world are eager to spend hours and hours debating and trying to defend one or another approach.
One thing which I have learned in my career is not to be dogmatic about anything. Usually, being pragmatic is the key to success in almost everything. And that is especially important here.
I will avoid talking about the definition, unluckily naming of Estimations, history, or how #noestimates movement was created.
Instead, I will just share with you a few of my learnings which I gained by practising both ways. Also, I have spent more than half of my career working as a Product Manager / Product Owner, which also brings one additional perspective when this question comes to my mind.
My Learnings:
1.) Estimations if used as commitment are very dangerous and harmful to any organization.
Probably every single agile practitioner who ever tried to do estimations knows how dangerous it could be. The purpose of estimations should not be to get the number! The purpose of estimations is not to predict or commit to anything! We are living in a complex world where is almost impossible to predict when something will be finished, especially if we are doing it for the first time and facing a lot of unknowns and things which we need to learn.
2.) In doing Estimations the most beneficial is the process of making them.
Yes! Aside from all Scrum events, which are opportunities to have conversations and share mutual agreements, estimations are one of the most powerful techniques for teams to empower collaboration. It is like opening the magical gate of collaboration, where every person in the team might easily share their thoughts, challenge each other’s and start sharing knowledge or ideas on how upcoming work might be tackled: it is 3… no it is 8! — Why you think it is 8? Because it is not that simple, you need to do that and that and… And very often after discussions like these some third idea might pop up.
3.) Estimation might serve as great early feedback if planned work is feasible at all or not.
It happens very often that the Product Owner/Stakeholders/Clients are expecting much more than the team can produce. In those situations, it is very important early to send the message that something is not doable at all, so that the Product Owner from one side could manage expectations, and from another reprioritize the “doable” work. This is especially applicable if the team is new or working in an early stage of product development, where there is no too much historical data (like throughput). And here, we are not talking about some precisely or time-consuming exercise. Usually just a high level — abstract estimation might be enough as learning what might be doable and what is definitely not possible.
4.) Estimation might serve as great protection for the team
If your team is frequently exposed to high pressure to deliver and they are struggling in doing so, or if they are lacking the focus to complete the work and working always on several topics that are constantly burning… then bringing some metrics might be a very strong argument to protect your team: if you are always expecting from us to deliver 20 apples, and we are able every sprint to deliver 6 and a half, there is no point… By protecting the team and giving them a little bit more space, the team might focus on learning important things like how to focus, optimizing the flow, addressing the technical debt, etc.
5.) #NoEstimates are good for optimizing the flow
If you are doing #NoEstimates then you need to find alternative ways to plan your projects, product developments, or releases. The teams are focusing on measuring how much value they are creating. By doing that they are learning to slice work into more equal and smaller pieces, they are learning to deliver more frequently, to be more predictable… It is a journey that requires the time, but definitely worth learning.
What is really important?
Both of these approaches have positive sides. Aside from my learnings, I am pretty sure in your path you might find out many other learnings for your team or organization. We should try not to judge what is better. If you ever come into the dilemma should you Estimate or #NoEstimate probably you should first ask your self:
- Why are we estimating?
- Which problem we are trying to solve with estimating?
- What is the next most important thing which we want to learn?
Summary
If you are questioning if Estimations are efficient in the way how your team is doing them now, or if you have just learned about #NoEstimates and questioning what is better for your team, I would definitely tell you that there are many ways to practice them both wrong. At the same time if you are doing them right there are so many learnings that your team might collect by following that path.
You should start by questioning your self 3 simple questions:
- Why are we estimating?
- Which problem are we trying to solve with estimating?
- What is the next important thing which we want to learn?
Try to reflect on your organization, observe the team dynamics, and understand what your team needs more at this point in time. What learning will be more beneficial?
References:
- More about #NoEstimates you can find online. This might be a good starting point: http://softwaredevelopmenttoday.com/noestimates/
- All drawings are made by the author (hope you like them:)
