#NoEstimates – The 6 alternatives for estimating
Everything you always wanted to know about #NoEstimates
Let’s start with a little bit of background. About five years ago Woody Zuill started questioning why we estimate and if there are maybe other ways. He did this under the name #NoEstimates and since then there have been heated discussions.
What I miss in these discussions is the context. It is a broad subject. I try to provide that context with this post.
It started with my own need to make some sense out the alternatives for estimating. Hopefully I managed to do it adequately well so that others also find it useful.
From the discussions I determined the following reasons to be interested in #NoEstimates:
- When no-one needs to know what will be built by when and when no-one requires to know where the money is being spent on in a certain quarter or year to get budget, there is no reason to estimate.
- The way estimating is misused.
- You are becoming so predictable that it doesn’t make sense to use story points as estimates anymore.
These starting positions are important to be able to make a distinction between the alternatives for estimating that I have seen mentioned under #NoEstimates. The practices below all are based on one of the above starting points.
I identified 6 different practices under the same # and I tried to be as accurate as can be in mentioning the main users/advocates of the ideas.
I aim to discuss the practice and use of the alternatives in general and usefulness for my working environment in particular. So here we go:
A. No estimates at all
Description: this is the approach that is most literal. Estimates are to be dropped completely.
Mentioned by: Tim Ottinger
Underlying reason: The organization is not interested to know where the money is being spent on in a certain quarter or year (to get budget). There’s budget and the people are trusted to build valuable software from it.
Tim Ottinger commented on this post informing me that his practice is a combination of this alternative, drip funding and planning on historical data (see both below). So he is not following the literal practice of not needing to understand anything about the size of the work. I then contemplated removing the alternative altogether, but I am convinced there are people actually work this way and it’s the only alternative without a sense of sizing and as such relevant for the discussion.
My assessment of practicality: You may argue that this is a perfect position to be in. You don’t have to step to people to ask for budget for a certain idea. You are simply allowed to use it as you want. Still I think you are working within constraints. Your budget and number of people available are not unlimited. So is time. I’d argue that you always need to know what you can do within these boundaries and for that you need to estimate.
B: Drip Funding / Work on the most important items first
Description: Decide how much you want to spend on the options available, drip fund & iterate.
Mentioned by: Neil Killick @woodyzuill
Underlying reason: Often you don’t know how big a certain initiative will be. Assuming one has the capability and will to deliver vertical slices through a solution early and rapidly, and one has fixed cross-functional team, 100% committed to the project at hand, one can focus on the potential value of the ideas we want to build while controlling cost using small “drips”. Drips being small iterations of a product. See Neil post on this here: Neil’s post mentioning Drip Funding
As Woody mentions in his blog starting #NoEstimates: ‘We discovered the needed features. Most of what was thought to be needed was not actually needed. Doing the work of writing the code in small pieces and getting it into real use made it possible to steer the work. This is the “requirements emerge concept”. I urge you and encourage you to think about it and experiment with it. It is GOLDEN.’
Here is a link to this post: Woody’s intro to #NoEstimates
My assessment of practicality: To me these approaches seem reasonable when you have only one or a few initiatives to work on and when the full scope of the initiative is not clear yet. By working in small chunks, funding only those small chunks every time, you have control on things not getting out of hand.
I don’t see this working everywhere. I our organization for instance we have multiple potential initiatives of which only about 10% can really be picked up due to constraints on money, time and staff. We need to have a fair understanding of what an initiative is about and based on that decide which of the initiatives are going to be picked up. On top of that all initiatives should fall into the bigger picture of our IT landscape, which doesn’t allow much experimentation.
C. #NoEstimates according to book Vasco Duarte
Description: here follows my understanding of Vasco’s #NoEstimates approach:
- Work with fixed duration, fixed cost and flexible scope.
- Break proposed deliverable down in features.
- Determine, based on historical data, the average number of stories per features and average duration of stories.
- Multiply user of stories with average duration.
- Knowing the duration and the cost you can now project what scope can be delivered.
- Deliver value early and keep on delivering iterations.
- In very regular intervals revisit this data and if required de-scope/re-scope.
The core principle is: Always be ready to stop the project and deliver value, at any time. Add a scope buffer to the project.
Mentioned by: Vasco Duarte
Underlying reason: According to Vasco Duarte we are bad at estimating. We can better study historical data and base our planning on average size of the user stories. By using averages as Heuristic one is enabled to receive early signals to allow early decisions making.
My assessment of practicality: taking the average size of the user stories based on historical data seems to me like a reasonable idea. But the approach is not without its risks, as you can see in below picture, often used on twitter. Averages alone don’t bring you where you want. You should also know something about the spread of the values.
I understand the notions of delivering small chunks of working software as it allows you to learn and adapt. But this approach doesn’t guarantee that the minimum requirements are met.
Changes have an impact on one of the factors of the triple constraint (cost, time, scope).
Vasco makes the choice to de-scope (see scope-buffer above) in order to be in time and within budget. You could just as well choose to keep the scope unchanged, but then take more time or spend more money. I can think of multiple situation where the absolute minimum scope isn’t that much smaller than the ‘nice to have’, so the scope buffer would be very small and not helping you. How to deal with this using this approach?
In the end Vasco’s approach does not take away the risk of planning misuse, the second reason mentioned above to discuss #NoEstimates.
Vasco’s last claim is that planning with historical data is more accurate than traditional planning (I assume he means by estimating story points). Even if this is the case, it doesn’t take away the issues, while the book claims it does. On top of that, whatever you call it, forecasting based on historical data is a form of estimating.
D. Roughly size on number of stories based on historical data
Description: At the start of an initiative: roughly guess the number of stories required for an initiative/project. Take average duration of user stories and multiply by # of expected user stories. This way you get a projection of the project end date or planned feature delivery date. While working on the initiative use CFD (Cumulative Flow Diagram) to track and show progress.
Mentioned by: Allen Holub @allenholub
Underlying reason: We are bad in estimating and we spend too much time on this. The planning should be lightweight and shouldn’t take much time. You can’t know upfront how many stories an initiative/project has and it also doesn’t make sense to slice stories because of this uncertainty. The CFD is a great tool to manage expectation. See a simple version below as used in one of the threads on twitter:
This will help you to clarify to management/client/user how you progress and what still needs to be done. This will probably not fully take away management abuse of estimates and planning, but it will certainly help you to gain understanding.
My assessment of practicality: Very similar to Vasco’s approach, but starting with less understanding on the scope and therefore more high-level. From all the #NoEstimates practices to upfront plan an initiative this one seems most practical to me. You generally indeed don’t have a complete view of an initiative upfront, and within an Agile working environment that isn’t the intention either. Also your own historical data is often a great tool to help predict average of user stories. My main critique is the same as one of the issues with Vasco’s approach: the flaws of averages. But it does have less impact here, because Allen proposes higher level projection. Another issue is that this does not help to take away the pain that many have, namely that estimates and plans are set in stone and turned into fixed delivery dates. Sure CFD is a nice tool to project progress, but this will not convince many of the people that have been used to put people under pressure to get things done. And also here: forecasting based on a guessed number of user stories and their average size IS a form of estimating.
E. Slicing Heuristic, every story a 1
Description: An explicit policy that describes how to “slice” work Just-In-Time to help us create consistency, a shared language for work and better predictability. An example is: A user story ready to be worked on must have only one acceptance test”. This example is up to now the only slicing heuristic example on story level that I saw mentioned.
Underlying reason: As stated in Neil’s post: User Story heuristic can be an extremely effective way of providing empirical forecasts without the need for estimating how long individual stories will take. A complete description can be found here: My slicing heuristic concept explained
Ron Jeffries also advocates slicing heuristics, talking about all stories being a ‘1’. See this video: All stories should be 1
By slicing everything to be very small you make the stories as clear as can be and you are enabled to work with a steady pace, being very predictable in your output. You also take away the reason to estimate stories (by for example story point estimating) because everything will be about the same size due to its very nature.
My assessment of practicality: This is a practice that I would put under #NoEstimates topic 3: “You are becoming so predictable that it doesn’t make sense to use story points as estimates anymore.” Also, this is a practice at the level of story/epic estimation, not the same as project/initiative estimation as discussed in the alternatives above.
I do like the approach of focusing on what is required to make the story a success. I even created a post where I describe that this is an important viewpoint Story Slicing example on Online Banking functionality. Neil takes this to the point that the stories are becoming very small by nature. I would love to be in a position where I have a constant flow of roughly equally sized small stories. Seems to be an ideal position to be in. I do have my questions regarding the use of ‘one acceptance test per story’. This picture, used a lot on twitter by Henrik Ebbeskog, illustrates what I mean:
In the picture above you see that an acceptance criterion might look simple (identify that the picture is that of a bird), but that it takes quite some effort to actually develop. On top of that I argue that it often is worthwhile to bundle three acceptance criteria into one story, because it is easier to develop this way (as it hits the same part of the code).
Also you run into the risk of losing cohesiveness of the software by deploying on micro-level. You should never lose the sight on the big picture.
Some argue that slicing to one acceptance test is difficult to achieve. Others (a.o. Glen B. Alleman) argue that that practice has been there for quite some time:
My team also tries to slice stories as small as possible, which mostly results in stories with one acceptance criterion. But we see that they vary in size quite much. It would be nice to see real-life examples of this practice where all stories are indeed very similar in size.
Final note: this practice is about how to predict/plan user stories/epcis. You should still have a view on the planning/budget for the larger initiative. As I see it this does require you to estimate that part.
F. Short/middle term planning stories/epics/capabilities on history based average
Description: this practice is also ditching story point estimating. It’s about using historical data to determine the average story size. Added to that is the velocity of the team, allowing you to understand the cadence in which you can deliver your stories. This is a practice that best fits in a working environment without time-boxes (like Scrum). Some are actively using this practice, others are implicitly using it.
Kirsten Minshall pointed me out that this practice is also used to plan epics/capabilities. User story mapping can be used to identify where to focus on (first). Then one can forecast based on historical data x the number of stories in an epic/capability.
Mentioned by: People that mentioned this approach are John Cutler @JohnCutlefish and Kirsten Minshall @KirstenMinshall.
Underlying reason: When you are becoming very predictable, why would you estimate your stories based on story points? Just look at your historical data and plan based upon that
Some mention the serious issues that arise with using story points. They can be misused to ‘command and control’ as the wrong kind of managers love these kind of figures (velocity, predictability). By removing story points you remove the misuse.
My assessment of practicality: Indeed, when you are becoming very predictable you could opt to drop user story estimating. I can agree with that. I do think that you may hit the ‘flaws of average’ issue, but you can take into account the spread of your historical data to deal with that. Mine is shown below and the spread looks not too bad, but it is already to big to be depending on the average story size:
Also this practice is about how to predict/plan user stories/epics. It looks very much like Vasco’s idea, but then on a smaller scale (stories/epics). With that it becomes more practical, because your aim is at what you can oversee. A piece of the puzzle, not the whole puzzle from the start. You should still have a view on the planning/budget for the larger initiative. As I see it this does require you to estimate that part.
Back to the remarks made about misuse of story points: I am not convinced that removing story points alone take away the dysfunction of a management that wants to command and control. I think more is needed, like a change in approach and behavior from management.
The above is my view on the practices as brought forward under #NoEstimates. As I see it none of the practices are a universal solution to the problems that come with estimating. The practices are all addressing different facets of estimating.
It shows that #NoEstimates is indeed a # that is used to describe all kinds of practices where estimates are not to be used (anymore). This however also hits the definition of an estimate. Some state that any kind of estimates should be avoided, others are targeting an certain type of estimating like Story Point Estimating or ‘classical estimating techniques’ (whatever that means).
So if you are in a discussion about #NoEstimates it helps to get an understanding on what exactly is being discussed. #NoEstimates has a lot of different shapes. And most of the alternatives include estimating in one form or the other.
My main take-away of the above is: #NoEstimates proposes a number of alternatives. I can relate to a lot of what is proposed -irrespective of whether or not estimation techniques are used-, but the alternatives don’t effectively tackle management misuse of planning an initiative/project. This requires a totally different solution, involving organizational changes.
Did you like the article? It would be awesome if you’d clap 👏🏻? Thanks!
Originally published at ageling.wordpress.com on September 18, 2017.