I was teaching an introductory agile training course last week and noticed that many of the students got confused about story points. Taking a step back, I can appreciate their confusion about how story points work.
I personally like story points and find them helpful, especially for new teams. A lot of people don’t like them. Let’s explore why that might be.
People Get Confused About Story Points
People in my class got confused about story points.
They did not seem to be confused about relative estimating. They were able to use planning poker as a team. And they did affinity estimating as a team. We used the great dog grooming exercise from David A Koontz of the Agile Complexification Inverter site. Participants were able to quickly sort the dogs into groups that were roughly the same size and would “cost” about the same for grooming.
They were not confused about the concept of estimating how big things were.
What seemed to throw them was specific to using story points. “Do the points equate to hours? Where do the points come from?”, and “Why do you use the Fibonacci scale?”
In some cases, they thought each Fibonacci number could only be used on one item.
I Always Liked Story Points
I always thought that using story points with either story planning poker or affinity estimating were helpful, especially for new teams. I found they were both fast and accurate enough as an estimating technique.
Story points support velocity calculations and that provides a mechanism for teams to gauge their consistent delivery. They also provide ways to forecast the future in what I like to call, reality-based forecasting.
I always have discouraged teams from equating points and hours. The advantages of points wane when you make them equal to hours. And you cannot expect teams to improve their velocity if it is grounded in hours of availability.
Good Scrum Masters will support the agile team to use story points correctly and prevent most of the common misuses of story points. To be clear though, story points are not part of Scrum and you won’t find mention of them in the Scrum Guide.
What Critics Say About Story Points
Critics of story points say that they get abused. Managers begin to abuse the points. They compare one team to another or question the team’s “commitment”. I’ve heard managers call teams lazy.
And once someone outside the team begins to pay attention to the points, it is quite natural for the teams to begin to game the story point estimates.
I would argue that the same gaming and abuse will happen with any type of estimation. Everyone that has been in the position of giving estimates knows that estimates get challenged, gamed, and abused.
Other critics say that the team’s focus on points and velocity can lead to cutting corners, quality issues, and the buildup of technical debt.
What do you think?
A few thoughts The basic conciet at the core of story points is that teams need to size pieces of work in order to know whether the work is too big or too risky to accomplish in a specific period of time. The answer is no, any team that breaks its work down, plans and commits to that work and then uses the results from that sprint or iteration to learn does not need story points. The inspect and adapt feedback loop provides an experiential platform that negates the need to have a debate over Cohn’s Numbers or an entry on the Fibonacci scale. That time is better suited discussing what the work is and how it is going to be solved.
Story Points are not horrible at a team level assuming they are not equated to hours and assuming risk is addressed as part of relative size. But, as you noted, that is a human failing. Kahneman in Thinking Fast and Slow suggested human attribute causality to events. Story Points easily fall into that pattern.
Story Point: Not horrible and they may be useful in some circumstances (I feel a blog entry coming) but like most tools, at some point, they become metaphors at which time they have outlived their usefulness. So for me, in most circumstances I can leave them!
Tom, thanks for your comments. I guess “not horrible” is a fair characterization of story points!
Anthony
At the team level, Story Points have a role to play. The role* is not for productivity assessment but to help the team share an understanding for how difficult and time consuming a specific piece of work might be. It’s the conversation around the “size” that helps to communicate what is to be done to deliver a story.
For project level measurement or estimation I advocate the use of COSMIC FP, a consistent, ISO standard for functionality size. CFP cannot be gamed, they are easy to count and are an appropriate basis for project level metrics.
Story points – leave them*
Colin, thanks for joining the conversation. I’ve not heard of COSMIC though I am old enough to remember function point estimating from my days at IBM in the 1980’s. I’m curious about one aspect of COSMIC vs. Story Points and that is speed. I would imagine estimating using CFP would be more accurate, but much slower than just using FP. Thoughts?
Anthony
I am familiar with most of the functional metrics (and am proficient at 4 of them). The speed of the counter is dependent on granularity. The problematic part of that statement is the term “the counter”. While accuracy in size is better the level of transparency and team buy-in is often lower.
PS – all sizing methods can be gamed if some works hard enough. Unless there is trust in the system them measures and metrics are things that are perceived to be “done” to the team or in support of the contract. I find that if you treat people as part of the solution rather than the problem that they do the right thing.