Some thoughts on Story Points
Over the last 10 to 15 years story points have become a core 'agile' practice. 'Agile' in air quotes because one has to ask how Agile they are really at this point. Let's have quick a look at what story points are – in fact four versions of what story points are – some objections to them and whether or not we use them at Sodium Skies.
Story Points version 1: Ron Jeffries and ideal days
Ron Jeffries tells it best on his own blog and you should read this story over there. It's short. Here's an even shorter version.
Ron had an XP team (not a Scrum team) who estimated their work in ideal days. 1 ideal day of coding took about 3 real days due to interruptions from stakeholders, meetings and all the rest. So instead of publishing their estimates as 'ideal days' and being asked where 2/3 of the time was going, they published them as 'points'. In their context, in their organisation, this satisfied their stakeholders.
The original Story Points were just a synonym for 'ideal days'.
Story Points version 2: abstract units of time
Sometime around 2010, Story Points began to spread as an abstract way to estimate User Story size. They were closely coupled with the practice of Planning Poker and typically used unit sizes from the Fibonacci sequence. Using Planning Poker the whole team contributed to the estimate for each piece of work. It elicited discussion, and if the team disagreed significantly on the number of Story Points for a piece of work, that at least indicated that it might be a risk in the Sprint.
Their purpose in this version was generally to gauge Sprint Backlog capacity. The underlying belief was that we're typically very poor at estimating in time but very good at estimating relative sizes: "This is about twice as big as that". So if the team could manage on average 62.5 Story Points in a Sprint, then in Sprint Planning you added User Stories until you reached 62.5 estimated Story Points1.
The understanding always was that a team's Story Points reflected their people, their task and maybe even a bit of luck. It didn't matter if Team A estimated a task at 2 points and Team B estimated the same task at 5 points. So long as each team was consistent, Story Points enabled them to bring an appropriate amount of work from the Product Backlog to the Sprint Backlog.
In this version, Story Points became totemic in Agile communities.
Story Points version 3: SAFe
Two axioms of SAFe seem to be:
- Load the manual with as many Agile buzzwords and techniques as possible
- Design a system to centralise control of all the teams2
Story Points are no different. SAFe proposes that each team's Story Points should be on the same scale – Team A and Team B in the example above should estimate the same task at the same number of SPs. This enables Architects, Stakeholders and Programme Managers to estimate entire Epics even before the work is presented to the actual teams who will analyse it in detail and are accountable for delivering it.
Story Points version 4: commonplace 'agile' practice
Agile practice has unfortunately become extremely dilute. Many teams have some grasp of some Scrum and other Agile activities without ever reading the Scrum Guide or understanding the Agile Manifesto. Story Points have been widely adopted with little understanding or question.
So for instance a Tech Lead might hand out User Stories to team members, and each person on the team estimate their own work in Points. Much of the discussion that came with Planning Poker is lost, as is the liquidity within the team of each person simply picking up the next piece of work on the Sprint Backlog.
Worse, there are reports of some organisations comparing team members on the number of SPs they complete each Sprint, penalising those who deliver the fewest. This leads to all manner of dysfunctions: team members becoming competitors instead of collaborative colleagues, high-balling your own estimates (to log more SPs), low-balling others' estimates, hoarding easy work, developing secret automations that you keep to yourself…
What started as one team's linguistic tweak to meet their contextual needs has mutated into something that can tear teams apart.
Some criticisms
Story Points may well be better for many teams than estimating in days and hours. Some other teams may find that time estimates genuinely work well for them. Others have reported being so bored by Planning Poker that they have developed secret signals to cut the process short, with the Scrum Master none the wiser.
For some years now no-estimates advocates have been questioning whether estimates are required at all. Instead they focus on achieving a state of steady flow, whereby there is little demand for estimates, and on simply counting the number of well-sliced User Stories rather than taking the time to point them.
I had an opportunity to test the story-counting approach some years ago when working with a long-running product team. Several years' worth of Sprints and pointed tickets in Jira provided a basis of comparison, and I found such a tight correlation between SPs completed in a Sprint and tickets completed that it suggested that pointing was simply a waste of time. The team however was strongly resistant to trying a Sprint without pointing, holding to the veiw that you simply have to estimate without considering what those estimates are actually for.
This reinforces the now totemic nature of Story Point estimation. The Agile Manifesto proposes among its Principles that "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." If SPs are so ingrained that teams cannot imagine working without them, how can they ever find what works best for themselves?
The bottom line
At Sodium Skies we don't use estimates for our own internal work. We haven't found the need. And we advise remaining open-minded to different approaches for yours. Understand what different types of estimates are used for (eg roadmapping vs Sprint capacity planning) and experiment with different approaches. Story points? Time estimates? No estimates? How about Ducks?
Be Agile. Find out what works best for your team. Give it all a go.