At least two of these statements are controversial:
🤔 Story points are inaccurate when used correctly.
🤔 Story points are inaccurate when used correctly.
👌 Use story points for sprint planning.
＊ Story points are often misused.
There is no contradiction — I will explain.
Little-known fact: story points are not officially part of Agile Scrum. The Scrum Guide mentions only "backlog items," not User Stories. However, User Stories have been widely adopted, and in general they are a good idea.
Ron Jeffries, one of the founders of the Extreme Programming (XP) methodology, says¹:
I may have invented story points, and if I did, I’m sorry now.
Jeffries originally estimated stories in terms of time — "ideal days". An "ideal day" was a theoretical day with none of the usual workplace interruptions ("if the bastards would just leave you alone," in Jeffries' words). It tended to take three days to get an ideal day's work done.
Nobody wanted to accept that it took three days to get one day's worth of quality work done, so Jeffries stopped using days as his unit of estimation. He just renamed them "points". A story worth 3 points would take 9 days to complete.
Story points are misused in many ways. Here are two egregious examples:
- Use of a non-linear scale for story points. It makes it difficult to compare stories, and even more difficult to plan sprints.
- Using story points to answer, "When should this story be finished?"
The only proper uses of story points are:
- Sprint Planning.
<end of list>
Story points are inaccurate. They are supposed to be inaccurate. The system works because the errors tend to cancel each other out on average.
The only questions that should be answered using story points are these:
- What is the team's capacity for the next sprint?
- Which combination of stories fits into the next sprint?
This is how I use story points successfully:
👉 Use a linear scale.
👉 Use a linear scale.
- This means that a 3-point story should take three times as long as a 1-pointer. Or three times as many people.
- This allows sprint planning to be like playing Tetris.
- I use man-days, but as Jeffries recommends, I call them points¹. 1 man-day is 1 point.
👉 Use discrete values only, a.k.a. "T-shirt sizes".
- If a story falls in-between sizes, use your intuition to size up or down to the closest appropriate value.
- These are the story sizes that have worked for me — the units are man-days (real days, not "ideal" days):
- Small = 1
- Medium = 3
- Large = 10
- Extra-large = 30 (use for Quarterly Planning² only!)
- If you need a rationale or fancy sounding formula for the above, it is based on powers of three² — S=3⁰, M=3¹, L=3²+3⁰, XL=3³+3¹.
- I round up to the nearest 10 for two reasons of convenience:
- My preferred sprint length is 10 days.
- A task that will take two people one week to complete is worth 10 points.
👉 When estimating stories, prioritise utility over accuracy.
- It's a "guesstimate" — part bet, part prediction.
- Know as much as possible about the task, without making it a separate task to perform a detailed analysis.
- Know where the main effort needs to be expended, and identify the important risks.
👉 Calculate each team's sprint capacity.
- Your sprint capacity is the total number of originally estimated points in stories that were delivered, averaged over the last few sprints. Account for any significant absences or team-size changes during the participating sprints.
- Do not nitpick over actual vs. estimated story points, except if you'd like to improve your estimation skills.
- Remember to reserve a percentage of your capacity for unplanned work — but that's a topic for another post.
Thanks for reading this far! I will appreciate your comments, questions, suggestions, clarifications and especially corrections via this LinkedIn post.
__________
¹ From Jeffries' article Story Points Revisited. Jeffries was also one of the seventeen original signatories of the Agile Manifesto.
² Quarterly Planning is a topic I will cover separately — it is outside the scope of this post.
³ Why three? It works for me, but feel free to try a different number. Pythonists may recall the instructions for operating the Holy Hand-Grenade of Antioch, which demonstrate an ages-old fixation on the number three.
² Quarterly Planning is a topic I will cover separately — it is outside the scope of this post.
³ Why three? It works for me, but feel free to try a different number. Pythonists may recall the instructions for operating the Holy Hand-Grenade of Antioch, which demonstrate an ages-old fixation on the number three.