Do we need estimates?

Posted Apr 17, 2020

If planning won’t bring predictability, or an accurate answer to the question “When will it be Done?” in a software project… I guess there’s no need to create estimates either, right?

Well, not quite. Estimates can be useful for other things than predicting when a set of work will be done. Here are two good reasons why you should consider creating estimates in a software project!

Enable delivery of business value early

With an agile, incremental, delivery model the goal is to realize as much value as early as possible. This can be compared to a traditional project where all business value is realized by the end of the project when the product is finally delivered. Instead we want something similar to the chart below.

Maximizing the value of the product is one of the core responsibilities of the product owner. For each and every sprint the team delivers a new product increment, the product owner needs to make sure that the new increment returns as much value as possible to the users, the business and other stakeholders.

A product backlog often contains a lot of ideas of what needs to be done and what could be done for a product. All of these items will differ in their complexity and effort of development. Complexity is impossible to estimate perfectly, but by adding estimates to the different backlog items the product owner can get a hint of the effort of the work required compared to other items in the product backlog.

With estimates added to the items in the backlog the product owner can work on creating a clear relationship between the expected business value a feature could bring and the effort it would require developing it. That information could help the product owner to resonate about priorities and to make better choices for the product. It’s also possible to uncover if high business value can be delivered with a small effort, and that would probably be a very interesting thing to prioritize!

Spawn important discussions about work complexity

One of the goals of the sprint planning event is to answer the question “What can be delivered in the Increment resulting from the upcoming Sprint?”. Before this can be determined it’s important that all team members have the same understanding of the work required to consider a backlog item as Done. To help the development team get to a shared understanding it’s important that the team has enough details about the Why and the What to achieve. They also need to keep the Definition of Done top-of-mind to consider all aspects of the work required to finally be able to deliver a potentially releasable product by the end of the sprint.

If I ask you to predict how long it would take to travel between Göteborg and Stockholm using a bicycle - What would you do? You would probably start to break down the challenge into smaller pieces using your imagination. Maybe you start asking yourself questions like:

• It’s almost 50 miles between Göteborg and Stockholm. How long does it take me to ride one mile in a pace I can manage for 50 miles?
• What kind of bike can I use? Is it in good shape? What happens if my bike breaks down or I get a flat tire?
• Are the roads for bicycles good enough all the way to Stockholm? I remember it was quite bumpy and hard getting through Mariestad by bicycle last time I was there…
• Do I need to travel over steep hills?
• How much rest do I need? Do I need two, three or four nights of sleep before I’m finally there?

The act of creating estimates tends to spawn insightful discussions both about what it would take, but also about what “getting there” means. When asking the team to estimate items in the backlog differences in understandings of the work often becomes more apparent. Past experiences often get shared in a way that is very productive for the team’s understanding of the work.

Different techniques can be used for estimating, but often the discussions are often more important than the estimate itself. After these discussions the development team often have gut-feeling about what can be delivered in the upcoming sprint. If the team finds it valuable the estimates can of course be used to support the team in deciding this as well.

Conclusion

If you have a good process around inspection, adaption and transparency you know that planning won’t bring predictability to your product development. You understand that the plans need to be changed based on new insights and customer needs.

I hope that after reading this post you can still see the value of estimates, and the act of creating them as a part of your planning. Use estimates as a tool for the product owner to make better priorities and for the development team to get a better understanding of the work ahead.

Please reach out to me if you have any feedback or comments!

Good luck!