No Estimates and is it advisable for a Scrum Team to adopt it?

As part of the webinar “Ask a Professional Scrum Trainer – Martin Hinshelwood – Answering Your Most Pressing Scrum Questions” I was asked a number of questions. Since not only was I on the spot and live, I thought that I should answer each question that was asked again here, as well as those questions I did not get to.

In case you missed it, here is the recording of yesterday’s Ask a Professional Scrum Trainer webinar with Martin Hinshelwood! Watch here:

[Question] NoEstimates and is it advisable for a Scrum Team to adopt it?

Estimation is a tricky topic as many folks are heavily invested in it. My feeling is that the value of estimation is not in the resultant numbers, but in the discussion and illuminations that the activity brings to the Scrum Team. They understand more by discussing it than is wasted in the time it takes. As the Scrum Team builds up its inherent knowledge of the product, the market and the technology they these activities should naturally streamline, and anything you can bring as they mature to minimise the waste in this process is a good thing. Remember though, it’s not waste if it results in useful learnings.

When a Scrum Team is first starting out they have enough on their plate trying to deliver working software every Sprint to worry about the deep mechanics of Flow. So Story Points and Velocity are a good starting place that provides a balance of the team learning how to communicate and decompose their work. Story Points are easy to understand, easy to implement and great for immature teams. Once the team gets past the basics they need to start thinking about optimisation of their process. At the very least they should be optimising at every Sprint Retrospective and very quickly the question should come up: “Should we keep doing planning poker”. If the question comes up, then the answer is a resounding no!.

Once a Scrum Team is able to deliver working software at least at the end of every Sprint then they should be ready to start focusing on optimising their Flow. That means dropping Velocity and Story Points in favour of four new metrics that will help them on the next leg of their journey of continuous improvement:

  • Cycle Time
  • Throughput
  • WIP
  • Work Item Aging

These metrics enable the Development Team to start having a lot more interesting conversations about the work that is happening and the state of that work. Once Teams have a few Sprints worth of data they start to realise that to game the metrics they can just reduce the size of PBI. They spend more time looking at Sprint Refinement, the work gets smaller, and their flow gets better. In this new world of small PBI and a greater degree of predictability the need to spend a lot of time on relative sizing disappears and is naturally replaced by boolean sizing. Does a PBI fit or does it not.

My feeling is that #NoEstimated is one way to do boolean estimation. You can read about NoEstimates on Ron Jeffers post.

Read the Kanban Guide for Scrum Teams and Actionable Agile Metrics for Predictability from Daniel Vacanti.

While there are no right answers there are some answers that are better than others. For your given situation select the most right answer and iteration to the best version of it.

Create a conversation around this article

Share on Facebook
Share on Twitter
Share on Linkdin

Read more

Martin Hinshelwood
The Boards in Azure DevOps are a powerful tool that your teams can leverage to enable transparent visualization of the current state of value delivery.  However, the inclusion of Blocked columns can stealthily erode the very foundations of efficiency these boards are meant to uphold. By obfuscating the state of …
Martin Hinshelwood
This week, I participated in a Webinar hosted by Sabrina Love ( Product Owner) as well as my colleagues, Joanna Płaskonka, Ph.D. and Alex Ballarin 🇺🇦 to discuss the state of learning and how immersive learning is the future of training. You can watch the video below to hear …
Martin Hinshelwood
Business Leaders face a key challenge when scaling their organisations effectively while maintaining the distinctiveness that made us successful in the first place. Many frameworks and methodologies, such as Scaled Agile Framework (SAFe) or the Spotify Model, promise a structured approach to scaling, but do they genuinely fit our unique …
Martin Hinshelwood
As we inch further into the dynamic landscape of the 21st century, our long-established Alpha organisations stand on shaky ground. The organisations whose DNA is infused with strict command and control, woven into the fabric of every process, are feeling the tremors of a rapidly evolving, technologically charged market. Not …