What is a story point? (ELI5)
TL;DR — A story point is a unit of effort required to complete a task / story, relative to other estimates.
Estimating how long it will take to do something is hard. Have you ever tried to tell someone exactly how long a project or task will take, only for it to take twice or half as long as you originally anticipated? Don’t worry, you aren’t alone. In fact, getting the numbers spot on is actually pretty rare.
For larger and more complex tasks there is greater potential for uncertainty as each individual component can skew the overall estimate of work involved.
This is down to estimates being delivered in units of time. Story points are usually based on arbitrary or made up units, specifically designed to decouple estimates from time, and reduce commitment.
Usually story points are assigned to stories, but at Scrumi our team likes to add them to tasks and bugs as well. If effort is required on something, it’s usually worth tracking the story points.
What is a story point for?
TL;DR — Removing emotional attachment.
Story points offer an easy to understand way of assigning effort to a task. This is just an estimate, so it doesn’t really matter if we are talking in hours, oranges, or courics. The important thing is how that number aligns with the rest of the estimates in your project.
“X is roughly double the amount of effort of Y”
This allows us to quickly estimate tasks (of which there may be many), and roughly quantify the uncertainty of the task without getting pulled into rabbit warrens of detail.
Now because we are thinking and talking in a made up unit, it instantly pulls the emotional attachment away from time.
Why not just use hours?
TL;DR — Humans are bad at estimating time.
As mentioned, if you talk in time, then a lot starts to ride on those estimates. People will start referring to them as deadlines and expectations. This will get passed up the chain, and before you know it your guess work will be coming back to haunt you.
One option is to just put more effort into making your estimates accurate, but to do this properly you need to research, tinker, forecast potential pitfalls, and often get stuck-in to come up with a realistic number. This causes you to lose agility, takes up more of your time, and ultimately can still be wrong.
When working on a task, it isn’t always linear progression.
“It’s often “write 90% of the code in 10 minutes and then tear your hair out debugging for 17 hours.” That’s pretty hard to estimate in the clock timing sense.”
Story points allow for best guess, leave margin for error, and take these unknown factors into account.
Story point considerations
TL;DR — Complexity / Uncertainty / Risk / Effort
So while a story point sounds vague, it can actually quite easily portray a bunch of factors that are hard to pin down with time alone:
- Effort
- Amount of work
- Risk
- Uncertainty
- Complexity
- Different departments point of view
All of the above make for good reasons to increase the number of story points on a story or a task.
Considering these factors is a team game. Your opinions may differ vastly depending on your exposure to a problem.
“During a round of planning poker, the programmers on the team might estimate this story at only two points, since adding a tooth-count column to a database table is a minor change for them. However, the testers might estimate this story at 13 points, since getting close enough to count a Jabberwock’s teeth to gather accurate fixture data is a dangerous (and potentially fatal) task.”
Story point poker / how to estimate agile tasks as a team
TL;DR — Pick a story, everyone individually estimates complexity and reveals their estimate, as a team compare notes, understand thoughts behind different estimates, agree on story points.
Going through the stories one by one, planning poker usually consists of:
- Picking a story
- Estimate the story, but keep it to yourself
- When everyone has a number in mind, reveal as a group. Be honest!
- Consider the variations, understand thought processes
- As a team, agree on a final number
Usually coming to a final agreement can be difficult. It’s important not to just pick the median number, or the best case scenario. Let common sense prevail and pick something the team can commit to.
How should story points be structured?
TL;DR — Fibonacci-like format: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100.
Okay, so not up to 11 as above, but use some kind of scale or sequence such as Fibonacci, or power of 2. This supposes that the higher the number, the less precise it is. This is fine, because as we mentioned earlier the more complexities to a problem, the harder it is to accurately estimate.
At Scrumi we use 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Math nerds will notice that this isn’t Fibonacci, but at a point we just round the numbers to remove the focus on accuracy. Eg 21 sounds like a specific number, but 20 is loose.
In my opinion, anything 20 or over should be broken down further into smaller tasks or stories. This can be handled later after the initial planning stage.
Conclusion
Story points allow for inaccuracy, in a world where precise estimates are difficult, time consuming, and improbable. The key is to move the focus away from time, into an abstract unit that prevents emotional attachment and waste.
Make sure you factor in the effort required, any potential for uncertainty, and risk of actually carrying out the task when considering the number of story points.
This lets your team quickly estimate stories, highlight potential pitfalls, and ensure a hive mind approach to estimation. Planning poker is improved by healthy debate and sharing of opinions / high level solutions.
Thanks for reading the Scrumi.io blog! Make sure you give this post your 👏 50 claps 👏 and take a minute to follow us on here and on Twitter if you enjoyed this post and want to see more.
Note: A lot of the above is generalising, and misses some in depth elements of story points. That’s fine, there are thousands of lengthy and complex articles discussing story point practises in great (usually too great) detail. Google is your friend :)
