The Risks Of Estimating Time As An Agile Team, And What To Do About It

4 reasons why your Agile team shouldn’t estimate in hours or days, and what you can do instead.

Martijn van de Haterd
Serious Scrum
7 min readSep 6, 2021

--

As a father of two little boys, aged 4 and 2, I wouldn’t say I’m an expert on handling toddlers but I’m no rookie either. So, when the situation presents itself where I have to get my boys ready to go out the door (let’s say to go to the forest for a morning) I am quite capable of doing just that. I might even be tempted to say it’ll only take me 10 minutes. But every parent knows, getting two toddlers out the door is not always as easy as it sounds.

Assuming that both boys are dressed and fed, I have to tell the oldest what shoes to wear “No sandals to the forest, go get your boots… no, your boots I said… I don’t know, they’re probably by the backdoor where you left them.” The youngest needs my help getting his boots on, “Where is your other sock?”.

I must change a diaper, make sure the oldest uses the toilet, bring snacks, the diaper bag (just in case), and get myself ready in the meantime.

This is a fairly manageable situation which I’ve done numerous times, yet I probably shouldn’t say it will take 10 minutes. Even though this activity is rather predictable, time as a unit doesn’t seem the most fitting. Sometimes it takes 8 minutes other times 20.

Four Reasons Why Time As An Estimation Is Ineffective

Reason 1: Because we are horrible at estimating time.
We tend to have an optimism bias which simply put makes us underestimate how long a similar task took us in the past and on top of that makes us ignore (or grossly underestimate) possible setbacks down the road. This bias occurs throughout the day, whether it is when going to get a coffee before the meeting starts or underestimating how long a drive will take.

Reason 2: Because you shouldn’t estimate uncertainties in absolutes
Time is an absolute value, it doesn’t need context or framing. One hour is 60 minutes and it is always just that. But when we estimate a future activity (could be a user story, a waterfall project, or a home improvement project) we often do the estimation at a moment where details aren’t known yet, there are plenty of uncertainties yet to be discovered. In an Agile way of working, we don’t even want to know the details, yet we leave it up to the development team to figure out down the road what is the best way to implement something. So when you add the amount of uncertainties to the optimism bias it seems weird to use a value that leaves no room for interpretation.

Reason 3: Because someone else will run with your estimation
The following situation happened at one of my first employers: a project manager and an architect who both wouldn’t know two team members by name decided that a certain initiative would take the team 500 hours. Now let’s say there are five team members on the team that each work 40 hours a week, then this initiative should be done in three weeks, right? Well, that’s how it was forecasted to management and after approval, it was brought to the team for refinement. Guess what — three months later it was not completed.

It is very hard to get an estimation in hours or days and not assume that ‘now + estimation = done’.

The goal of refinement is to become more predictable. As a team, you discuss possible options and outcomes and clarify goals and priorities. In hopes of a smoother execution, you want to get the issues on the table beforehand. The final part of refinement is estimation, because we want to get a rough idea of the ‘chunk of work’, not because we want to communicate a deadline. Estimations and planning are two different things.

Reason 4: Because it leaves no room to grow
When you are in a short-lived assignment it makes sense to always take the quickest route. A straight line to the finish. But in Agile teams we often have a longer horizon, we want teams to grow (invest in T-shaping, onboard new staff for stability), technology to stay up to date (learn new tools and techniques and upgrade platforms) and systems to remain operable (refactoring, investing in maintainability and quick delivery). The quickest option now may be a very costly one down the road.

When using time estimations, it is harder to opt for that valuable detour, like letting the junior developer take the lead or choosing to add a bit of refactoring.

Using complexity for estimations, and what does that mean?

Back to my kids and trying to get them out the door. When I can’t say how long it will take me, or at least that estimation will give me little confidence, I can use an estimation of complexity instead. The complexity of the task of getting them out the door remains the same whether it took a few minutes longer or not. Let’s give that situation a complexity of 3.

At the end of the day their bedtime ritual begins. Getting undressed, PJ’s on, brushing their teeth, reading a book, and then lights out would be the oversimplified version of it. Compared to getting them out the door this is slightly more complex, let’s say it is a 5.

On set days however, bedtime ritual also includes bath time, this adds a bit of complexity therefore making it an 8.

For estimating complexity Agile teams often use the Fibonacci sequence (½,1,2,3,5,8,13,…). One of the reasons we do this is that we don’t want to foster the illusion that we know exactly how it will play out. That level of detail is simply not available at that moment. I know I’ll read a book to my kid tonight, I don’t know which one, he gets to choose it. One book takes longer to read than the next. And if we feel like it, we’ll read two books tonight.

A second reason to use this sequence is that complexity grows exponentially. This means we deliberately take a bigger margin of error into our estimations when the task gets more complex.

With estimations of complexity, we use sequences and language that makes it clear the estimations have value (compared to each other they give a sense of size) but that they are not an exact science and should not be used as if they were.

When using complexity as an estimation you respect the fact that certain details are unknown, and you don’t lock yourself down with a certain approach. You and your team may still find the best route for the assignment.

Forecasting over deadlines

Using complexity does not take away from the fact that you or your stakeholders might want to have a clearer sense about when something may be expected. This also works with complexity estimations.

All complexity points (story points) completed in a sprint make up a Velocity. This (average) velocity can be used for planning. Personally, I don’t like using it to plan the next sprint, but it is great for long-term planning. I could not explain it better than Mike Cohn did in one of his blogs:

“Suppose a basketball team is in the middle of their season. They’ve scored an average of 98 points per game through the 41 games thus far. It would be appropriate for them to say “We will probably average 98 points per game the rest of the season.” But they should not say before any one game, “Our average is 98 therefore we will score 98 tonight.” This is why I say velocity is a useful long-term predictor but is not a useful short-term predictor.”

As a team, you can provide clear insights about how far down the backlog you expect to come at a certain point in time or, the other way around, at which moment in time you expect to reach a certain part of the backlog. Therefore, you are just as able to discuss delivery date forecast as you were using time, only this time it will have more value.

Let’s be honest

I believe using time as an estimation is being comfortable with a false truth that you know doesn’t exist. I can’t help but feel that the person giving the estimation is often not the person dealing with the pressure of not meeting that deadline. Working with complexity as an estimation requires all parties to be open and fair about the situation, trying to work towards a situation that is most useful for all stakeholders. It might be a bit harder (for all to grasp) and it requires some trust, but it is worth it.

--

--

Martijn van de Haterd
Serious Scrum

Father and husband, Agile Consultant, Scrum Master, Servant Leadership enthusiast. I think the world needs more leaders, not managers.