Get to the Forefront of
Agile Innovation

As part of our commitment to excellence and innovation, we’re inviting you to join our exclusive 365-day free beta program. This is a unique opportunity to experience firsthand the transformative impact scagile can have on your agile project management processes, at no cost.

The Risks of Time Estimation in Agile Teams

Time estimations in scagile app

Contents of this article

Time estimation is undoubtedly one of those issues that divides the agile community into two camps. Let’s face it, most development teams are against it, while management often insists on it. Both have their reasons and usually, these are quite obvious and understandable on both sides.

Development teams regularly dispute this exercise’s significance and often feel unjustly controlled or even micromanaged. Organizations, on the other hand, often emphasize their interest in operability through predictability, both regarding time-to-market and concerning budgets and costs.

Of course, and how could it be otherwise, both are right and are particularly happy to let each other know it. In the tireless effort to find a good solution – unsurprisingly – the problem is shifted to the methodology and thus to Agile Coaches and/or Scrum Masters. They are now expected to explain the other person’s position, or even better, to convince each other of the respective opposite viewpoint.

This is sometimes not so easy – also for obvious reasons – and therefore I dedicate this article to this topic with a clear and unambiguous recommendation that hopefully both sides can understand and accept. 

To avoid a major misunderstanding, this article is about estimating the effort in time. It is not about estimating the job size in Story Points. Unfortunately, the two are too often confused, usually in the sense that story points are used as a currency for estimating effort. Often also because people do not really reflect the difference between job-size and effort. How can you tell the difference? More on this a little later…

Back to our effort estimation and time estimation now. I use both terms synonymously here.

For all those who are just as impatient as I am, I’ll reveal the answer right after this commercial break… uhhh… no, I’ll give it right away today for a change and then for all of you who want to know the details or who don’t like the answer, I’ll give the reasoning.

Do you agree?

I’ll take the silence as a “yes”. 

Are time estimations effective in Agile?

Time estimates for PBIs (Product Backlog Items) – i.e. usually Stories – or even for Subtasks are…

Useless

They don’t deliver what you’d like them to, and with a bit of bad luck, they even take teams and organizations further away from what they actually want to achieve. 

I’m not saying they wouldn’t be useful if they worked, but they simply don’t, and therefore often the opposite of what is desired happens. I’ll come back to that shortly.

Anyone who is satisfied with the answer? Great, feel free to go ahead and show this to your Product Owner or Manager. Anyone who wants to know why, or who has well-founded doubts about my hypothesis – let’s go more into detail.   

Pros and Cons of time estimations

I must admit that not so long ago, I claimed the exact opposite. I also belonged to the camp of time estimators, regularly demanded it in my training sessions, and justified why it was so important. I fell victim to (self-)reflection and experience.

The longer I have looked at this and thought about it, the less I think that time estimation can be a solution to the problem of agile forecasting. So today, I take it all back and claim the opposite and sincerely and explicitly apologize to everyone I’ve annoyed with time estimation. 

But first things first. Why was I a proponent of time estimation and why are so many Project Managers, Product Owners, Business Owners, and Stakeholders still – justifiably so – today? 

Why are time estimates often ineffective – our honest opinion

Pro: Time estimates help teams make a commitment.

In my training courses, I quote two basic values of agile working methods: Commitment and Completion. This is primarily about commitment, which can be seen quite well in the KPI “Sprint Accuracy”. The very abbreviated explanation for this is as follows: 

Commitment: we as a team set ourselves a target for a sprint and that is exactly what we deliver. If this does not apply on a regular basis, you no longer need sprints – so you can go straight to Kanban – and thus deprive the organization of any chance to make any halfway valid planning. In terms of time-to-market, this is not good at all. 

I have given a detailed explanation in the article “The 4 C’s”.

It is obvious that time estimates based on Subtasks are quite helpful, if not even indispensable for making a commitment. After all, a Sprint is a timebox, so everything I do in it has a time component. Unlike in classic project management (e.g. Waterfall), where the length of the phases depends on the content, in an Agile context it’s exactly the opposite – almost everything is timeboxed. That’s just the DNA of Agile methodology. So, it’s hard to say that Sprint Accuracy or keeping the commitment is not that important.

So, it’s not so easy to find time estimates unhelpful. We don’t really want to give up on the commitment element and we also don’t want to go back to the phased model, i.e. back to traditional project management.

Agile teams appreciate Asana’s approach, leveraging projects and sections to visually organize work and provide clarity on project planning responsibilities. 

Despite its popularity, Asana has grappled with challenges in keeping pace with its rapid growth. This has resulted in occasional downtime, causing disruptions to workflows and leaving Agile users feeling discontent. 

Con: We are horrible at estimating time

Unfortunately, the problem is that time estimations simply don’t work, they don’t lead to the result we want, no matter how hard development teams try. I have discussed this fact a lot and for a long time with very experienced developers, architects, trainers, CTOs – you name it. I’ve discussed it with inexperienced developers, who are also part of the teams, and asked them what they think they need to be able to provide valid time estimates.

These were very intensive discussions because, after all, I am not only an Agile Coach but also a Business Owner for our product myself (watch out – commercial break: https://scagile.io) and have a pretty high interest in ensuring that commitments are kept.

We also analyzed countless sprints in various projects to see how estimations matched the time bookings. The result was sobering. We tried everything, like keeping subtasks small, i.e. under 4 hours, because small things can be estimated more precisely than complex items. Nevertheless, the deviations were about as big as if we had simply rolled the dice and realized that we weren’t exactly on a lucky streak.

As important as time estimates are and as much as we would like to have them – both subjunctive – we simply don’t get close enough to a usable result. Even very experienced developers have confirmed to me that once a task is sufficiently complex, they can no longer provide a precise estimate.

There are simply too many factors that play a role – including how you feel on that day – which cannot all be estimated or even eliminated. It’s as if you needed a map on a 1:1 scale.

Some say that this was precisely the reason for the development of Extreme Programming and other techniques as forerunners to Agile methodology because things – like creative processes – became too complex to remain predictable and plannable. A vicious circle. 

Is there an alternative to time estimations?

Of course, we have developed techniques for reducing complexity and decomposition in response to this, but they don’t go so far as to make subtasks time-estimatable. It’s no use; we must face this.

The idea of having no alternative to time estimations while at the same time recognizing that they don’t work causes a lot of frustration for some. And yet, or perhaps precisely because of this, we have to ask ourselves how we can escape this dilemma. Maybe it’s not as bad as it looks. 

What we need is a shift in mindset. Instead of relying on numbers, i.e. time estimations, we should learn to trust our setup. This is not something we’re used to, and it requires a bit more courage. But if we look at it the right way, it may even result in even more agility and a better understanding of agile work, and in the end, we would have gained more than just a good estimation of our delivery capability.

But now let’s get specific. As mentioned above, commitment is one of two fundamental values of agile methodology. That remains so.

But what is the purpose of agile methodology? Without a doubt, the purpose of agile working is to create business agility, i.e. the ability of organizations to react to changing market situations quickly.

To achieve this, the organization needs above all a flow of value. Business agility and the flow of value are two sides of the same coin. Every team and organization should therefore strive to generate flow. Wherever possible, all things that obstruct the flow should be examined closely and, if achievable, eliminated.

Con: Time estimations distract us from more important discussions

Time estimations are definitely a flow-impeding activity. This is the second important insight we have gained from our discussions and observations. Time estimates too often lead to narrow-minded discussions, and they undermine valuable discussions about the purpose of features and the ways to implement them.

To be more specific, teams avoid creating a detailed implementation plan when the sword of Damocles of time estimates hangs over them. The more detailed they get, the more often they must make the disliked estimates and the more they discuss the form rather than the content. Because even in the agile planning process, timeboxes cannot be extended at will.


Ultimately, I would trust a team that is truly in flow more in terms of commitment than a team that desperately and with great effort tries to make time estimations, which everyone knows after some time won’t work well and will potentially leave all stakeholders disappointed in the end.

So what are Story Points and how do they differ from time estimates?

Here are a few words to help you differentiate both terms. This is important because the assessment of which estimate is useful, and which is not is very different. The formula for job size, which has now become widely accepted, is:

JS = amount of work + complexity + uncertainty

Here is a brief example that illustrates the difference between job size and effort: You have to clear the snow from the path outside your front door in winter. The example is a little far-fetched, as snow has become rather rare due to climate change, but some of you may still remember shoveling snow in front of your doors.

You are now asked to estimate the effort involved, and your partner asks you when you will be finished. So what you need to do here is a simple estimate of your effort – in other words, a time estimate. Intuitively, you will create this estimate in two steps.

Step 1, you estimate the job size and apply the above formula.

Amount of work
↪︎
How much snow needs to be shoveled away? Let's say 20 cm of fresh snow has fallen, the path is 20 m long and 4 m wide.
Complexity
↪︎
Eskimos know about 200 different words for snow. Snow is not just snow and if you are unlucky, the snow below has already turned into ice. So, the matter becomes more complex. Or maybe it's just light powder snow that no one has trodden down yet, and you can use a snow shovel instead of a spade, for example.
Unceirtanty
↪︎
You look up at the sky and realize that it looks like it could snow again. You don't know for sure, but your weather app says there's a 70% chance. When it snows, the job size inevitably increases.

The job size is therefore concerned with the object itself, so it is completely independent of whether you do it or whether you ground your children, which they consider to be completely undeserved when they take on the job.


The natural currency for effort is time. To determine the effort, we therefore make a time estimate, naturally related to the job size. Anything else doesn’t really make sense. If you are asked the question, “When will you be finished?”, you could at best amaze the questioner with the answer, “In 13 story points.” at best. The questioner will probably not find the answer very helpful unless they know your exact velocity. But they would also convert it into time, so you could save yourself the detour.

Step 2: Now you estimate the effort.

Of course, this depends heavily on who is doing it. A strong king will take longer than the seven dwarves. The number of workers, the skills, the experience, the tools, the method, the motivation, etc. all have an impact on the effort. So while the size of the job is more indicative of the nature of the object, the effort is more indicative of the characteristics of the team, i.e. the people.

There is no currency for job size. This is mainly due to the “complexity” component in the formula. We deal a lot with complexity in the world, but the world has not yet invented a scale such as Fahrenheit or a method of measurement.

 To my knowledge, the Story Points currency, even in the form of (team/organization)-individual and relative estimation, is the first attempt ever to represent complexity numerically. You should therefore only use Story Points for this purpose. The sensible question would therefore be “How long does it take you and your team of 7 dwarves on average to complete a task of 13 story points?”. If you want to find out more about Story Points, you can take a look here.

The situation is quite different here. I think this makes perfect sense. Since it is determined using a comparative estimate with an accepted uncertainty, it is much easier and usually less problematic to determine. Job size, together with a feeling for the velocity of a team, also enables quite good commitment and the estimation of job size has other advantages, which I discussed in more detail in this article.

Final thoughts

To sum up, abandoning time estimation is not a rejection of commitments or the need for time-to-market capability. We don’t want to give up on our goals, we’ve just learned that time estimations don’t get us anywhere here because they don’t work as reliably as we need them to.

Even very experienced developers and teams can’t deliver the precision we need. Despite all efforts, they do not move us forward, and we would be well advised to change our strategy. Instead, the disadvantages of elaborate time estimations are undeniable and get in the way of what is essential for us to achieve business agility in an organization, namely flow.

Flow is a sensitive matter, so we should make every effort to avoid anything that hinders it. So, are we trading accuracy for flow? I don’t think so. I believe that teams with flow are very capable of both delivering and achieving very good forecasting because they concentrate on the content rather than on formalizing estimation processes.

They learn to use the timeboxes more as a structuring element of the agile process than as a delivery milestone for a specific set of features. While commitment may suffer a little, it is overall better for the time-to-market goal. As long as the loss of commitment – ultimately represented by the Sprint Accuracy KPI – remains within the range of 5% to 15%, this would be a good deal. If it goes beyond that, you probably have other problems and most likely no longer have flow.

I think it will become clear here at the latest that flow and Sprint Accuracy also correlate. At least it corresponds to my observation that teams in flow can make and keep commitments quite well, and vice versa, that teams with very good sprint accuracy are often also in flow. 

The app for scaled agile teams is finally here!
Click here to see articles with the same tags:
Klaus Riedel
As an agile coach, Klaus Riedel, together with his team, supports the digital transformation and the introduction of Scrum and SAFe in large organizations such as Deutsche Bank, Conrad Electronics, Volkswagen, PWC and others.

All his gained practical experiences in more than 15 years of agile transformation have been incorporated into the articles of his blog.

In Scagile Academy he trains young Agile Experts and since 2016 he teaches agile project management at the German Faculty of TU Sofia.
More interesting articles for you: