Other posts in this series about Story Points:
The second theme identified by the questions about Story Points from my AgileAI experiment was about equating points in some way to time. Here are some of the questions that were asked:
Are story points just days?
Should I look at story points as time?
How long should a 5 point story take to develop?
What is a good number of story points for a large feature that takes 3 people 6 days to finish?
What is the value of a single story point?
How big is a story point?
Which story point format is best?
While the last one kind of befuddled me, the others are quite typical.
With respect to equating Story Points to any time-based measure, you’ll recall that in What is the (Story) Point I mentioned that points were created explicitly to get away from measurement in time. I won’t rehash the reasons why again here, but suffice to say that it’s something we want to avoid at the level of granularity of a User Story.
So, here are some quick answers to the above questions:
Are story points just days? No.
Should I look at story points as time? No.
How long should a 5 point story take to develop? As long as it takes. If that’s more than an entire iteration/sprint, then it was too big to begin with.
What is a good number of story points for a large feature that takes 3 people 6 days to finish? A good number? One. Except that the feature in question should likely be split into much smaller stories.
What is the value of a single story point? Um… one point!
How big is a story point? As big as it needs to be. Each team will be different.
Which story point format is best? As far as I’m aware, there is only the numeric format, unless you include T-shirt sizing, which is a different estimation technique altogether.
These questions and my answers represent both the strength and weakness of using Story Points. There were intended from the start to be different depending on the team and even the type of work. A story estimated at 2 points by Team A might take them a day or so to complete. If Team B did that work, it might be 1/2 a day or 4 days. We just don’t know and, honestly, we don’t care.
Story Points where never intended to be comparable across teams! They were intended to be used by a single team as a lightweight estimation technique that avoided an time component, yet could still be used to assist a team during iteration/sprint planning. To wit, we use a concept called Yesterday’s Weather by which we only pull the amount of work into an iteration/sprint that was completed the previous iteration/sprint. So, if we completed 15 points last time, we’ll only pull in 15 points this time. You might adjust for holidays or planned absences from the team, but in general that’s all you do. No calculating of “available hours” or any such rigamarole (which is a technical term) - just assume you’ll get the same amount done.
It’s also quite possible for the “size” of a point to change over time as a team learns more about the solution they’re building, or as a team matures after being together for a while. Maybe some new technology comes along that makes the technical work easier. Maybe a new team member causes the team’s throughput to increase or decrease. We just don’t know, so tying points to time remains a fool’s errand!
Back to comparing points across teams for a moment. The Scaled Agile Framework (SAFe) has the concept of Normalized Story Points for baseline estimation. SAFe actually stipulates how many points are available per developer per two-week iteration.
I can tell you unequivocally that this is NOT what was intended with Story Points, not by a long shot!
Even time estimation cannot be baselined across teams because teams contain different people! The type of thinking that all teams are completely equal and their throughput is the same comes from Scientific Management, aka Taylorism. It treats people as “resources” that can be replaced by another “resource” with no change in performance of the group.
And that’s complete bullshit.
Story Points were intended to be used by individual teams for their own internal work management. They are a gauge of the effort required by that team to deliver the story. The number of points completed over a certain time period is used by that team as a simple planning tool to determine how much work to pull into an iteration/sprint.
That’s it. That’s all.
To summarize, the definition of “1 story point” will vary from team to team and will vary over time. Therefore you can’t (and shouldn’t) equate Story Points to days or any other time-based measurement.
In an upcoming post I will talk about alternatives to using Story Points that also avoid time-based estimate. Stay tuned!