Perils of Stopping Story Points
Commentary on the #NoEstimates movement, What Story Points are and words of caution (Part 1)
I’ve just finished reading John Cutler’s article on the question of whether we can stop using story points. If you’ve not read it, it’s worth a read, especially if you are a seasoned veteran of agility and the use of story points. For you, I’ll wait :)
TL;DR
The one group however, that I would not recommend it for, are relatively non-fluent agilists or those who have not caught up with lean thinking yet and are not delivering in a systemically aligned way. For example, if you still have an ops team separate from your dev team, whether intentional or not, or you are still working in departmental silos. I say this not to be mean, but the problem is that #NoEstimates naturally relies on using the actual, consistent, reliable performance of teams to determine the future scope of the project, or to determine the likelihood of the team’s ability to “achieve the deadlines” they should meet.
#NoEstimates
I’ve written about NoEstimaes before. Several times. As an observer and indeed, experimenter in the space, I have been extremely frustrated by the nearly 4 years that I’ve been watching or engaging with it. The movement’s hashtag in particular is pretty much one of the most digitally famous piece of arguably “fake news” that I’ve come across. The tag itself has led to thousands upon thousands of tweets from practitioners, critics, denigrates and even trolls. The movement seems to have become clogged and so frozen in time, some ten years ago and things really have not moved on much.
The #NoEstimates tag and subsequent push-back solely and exclusively refers to the very first estimate made in a project plan. The finger in the wind estimate given when a business owner, project manager or the like, comes to you and says
“We want to build a shimshammy, finger in the wind, we won’t hold you to it, but how long do you think it will take to build it?”
This is really where the #NoEstimates comes in. After this point, #NoEstimates advocates making decisions based on data.
See? This causes me a problem. Not least that the initial premise, the push-back at the very beginning, is unworkable unless you align all elements of the business value chain from business and tech (a business case is an estimate for example, which it can’t get away from — though there are ways around this too) but the rest of it is totally and utterly correct.
You should always make decisions based on the data in front of you. Every time you do not, you are unnecessarily introducing uncertainty and crucially, if people then act on that uncertainty — by spending money — they are in the realms of gambling. So pushing back, however uncomfortable it is, is the most humane thing you can do.
A History of Story Points
Way back at the beginning of the agile movement, story points were introduced as a way to manage some of the difficulties inherent in project estimation. Before then, most projects were estimated in days. A widget-app might take 210 days to complete. A flimflammy might take 120 days. But these estimates were made in different contexts, with different teams, by different people, working in different ways, in different companies, with different tools, at different times, in different industries, with different company structures, different company cultures, sometimes split in different geographical regions etc. each of those factors introduces a level of uncertainty (in days) which means generalisation of estimates made elsewhere simply doesn’t apply. How can it? What does baking a cake have to do with playing football? It led to some important discoveries, especially around [mythical] man-months. Double the team doesn’t double the throughput. Due in no small part to communication and triage time, as well as extra contention and thus, bottle-necking in shared services. I wrote about this some time ago.
Story points were introduces as a way to accept that the initial estimates are f***ed from the start and only get bigger with time.
Story points typically used a Fibonacci sequence for the “effort”, specifically to account for both the expected [average] size of the item and the variation [deviation] caused by the increases in time. A 3 point story is actually two 1-point stories of effort. The extra 1 being there to account for the variation in size (aka variation in estimate).
This is not to say that this understanding wasn’t there before then. Even PRINCE2 acknowledged that the work should not be estimated by people who were not doing the work. That attempted to remove one factor’s uncertainty and at best, all it ever did was reduce it. If the developer that did this work daily and the project manager estimated the same tasks, they’d come up with different numbers (itself uncertainty — Who does the business owner believe? Who will the business owner believe?).
This work of 5 days may then spread over 20, so the elapsed time was high (especially where contention was similarly high) and crucially this effectively meant that an estimate of 5 man days, took 20 actual days to do. So “in 20 days, you delivered 5 days worth of stuff” and “you told us it would take 5 days” became a naturally confrontational position that managers used to beat developers with.
Yet, as well as including story point estimation, agile teams worked in iterations of one, two or four weeks. The introduction of such time boxing is not really a bad thing at all. However, this naturally leads to the introduction of time into the system. What then happened is that managers and teams started to measure their output in one, two or four week cycles called sprints. Again, no bad thing. The issue is that naturally introduces time into the system again. And in fixed wage environments, time equals money.
Got any experience you’d like to share? Let us know in the comments or follow @Axelisys on twitter.
