The what, why and how of #NoEstimates
I have recently spent some time looking more closely into the #NoEstimates movement. There is a substantial amount of information to be found on the internet, just look it up with your favorite search engine. Ron Jeffries, Woody Zuill, Neil Killick, Steve Fenton, Vasco Duarte, Angel Medinilla and many more share their experience in working with estimates. In this post I would like to share some thoughts with you and try to present the basic ideas conveyed in the “No Estimates” book by Vasco Duarte which I have just finished reading.
#NoEstimates is a catchy, rather provoking, term that questions the practice of estimating software development work. After all, if like Steve McConnell in his “Software Estimation: Demystifying the Black Art” book, you accept that good estimating means being within 25% of the actual duration of a project 75% of the time, would you bet your money on it? I know the #NoEstimates movement people wouldn’t! Instead, they suggest we should stop trying to get better in estimating and start forecasting instead.
“Stop trying to get better in estimating; start forecasting instead.“
#NoEstimates is an agile software development approach. It aims in providing a way to manage projects based on real progress, thus historical data. Other than the term itself might suggest, the aim is not to ban estimates altogether, but to rather reduce the need for estimates to a bare minimum. This is in line with the Lean principle of minimizing waste. And since estimates do not add value for the customer they just represent waste that needs to be minimized. The proposed #MehEstimates term by J.B. Rainserger or even #AgilePlanning term might therefore be more suitable, but in my personal opinion, would not have had the same impact as the #NoEstimates term.
“The aim is not to ban estimates altogether, but to rather reduce the need for estimates to a bare minimum.“
Almost everyone who works with iterative software development methods learns about Planning Poker. At the beginning of every iteration, team members will gather in order to collectively estimate the work that needs to be done. Since estimation depends on the personal experience of each member, reaching an agreement might be cumbersome for some teams. Even worse, by using Planning Poker you might not even produce a better estimation as a team. To see why, please have a look at my previous post here. What you would ideally look for in order to objectively assess the size of the remaining work and therefore the progress of your project is facts. These can be found in historical data or, in other words, work that has been completed by the same team at the same project.
Vasco suggests dropping estimation in story points in favor of forecasting based on user stories. Looking at the user stories that the team has already delivered, you could extrapolate to the future. A prerequisite for this to succeed is that the project work is divided in “small enough” stories and that in any case, the distribution of story sizes is random (i.e. not all big stories first, followed by small stories). The result will be a forecast of project progress that will be bound by an upper and a lower limit corresponding to the iteration length you use. The forecast will be updated when more data is collected or the remaining work gets reprioritized. Since forecasting, as described here, is a trivial task and things get done every day, the progress report can be updated daily!
For #NoEstimates to work, you will need to apply it early on in the project when your customer is still open for discussion and trust is being built. Naturally, you will need to define your project as a value-driven project where time and cost might be fixed, but scope is flexible. The scope should be determined by delivering the feature with the highest value first. And you should know your customer well enough, in order to understand which features are needed the most from his own perspective. You achieve this by frequent delivery of working software to your customer and by actively seeking his input, which in turn will probably lead to valuable discussions and to reshuffling of the remaining work.
When defining the features that the software will include, you should try meeting the INVEST criteria, where Vasco has replaced the “Estimable” with “Essential”. The project will further benefit by visualizing scope as a matrix; the columns being the requested features and the rows being independent units of work (user stories) that need to be completed in order to deliver each feature. Each piece of delivered software must be running and tested software abiding to the team’s definition of “done”. This will assure that real progress is being measured in accordance with what the agile principles prescribe. Since, in value-driven projects, time and costs are fixed, timeboxing the user stories might be a good idea. A central buffer can be used to accommodate for time overruns, as opposed to time-padding for each different user story. In that way, the risk for potential project delay remains visible at one place. Finally, constant slicing of the remaining features and user stories is of paramount importance, in order to ensure that work that is not required, is also not going to be done (avoiding the waste of overprocessing in Lean terms).
“#NoEstimates is more of an add-on to Agile approaches that use estimation, rather than a whole new approach.“
In my personal opinion, #NoEstimates is more of an add-on to Agile approaches that use estimation, rather than a whole new approach. And that’s a good thing because I sincerely think that we, Agile practitioners, can benefit from it. It might have occurred to some of you that Planning Poker isn’t really about hanging a number on a user story. It doesn’t really matter if a user story is a 3 as opposed to a 5, or even a 13 as opposed to 21 or 34. Some of you might even already have removed some of those numbers, ending up with just a few of them. It is the common understanding of the work to be done that really matters during the planning session. The value is in the discussion, not the estimates. If you are already that far, I think you are already using #NoEstimates.
“The value is in the discussion, not the estimates.“
What Vasco additionally proposes is the use of user stories instead of story points. It is an interesting idea to explore, so experiment with it! Take a small step, apply the PDCA cycle and see if it works for you. And remember; it is actually #MehEstimates, since #NoEstimates will also need some estimation 🙂 You need to estimate the size of the user stories in order to verify that there are no “too big” stories. You also need to estimate, at least, the scope of the first step of your project. Just be transparent about this and communicate real progress to your customer. Apply scope management, slicing features and stories in cooperation with your customer, aiming at providing the highest value at all times.
“#NoEstimates will also need some estimation“
The book itself suffers from some distracting language errors and could be improved by good editing (this might also be the case with this blog, so don’t hesitate to let me know). I also found it annoying that there is no table of contents and no publication dates. Other than that, I enjoyed the story about Carmen and Herman. It is a pity though we don’t get to read what kind of offer Carmen submitted in order to win the deal. Maybe something you could consider adding to the next version of the book Vasco? 🙂 I also fail to see Parkinson’s law as a Law; the same way Murphy’s law is not a Law. Parkinson refers to bureaucracies with his law, so if this applies to your organization you might have to dig deeper and first remove bureaucracy, before trying to apply #NoEstimates. Even if, as I personally believe, the book could have been shorter, it is still a good deal at just $7. So go get it, you might discover points I have not mentioned here. I would be glad if you would let me know.