Before the introduction of money, exchanging goods could be challenging. How many chickens should I give you for a cow? What if I want your cow, but you don’t want my chickens? Our modern economy could not have existed if we were stuck with such barter trading. Then money was invented. It created an alternative to bartering and eventually replaced it.
Money simplified – and expanded the possibilities of – trade by distilling all the considerations that go into determining something's worth into one number.
Story points do the same for estimating and planning work.
What are story points?
Story points are a unit of measurement, just like time and money. Time measures duration, money measures value, and story points measure the estimated size of a piece of work, where size is the sum of multiple factors.
The concept of story points was originally developed by Ron Jeffries as part of the Extreme Programming (XP) agile framework. But they have since come to be used by teams that use other frameworks, like Scrum.
Teams may use story points during their backlog refinement or agile estimation meetings to give a clearer idea of how much work they can expect to achieve in each sprint.
Teams estimate a task's size by taking into account all the factors that could impact completion:
- 🏋️ The expected effort and expertise required to complete the work
- 💡 A team's experience completing similar tasks in the past
- ⚠️ Uncertainties, doubts, and risks at the moment of estimating
- 🐛 QA (Quality Assurance) tests and bug fixing that might be necessary to complete the task
- 📆 Workflow overheads in the form of communication, meetings, and admin work required to reach completion
Trying to compress so many factors into one estimate might sound impossible. But with a bit of practice, it's as simple as figuring out if the flat white at your local coffee shop is fairly priced.
You accomplish that feat in a split second when you see the amount, mainly because you subconsciously compare that price to a whole range of factors.
Some are obvious, like the pricing, quality, and your experience at other coffee shops. But there are also indirect factors like whether your current salary or the economic outlook justifies spending money on a fancy coffee.
It's similar with story points. Estimating them will quickly become intuitive and make your task estimation faster and more accurate than time-based estimation.
Why use story points in Agile?
Time is an outdated unit of measurement for estimating modern work because it's one-dimensional and absolute. It can't reflect all the unpredictable factors that impact the completion of tasks in complex projects, nor can it adapt to local conditions as story points can. What's more, cognitive biases mean we're apt to over-estimate how quickly we can achieve tasks.
Once your team fully understands story points, they lead to faster and more accurate estimates of your tasks than when using time. That's because story points are relative, account for the unpredictable factors listed earlier, and are applied at the team level instead of the individual level.
- ⚖️ Story points are relative because you arrive at their value by comparing tasks to other, already estimated tasks. "If that task is a size 2, then this one surely must be a 4, as it's twice as hard." Such relative estimation is much easier and faster when dealing with complex knowledge work than trying to fix precise values as you do with time.
- 💣 Story points account for unpredictability because they take into account risk, uncertainty, and a team's expertise and previous experience. We likely forget such elements when we estimate using time or only add them by spending many hours calculating various scenarios.
- 🤗 Story points are team-centric because they're based on a collective estimate from the team based on the skills and abilities of the whole group. A task will be estimated based on the abilities of the team as a whole, rather than how big or small it is for an individual. This is why teams running planning poker meetings usually discuss differences in their estimates to arrive at a middle-ground. When estimated in hours, that same task might take two hours for the senior person but ten for the junior.
How to use story point estimation?
The value of story points is rooted in the experiences of the team. One hour represents the same amount of time worldwide, but story points are more like money. There’s no universal value of currency and there's no one world currency. Most countries have their own currency primarily for use within their own borders.
Story points are your team’s currency, since they are used to discuss, size up, and reflect on work within your team, not to communicate between teams or to be compared.
Here's how to approach using story points:
1. Explain the concept to the team
It took us just over 700 words to get here and have a shared understanding of story points – or so we hope 🤞. You’ll need to make sure your team also understands the concept before you move along. Even with a basic understanding of story points, it’s easy for teams to default back to time-based estimation. Sharing this article before your first Poker Estimation session might be a good start. 😇
2. Establish what size task equals one story point
Take the absolute smallest task you'll ever need to estimate during your planning process and rate it as one story point. This item becomes your baseline task to which you calibrate subsequent ones. Over time, you can set other guides based on previous tasks. The hardest part is getting started without prior data to rely on.
3. Size up other unestimated items
Pick a different sized item from your Backlog and estimate its size in story points compared to your baseline task. Continue running through your Backlog in this way, comparing items to each other until you've assessed all their sizes. You can do this with an estimation method such as affinity estimation or relative mass evaluation. 💁
Wondering how to estimate tasks as a team? Read our article on agile estimation techniques such as the Fibonacci Sequence, planning poker, three-point method, and t-shirt sizing.
4. Create a sizing table for future estimates
Create a baseline story points matrix overview of various sizes you'll commonly use. You can help your team out by adding in one or more reference tasks for each size. Essentially, you're creating a gold standard for your team that you can refer back to when estimating work in the future.
5. Execute your Sprint and measure its velocity
You're now ready to start a work cycle like your regular Sprint. When you reach the end of it, add up the total number of story points your team completed. This number is your team's "velocity." Once you've completed several Sprints, measure your team's average velocity. You'll now know how much work your team can reasonably plan for one Sprint because you'll have a sense of the number of story points you can complete in each one.
6. Repeat steps 4 and 5 every Sprint
At the end of every Sprint you’ll have more data and experience to play with. So we recommend always:
- 📋 Updating your story point sizing table to reflect the latest information you have. As you start out with story points, your table might require some tweaking. The end of the Sprint is a great time to do that.
- 🏁 Calculate your velocity and compare it to the previous Sprint. Is it roughly equal? Did you blaze through more story points? Talk about why velocity may have gone up or down, and make amends to ensure you’re still planning the right amount of work with story points.
Your baseline matrix should not change much over time. But your velocity is likely to fluctuate during the first few sprints. Then its average might change gradually up or down depending on the goals you set as a team. But don’t expect\ your team’s velocity to increase sprint over sprint in perpetuity. This is not realistic and is a recipe for burnout.
You might, for example, make improvements to your working process that allow you to complete more story points in a Sprint, increasing your velocity. But
you could also decide to take on less work per Sprint so you can boost the quality of your deliverables. That would reduce your velocity, and the decrease would be positive.
📌 Reminder: If you’re a brand new team, your first few Sprints are likely to be slower. Team members need to get used to the codebase and to each other. In this scenario, you can expect velocity to rise over the first few months before plateauing off to a sustainable pace.
Avoid these pitfalls of story points
Story points are a tricky business at first, not unlike arriving in a foreign country with a currency you're unfamiliar with. It might take a few purchases and some calculations to realize that your first taxi ride from the airport to your hotel was a rip-off. But that shouldn't be a reason to give up on your trip and head straight back home. Stick around, and within a few days you'll know what's fair and what's not.
Here are some don'ts to get you around the most common hazards in story-point-land.
- ❌ Don't mix story points with hours or days. It's tempting to peg story points to time – "one story point = one day," but that defies their purpose. As soon as you do that, story points reflect an absolute measurement of time, not a relative size that's based on a combination of factors.
- ❌ Don't use numbers for story points, especially as a new team. To avoid conflating story points with hours or days, new teams can use a non-numerical proxy, for example, different sized animals, fruits, or vehicles like in the below image. Even experienced teams can benefit from this practice as it's hard to unlearn our time-based estimation habit.
- ❌ Don't compare story points across teams. Story points are a local estimation of currency for your team, influenced by your unique expertise, experience, and work process. When you try to make them universal across multiple groups, they lose their relevance for your team.
- ❌ Don't forget to review incorrect estimates. When an estimate turns out to be off, don't forget to bring it up in your Sprint Retrospective meeting and find the underlying cause. Maybe the baseline matrix needs a correction, or there's a factor you didn't take into account, like testing or bug fixing.
- ❌ Don't give story points just one Sprint to prove themselves. Story points take a few Sprints to get right. That means you shouldn't give up on them after just one try. Neither should you use them to give velocity estimates to other stakeholders before you've completed several Sprints.
Time estimation isn't superior just because it's simpler
Getting teams and organizations to grasp and implement story points correctly is a task similar in size to switching over cave-dwellers from bartering to money, or your parents from Dollars to Bitcoin. But the estimated size of the challenge shouldn't stop you from trying.
Time feels good as a unit of measurement because we have used it for decades to estimate and track work, so everyone instantly understands it.
But, as Einstein said:
"Everything should be made as simple as possible, but not simpler."
Barter trade is a simpler concept than money, but, for an advanced economy, it's too simple.
The complexity of modern work asks for a new way to estimate and measure tasks. Story points are the simplest possible answer to that problem.
Thanks to Rebecca Sassine and Maarten Dalmijn for reading drafts of this article and providing helpful feedback.