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

TL;DR

Estimation is valuable mainly for the team discussions it generates, not the numbers themselves. New Scrum Teams benefit from using Story Points and Velocity, but as they mature, they should shift to flow-based metrics like Cycle Time and Throughput and consider dropping traditional estimation. Teams should regularly review and adapt their process, moving toward simpler sizing and continuous improvement as they gain experience.

22 August 2019
Written by Martin Hinshelwood
3 minute read
Practice Product Development Scrum
Table of Contents
Comments
Comment
Feedback
` LinkedIn WhatsApp Twitter Facebook Email
Subscribe

As part of the Scrum.org 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: http://ow.ly/ijiM50vwEkD

[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:

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.

Smart Classifications

Each classification [Concepts, Categories, & Tags] was assigned using AI-powered semantic analysis and scored across relevance, depth, and alignment. Final decisions? Still human. Always traceable. Hover to see how it applies.

Table of Contents
Comments
Comment
Feedback
` LinkedIn WhatsApp Twitter Facebook Email
Subscribe

What to read next

Article Scrum Product Management

How do you make a good Forecast?

Explains how to create reliable forecasts in agile projects by using flow metrics like cycle time and throughput, and shifting from …

Read article
Article Scrum Product Development

How do you incorporate a Design Sprint in Scrum?

Explains how to integrate Design Sprint activities within Scrum by embedding design and UX work into regular sprints and backlog refinement, …

Read article
Article Scrum Product Management

What's the best way to work around multiple PO?

Guidance on addressing issues with multiple Product Owners in Scrum, highlighting the need for clear backlog ownership and accountability to …

Read article
Article Scrum Product Development

In Nexus with 5 Scrum teams, how can the Product Owner attend all Sprint Planning events?

Explains how a Product Owner can manage Sprint Planning across multiple Scrum teams in Nexus by delegating, using area or team owners, and …

Read article
Video Scrum Product Development

How does a Scrum team estimate what can be delivered in a Sprint?

Scrum teams estimate Sprint deliverables by assessing the size and complexity of backlog items, focusing on shared understanding rather than …

Watch video
Article Scrum Technical Leadership

Should the Scrum Master always remove impediments?

Explains when a Scrum Master should remove impediments, focusing on team self-sufficiency, true impediments, and supporting team growth …

Read article