Other posts in this series about Story Points:
My AgileAI experiment (which is a fancy name for “joke”) yielded several different themes around the questions posed about Story Points. In this post I’m going to examine the first theme - what are Story Points and why use them?
What are story points?
What is the point of story points?
Why should I estimate effort in points?
Way back in the last century, Extreme Programming used concepts called Ideal Days and Load Factor.
An Ideal Day is one in which you are able to focus solely on building the features for your Customer, without any interruptions whatsoever. This was used as for estimating User Stories, for example, I could estimate one as taking 3 ideal days to complete, meaning that I could complete the story in 3 days if I had no interruptions for meetings, to help others on the team, have discussions with the Customer, etc.
The issue, though, is that many of those interruptions are actually rather important! Having discussions with the Customer allows the team to evolve its understanding of what’s needed over time. Helping others when they need it smooths out the flow of work across the whole team, rather than optimizing for the individual. Finally, we do actually need to get together and discuss our work at times in order to coordinate properly. That encompasses the daily huddle or standup meeting, planning sessions, retrospectives, etc. So, the actual amount of available time doesn’t equal the ideal time.
That’s where the Load Factor was introduced. It was intended to compensate for all of the activities that took away from an Ideal Day and was used to translate Ideal Day estimates into something closer to actual elapsed days. A load factor of 0.6, for instance, indicated that 60% of your time could be allocated to working on stories. Therefore, an estimate of 3 Ideal Days, divided by the Load Factor of 0.6, yields an actual time estimate of 5 days to complete the work.
Because the world is unpredictable (!), the Load Factor was at best a finger in the wind estimate being applied to more estimates. We just don’t know if something will come along, such as a production problem that requires immediate attention or a re-org that distracts the Customer for a couple of weeks. Therefore, the unit of estimation was the Ideal Day.
There were issues, though, with these time-based estimates, some of which admittedly existed long before XP and Agile:
First and foremost, we mortal humans just aren’t that good at estimating the time required for knowledge work like developing software!
Estimates in time feel like hard commitments rather than estimates; if you haven’t completed the work by the time you stated, your stress level increases if you aren’t done!
People can feel micromanaged in discussions around time-based estimates, i.e. “6 hours? Can you not do it in 4 hours?”
Finally, when anyone heard, “That story is going to take 3 Ideal Days”, they heard, “That story is going to take 3 (mumble mumble) days”; when the story wasn’t done in 3 elapsed days, blood pressure increased and questions were asked.
That’s when Story Points were born!
Points were intended to be a relative measure of the level of effort to deliver a story, which included all of the team members involved. Effort included the amount of code (production and test) needed, how much testing was involved and how much risk existed from business and technical standpoints.
Originally, the only allowable values for Story Points were 1, 2 and 3, where any story deemed larger than 3 needed to be split. Those values were also intended to be relative to one another, since humans are actually pretty good at relative estimation. It’s not so much that a 2 is twice the effort of a 1 and 3 is 3 times the effort, but more that you would have a normal-ish distribution with a bunch of stories with estimates of 2 points and then smaller and roughly equal numbers of stories with estimates of 1 and 3 points. The constraint of having only 1, 2 and 3 points for estimation usually helped the team learn how to split stories much smaller than with time estimates.
Enter Fibonacci
In the very early 2000s, there were numerous ongoing discussions about that constraint. Some people advocated for “powers of 2”, with values of 1, 2, 4 and 8 for story points to allow for larger chunks of work to be estimated.
I believe it was 2001 when Mike Cohn first introduced the “modified Fibonacci” series for story points. This brought the values 1/2, 1, 2, 3, 5, 8, 13, 20, 40 and 80. His reasoning was that these predefined values would allow teams to estimate larger work without dickering over whether something was 40 points or 35. He did explicitly say, though, that the larger the estimate the greater the uncertainty.
Mike had been coaching teams to this approach and then wrote about it in his book User Stories Applied. Since it was the first book dedicated solely to how to work with User Stories, it was wildly popular and deservedly so. Despite being published in 2004, it remains relevant today as a source for learning how to work with User Stories.
However, that popularity had an unintended side effect. Within a few years, the “modified Fibonacci” scale had become the way to use story points. I encountered teams routinely taking on 20 point stories in an iteration and, of course, not completing them. When we dug deeper, there were always ways to split the stories much smaller. I also encountered teams where 95% of the stories were 8 or 13 points, with some that were smaller. In that case, the larger scale was just an illusion - make the stories 2 or 3 points and anything smaller a 1!
When I discussed these problems with the teams, they had been under the impression that the modified Fibonacci scale was the only way you could use story points - it had become a rule rather than a guideline. That allowed them to use larger estimates, which prevented them from splitting stories even smaller, which resulted in much greater uncertainty about the level of effort in the work, which resulted impaired or reduced flow of work and certainly reduced throughput. This is similar in concept to passing gravel through a funnel vs. passing small-grained sand:
This is an incredibly common problem that we see today in teams using Agile approaches, leading to difficulty shipping completed work, leading to the backlash we see now against “Agile” in general.
Conclusion
If you want to use Story Points, then please consider limiting the team’s choices to a small number of values, such as 1, 2 and 3 points. Anything larger is a trigger for a story to be split smaller. That, then, means that you must learn how to write and split stories well, but that’s a topic for later posts!
Don't forget my "Abbreviated Fibonacci Series" which is [1, TooBig]. ;-)