Are your estimates really agile? 🔎

“How much time will this task take you?”, – asked one developer.
“About a couple of days, I think. If I don’t run into any problems…”, – said another.
“Ok, then it’s about 3 story points”,- concluded the team lead.

Have you ever heard this type of conversation before? Well, I definitely hear this a bit too often for my comfort.

Unfortunately, when teams start anew with Scrum (or any other Agile framework), they still think in the old terms. One of the more difficult ones to overcome is effort estimation in hours. It’s hard to stop thinking about mendays or peoplehours just because we’ve been using this type of estimation for so long.

The problem is that when we work in product development, there are too many unknowns for us to be able to estimate in absolute terms, such as hours.

As a Scrum Master it is your role to help everyone understand planning and estimation in an empirical environment, which means you need to teach them relative estimation.

The problem with estimation in hours

How long will it take you to eat an apple? 🍎

…

How sure are you of this estimate? Did you add a buffer?

The answer to this question depends on a multitude of variables: how big is the apple? do you need to cut it before eating? are you hungry at the time of eating the apple? etc…

And here is where we see the key problem with absolute time estimates: they take a lot of time to define and they can never be accurate. And as humans we are not very good at absolute estimates. The worst part is that absolute estimate give you the illusion of accuracy and predictability, but tend to be wrong most of the time.

Here is a quick test: when a developer tells a stakeholder that a particular task will take about 8 hours given no issues are encountered, what did the stakeholder undertand?

…

That in 8 hours it will be done. No questions asked.

Another quick question for you: how often the “no issues are encountered” is actually true and the estimate is on point?

…

Agile estimation in a complex environment

As I mentioned above, product development lies in a complex domain where a lot of uncertainties, risks, and unpredictable circumstances may impact our work. That is why we need a different way to estimate.

• Firstly, it has to take less time to estimate. We just need to have a ballpark understanding of how complex a task is, without going into analysis-paralysis.
• Secondly, it doesn’t have to be 100% accurate, but it should give a way to monitor our progress towards goals.

Let’s go back to our apple-eating example.

I will tell you that I don’t know how much time it will take me to eat an apple in minutes, for example, but I can assure you 100% that it will take me less time than eating a melon. No matter the size. Just for a simple reason that I have to cut the melon before I can eat it. And melons are generally much bigger than apples. Simple enough.

This is relative estimation. It works perfectly in a complex product environment where there are many unknowns.

And as I start working (eating fruits in our case), I’ll get a better understanding of how much work I can accomplish. Let’s say I have eaten ten apples in one hour. Since melons are more complex, I’d say about four times more, then I will only be able to eat about two and a half melons in an hour 🍈.

With this information it’s quite easy to understand how we are progressing towards our fruit eating goals and what is an approximate delivery date.

Beware of “Agile” peoplehours

The hardest thing about relative estimation is getting the habit of using it properly. As in our case study at the very beginning – it’s easy to turn story points into hours.

As a Scrum Master, your role is to establish empirical product planning for a complex environment which includes relative estimation. Stepping away from hours’ estimation is a way for you to help everyone understand the complexity and enact inspection and adaptation in their every day work.

It’s very important to set the foundation and build on it. If your team just started using Planning Poker without any preparation, they most likely don’t understand the premise and will likely use it incorrectly, doing more harm than good.

Whether your team is just starting with Agile estimation techniques or has been doing it for a while, make sure they understand why they are doing it.

Whenever I start working with a new team, I get ready to run a workshop about relative estimation. It sets the stage, and creates alignment within the team. This is often the first structured discussion they have about their estimates and why they do them. It is also a stepping stone in getting to better undertstanding of agility and Scrum.

It’s not about the estimate

At the end of the day, it’s not really about the number you put on your Product Backlog item. The number in itself doesn’t matter.

What matters is the discussions that happen between Developers, between the Developers and the Product Owner, the Scrum Team and the stakeholders. It’s an opportunity to create transparency.

Does your team have a transparent discussion about the work and their progress as the result of estimation?

If not, you’ve got some work to do.

One of the things that I pride myself with are the workshops that I run with the teams. Over time, I was able to find the best ways to facilitate powerful discussions. I’d like to share it with you.

If you are looking for a way to help your team understand relative estimation, I have created a new facilitation guide that focuses exactly on that. With these workshop materials you will be able to explain the key concepts of empirical planning through relative estimation and practice at it with your team.

I hope that this article has given you more insights into how to speak to your team about agile estimation and planning. And if not, I’ve got you covered.