Story points 101: your guide to getting started

While intuitively straightforward, adopting this method does require some initial groundwork. Today, we're going to delve into how to introduce story points estimation to a team, ensuring you're well-equipped and off to a great start. Whether you're transitioning from another estimation method or starting from scratch, this guide will set you on the path to success.

Before diving into the estimation process, it's crucial to explain why it matters. Some teams might be resistant initially, fearing that estimation will introduce rigid deadlines or increase their workload. That's why it's so important to clarify that in Agile, the main purpose of estimation isn't to construct strict schedules or Gantt charts.

Instead, the goal is to foster meaningful conversations about work and develop a shared understanding of the overall scope. Once your team gets the hang of story points, the estimation process should flow smoothly, typically taking less than a minute per work item. This clear communication will help alleviate concerns and set the stage for successful adoption of story points.

The key to successfully implementing story points is understanding the fundamental principles they are based on. It's crucial to explain to your team that:

1. Story points consider time, complexity, and uncertainty,
2. They are not actual units and cannot be converted into time,
3. They follow a modified Fibonacci sequence, with an intentional and growing distance between the larger numbers (1, 2, 3, 5, 8, 13, 20, 40, 100).

An effective way to illustrate these principles is the 'fruit salad' analogy. Imagine each fruit as a task. You could compare the fruits using weight, volume, or other tangible measures. However, preparing each fruit for a fruit salad requires considering the work involved (rinsing, peeling, dicing, or even cutting into star shapes) and the uncertainty (you don't know the size of the strawberries, so you might have to cut them into small pieces or just halves). You can compare the fruits to each other and assign each a value on a scale, considering all these factors. But it's nearly impossible to measure precisely how much effort each fruit will require.

Similarly, story points give us a tool to gauge the relative effort of work items in a manner that's far more nuanced and practical than raw time estimates.

Now comes the fun part! Gather your team and pick a work item that will serve as your baseline, your '5' on the story points scale. The chosen task should meet the following criteria:

1. Everyone in the team understands its scope. I recommend choosing an already completed task as this guarantees full comprehension of the task's scope.
2. It's neither too large nor too small, representing an average task size in your team.
3. It's something that can ideally be completed within less than a week. If your average items take a week or more, I strongly recommend trying to break them into smaller tasks.

It's important not to overthink this step. There's no right or wrong choice here. Once you've picked an item, congratulations! You've established your baseline and are ready to start using story points for estimation.

Now that you have a baseline, it's time to dive into the actual estimation process. First, choose the most relevant work item from the top of your backlog. Don't overthink the selection, just focus on the tasks that seem most urgent.

Start by clarifying the context. The Product Owner or the person who proposed the task can provide additional details, and team members should feel free to ask questions. This might be the point when you realize your work items - whether they're Jira tickets, Trello cards or something else - might be lacking crucial details. If people are unclear about what needs to be done, that's something to address during your next retrospective!

When it's time to vote, do it simultaneously. If you're working together physically, you can use planning poker cards. For remote teams, tools like Team O'Clock or PlanningPokerOnline.com can be useful.

During the voting, you're comparing the new item to your baseline. If it's slightly bigger, it's an 8, if it's significantly bigger, it's a 13, and so forth.

Once the votes are in, look for outliers. If everyone agrees on the number (which rarely happens initially), assign that story point value to your work item and move onto the next one. If there's disagreement, the team members with the highest and lowest numbers should explain their reasoning. After a brief discussion, hold a second round of voting, then move on. This is another opportunity to discover differing opinions on scope and work towards alignment.

The first few estimation sessions might feel a little awkward and time-consuming. Discussions could run long, and there might be some confusion initially. Don't worry, it won't always be like this.

In fact, these early struggles are often signs that you're uncovering issues with how you define the scope of work. This is a great opportunity to start introducing tools like user stories, acceptance criteria, and Definitions of Ready and Done. However, be cautious not to introduce too many new concepts at once, as it can overwhelm the team.

By your second estimation session, aim to estimate enough work for one week, or for one sprint if you're working in sprints. This allows you to start tracking your velocity as well.

Gradually, estimation will become a routine part of your team's process, and you'll find that it takes up only a few minutes of your time. The key to successful implementation is consistency. Keep practicing, and you'll see the benefits of story point estimation unfold.

In the world of story point estimation, there are a few key rules to follow to ensure you're using the tool effectively and maintaining the spirit of Agile.

1. Never compare teams' velocities.

Remember how we picked the baseline somewhat arbitrarily? Each team's baseline will be completely different, so a team that completes 300 story points per week is not necessarily better or worse than a team that completes 20.

2. Never estimate as individuals.

Estimation should always be a group exercise – the main purpose is to have meaningful conversations and break down silos. Even if there's only one designer in the team, for example, they should involve other team members when estimating their tasks. This helps everyone get a clear idea of the scope of work and what everyone else is working on.

3. Always vote together and don't let anyone voice their estimation before the vote.

The goal is to have unbiased opinions shared and discussed. Consider an intern who may have insights others don't and believes a task to be a 13. They may feel unable to contradict a senior team member who has already declared it an 8.

4. Don't average out votes; stick to the scale.

If votes are split between 8 and 13, don't go for 10 or 11. We have this scale precisely because we agree we can't be precise when it comes to large work items. If you're unsure, simply go for the larger number.

5. Don't overthink small items.

Debating whether a task is a 1, 2 or 3 isn't worth your time. Just assign the higher number and move on. Some planning poker decks have a 1/2 card - I recommend getting rid of that one immediately, as it's not worth anyone's time to discuss whether an item is 1/2 or 1.

6. Resist the temptation to make "1" your baseline.

We choose 5 for a reason - it allows us to go both ways up and down, making it easier to fully grasp the concept of relative estimation. If you start with 1, you may be tempted to use it as a measurement unit, which is not what we want. Instead, we simply compare whether each new item is smaller or bigger than the previous one, and place it in the appropriate bucket.

7. Never measure "individual velocity" - how many story points each person completes.

People on a team have different levels of seniority and experience, and senior team members often spend time coaching, mentoring, and enabling others. Calculating personal velocity won't give you an accurate view of how much work each person is doing and could potentially cause tension within the team.

8. Don't try to "improve velocity".

Your team is already working hard and completing a significant amount of work. Pushing them to do more isn't a productive goal. Instead, we should strive to better understand customer value, prioritize effectively, reduce waste, and focus on delivering better outcomes. If you start trying to increase velocity, you'll likely just end up shifting the scale - what used to be a "5" becomes an "8", making it look like the team is getting more done when that might not be the case.

9. It's okay to change an estimate later on, but don't overthink it.

If you realize that an item you estimated as a "3" is actually a "13" because you missed something, you can change the estimate. However, don't waste too much time re-evaluating estimates repeatedly. As long as the scope is clarified, the estimation has served its purpose.

10. Don't treat estimation as a team's commitment.

For example, if you measure a team's velocity as 50 story points per week, and they estimate a large project as 200 story points, don't automatically expect it to be completed in 4 weeks. Estimates are not always accurate, and there are often interruptions and urgent work items that come up. If you need the team to commit to a specific delivery date (and consider carefully whether you really do – deadlines can be problematic), then you need to have a conversation about this and get an explicit commitment from the team.


In conclusion, I hope this guide has provided you with a wealth of useful tips and the tools you need to get started with story points estimation. This technique can be an incredibly valuable asset to your team, helping to improve transparency, foster better communication, and reveal any hidden issues that may be impacting your team's performance. I strongly recommend giving it a try - you might be surprised at just how beneficial it can be. Best of luck on your journey towards more efficient and effective Agile work estimation.