Should Developers Make Estimates?

Submitted by Yuliya Mijuk on 05/22/2014

"Should developers estimate?" - This is the title of the next session of a regular developer meeting with the name Archib@le, which takes place in Basel on the 25 of May.

I have discovered this event by chance on XING and thought: "Why does someone asks this question? Are there any doubts that development needs release or project planning? Does someone want to talk about the accuracy level of estimation within software development projects? Or maybe they want to exchange experiences about which estimation units (e.g. hours, days, ideal days, story points, etc.) are more suitable for software development projects?

It looks like an event for me...

What speaks against estimating?

  • According to the experience of many developers an accurate estimate is not or only rarely possible.
  • Estimate costs development time. While the team estimates it can not develop and produce value.
  • More investment in the estimation increases the accuracy only slightly, since many projects are not comparable.

What are the benefits of estimating or why should we estimate?

  • Customers need information about costs and risk to come to a decision.
  • The estimation process helps the team to understand the complexity of the task as a whole and in detail.
  • Estimation provides important information to the team to organise themselves

When talking about the effort estimation, one should destinguisch between the estimation of the product backlog and that of the sprint backlog.

Estimation of the Sprint Backlog is the issue of the team. My experience shows that many teams do not need to estimate, to be organized in the sprint  and to be able to track their progress. They split their backlog items into tasks, with the restriction that the tasks should not last longer than a day. But there are also teams that estimate the tasks in the Sprint Planning in hours because they feel more secure if the total number of estimated hours is similar or corresponds to the sprint duration. Anyway, we are talking  here about a "may" and not a "should". It’s up to the team to decide, whether they will estimate the tasks in their  Sprint Backlog or not.

And how about the Product Backlog? Should developers make effort estimates for the Product Backlog? Even if one thinks, that a developer has too litle or even no benifits  from estimating, it is undeniable that a customer needs a reliable statement about the price and / or the duration of his order. And if you work for a company which develops its own product, you want to have a resource planning. The developer should therefore be able to answer the question about the price and / or duration, but they can decide for themselves how they come to the answer.

It need not be a traditional estimation of time. Because exactly this kind of estimation is the one, where all the week or negative points of estimating are most visible.

One can use relative estimation (e.g. Story Points) – estimation of the development effort for a Backlog Item in comparison to the other items in the Backlog. The total number of estimation points that have been implemented in a Sprint serves as the benchmark for determining the delivery or release date then. This type of estimation gives, in my experience, not less accurate values ??than the estimation in absolute units of time and goes faster. It encourages team discussions on the contents of the backlog items better as it is easier to say "this task is difficult" than "we need a lot of time for this task."

Or you can go even further and join the #NoEstimates movement that answers the question on price and duration/delivery date

  • on the basis of experience (e.g. price/duration for the kind of  work that one performs regularly at a fixed price with a fixed team)


  • on the basis of the project constraints as ist budget or ist deadline (e.g. "We have \$150, what can you build us for that?" or "The Folk Music Festival takes place in 2 months and the folk music festival app must be published one day before it starts ")

#NoEstimates requires trust between the customer and the contractor as well as a stable development team. And that is the situation that every developer wants to have. Insofar #NoEstimates is in my eyes the goal that you should strive for.

 says: "It is not about ditching estimates. It is about improving the way we work such that estimates become redundant".

Yuliya Mijuk

About the author

Yuliya Mijuk

Yuliya’s professional life started with Scrum. She is a Certified Scrum Professional and received her certification as ScrumMasters in 2006. She studied Computational Linguistics at the LMU in Munich. After the graduation in 2004 she came to WEB.DE where the transition to Scrum was taking place. Later on Yuliya worked as a ScrumMaster and Scrum Coach at SPRiNT iT and (solute GmbH).

Always up to date with the DasScrumTeam newsletter.

The best in terms of Scrum. Once a month. Every month.