Get certified - Transform your world of work today


No Estimates

Moving beyond estimation

11 August 2015

Pratyush Nath
Royal Bank of Scotland

If you are on Twitter, you would agree that #NoEstimates was the latest trending buzz in the Agile world. I have been reading about it, I have been questioned about it, and I strongly feel like adopting the idea.

When we ask, "Will you be able to deliver on time?" the general answer is that we will do our best. I have been in situations in which the management team has tweaked or interpreted our estimations incorrectly, and we have been asked to do more than what was estimated. Well, more than what we were already doing.

I have tried story points, functional points, actual hours, or days, but somehow when management analyzes the numbers, they start playing around with them. I have seen people who are fed up with this. In such situations, I suggest you start adopting the concept of "no estimation." Do not give your management any numbers to play with, and also salvage the time that you spend estimating.

What I am suggesting is that instead of wasting time estimating your problems or user stories, start splitting them so that they are all similarly sized. Now you can do your sprint planning based on the number of stories. The number of stories that you deliver in a sprint also becomes your velocity. So you are basically killing any scope of mathematics. If we follow Scrum's recommendation for continuous improvement and eliminating waste, the estimation process could be considered a complete waste. You are not going to be publishing or using the numbers anyway.

"No estimates" certainly looks like the way forward. I have thought about it, and I cannot see any negative effects. I am tempted to give it a try within my projects as soon as possible. I am only concerned that I may introduce one experiment too many for the teams!

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3.8 (4 ratings)


Anand Vyas, CSP,CSM, 8/11/2015 2:31:59 AM
Hi Pratyush,

I too have heard a lot of #NoEstimates; but havent gone into more details of it.

While reading your views, you mentioned "start splitting them so that they are all similarly sized." - what size are you talking about? How do you know they are similarly sized? I guess we cannot do away with numbers then?
Karen Fernandez, CSM, 8/11/2015 3:08:01 PM
Similarly sized? We do that already with complexity estimating. Still need a baseline don't you? Also depending on the type of work a team does not all stories are equal and could not be. Sorry not sold yet.
Gaurav Dahra, CSM,CSPO, 8/12/2015 5:16:04 AM
Heard about # NoEstimates but i think what you explained here in the end also gets down to the same point where in we calculate Velocity based on the stories delivered. The important point to note is splitting the stories as similar sized because sometimes stories might not be similar sized and also will differ in complexity, so in that case it will not give a clear picture.
Gaurav Dahra, CSM,CSPO, 8/12/2015 5:16:13 AM
As far as poker planning is concerned where in we use relative estimation and baseline it to estimate a new story and give story points considering all different factors. Team will commit a certain story points for the Sprint and then at the end of Sprint, Velocity is calculated based on the story points delivered which then acts as a bench mark while committing story points for the next sprint.
Linesh Mahadik, CSM, 8/12/2015 12:41:35 PM
Split the stories till they are all similarly sized? Work breakdown by another name?
Pratyush Nath, CSM, 8/23/2015 9:00:08 AM
When I say similarly sized, I have assumed that you have a Definition of Ready for a story defined. We have something like that a story should be small enough so that it can be done in a quarter of the sprint. This acts as a baseline and then we can build around this.

I agree that all stories cannot be of similar size, it depends on a lot of factors. Having no estimates means that we limit the scope of our stories and try to deliver them.
Kirk Bryde, CSM, 5/7/2016 6:38:09 PM
@Pratyush, I agree with your idea of splitting stories down to "similar size" and then just counting them. I know it may be difficult to know whether stories are of the same size or not (especially before they're implemented), but we only need to make them of similar size ON AVERAGE (a few outliers are inevitable, but that's OK). Then, as long as stories being forecast are of a similar size to stories that have already been implemented (on average), knowing specific details about the size (and complexity) doesn't matter - the team's throughput forecast will be linear to its historical throughput. The law of averages takes care of any remaining inaccuracies in right-sizing the stories.

@Linesh: Yes, it's a work breakdown process, but this should not be confused with the WBS tasking of traditional projects. Agile teams should be striving to break down their stories to be of similar size (whether they're estimated in story points or not)! If your team doesn't already do this, perhaps they're too focused on estimating the size and complexity of individual stories (which has questionable accuracy), and aren't focused enough on striving to work with stories that are easier to manage within a Sprint?

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up