How to Estimate an Agile/Scrum Story Backlog with Points

When you’re trying to get started on your first agile/scrum project, it’s easy to find arguments about why it’s a good approach. But it’s a lot harder to find clear, step-by-step explanations of the tools and processes you need to succeed. I’m trying to fill that gap by answering the question: How do you estimate story points on an agile/scrum project?

A Little Context

The goal of agile/scrum estimation

We estimate story points to give ourselves a rough idea of when we’ll be done with important chunks of our work. At Atomic, we’re always interested in having the best understanding of this as soon as possible so we can make informed tradeoff decisions before it’s too late.

We do our best to understand how much work we have in front of us (through estimating) and how much we think we can get done every couple of weeks (through measuring velocity). Combining our estimates and velocity, we can project a range of when we can get our work done, or how much work we can get done by a specific date.

In summary, we estimate to feed the equation of velocity/estimated points = projected completion.

A few terms

Anyone familiar with an agile project should recognize the terms below, but they might be a nice refresher for folks newer to agile methods. This list is by no means comprehensive for any one framework or process, but it should be enough for the topic of estimation.

• Backlog – A prioritized list of items for the product dev team to accomplish and deliver. This can be implemented as a spreadsheet, note cards taped to a whiteboard, or with a tool like Trello or Pivotal Tracker.
• Backlog Item – A task on the backlog list. At a minimum, each backlog item should have a title, details, estimate, and type. Types of backlog items can include:
  • User Story – Represents a new feature or enhancement to the product that tangibly changes the end user’s experience.
  • Bug – Same as above, but a correction of unexpected behavior vs. new desired behavior.
  • Chore – An item that won’t result in a noticeable difference in user experience or be verifiable by a product owner, e.g. integrating with an error logging service or implementing a new backup & restore scheme. A chore could also involve work required to inform other items, e.g. writing a proof of concept integration with a payment provider or gathering a list of potential text recognition libraries.
  • Points – A number reflecting how big an item is compared to others in the backlog. An item’s size can reflect the relative complexity, the amount of work needed to complete it, and/or any risk factors.

How to Estimate the Agile Way

1. Set an estimation range

I like to use the following range of point values: 1, 2, 3, 5, 8, 13, 20, 40, 100. When printed as cards for playing planning poker, I like to include a “coffee” card to signal for a break (estimating a lot of stories can be exhausting.)

This range has two logical sets:

• 1, 2, 3, 5, 8, 13 – The lower numbers are typically assigned to items when teams have a decent vision for how to tackle them. Their size tends to be more determined by complexity and perceived effort to complete.
• 13, 20, 40, 100 – These numbers are usually attached to stories which will need to be broken down. Their size tends to be determined more by risk and unknowns.

I intentionally leave out 0, 1/2, ?, and Infinity options. Focusing on 0 and 1/2 encourages teams to spend more time debating the size of the tiniest items with the least impact on cost and timeline.

Including ? and Infinity allows teams to avoid quantifying the perceived risk of an item. I get that Infinity is quite a bit larger than 100, but since I can’t sum Infinity with other point values in the backlog, it won’t affect my backlog point total as it would if it were a 0. As a product owner/backlog manager, using a system where the most risky items in a backlog increase the backlog point total motivates me to de-risk and break down those items.

2. Set some reference points

When you’re tackling a brand new backlog of un-estimated items with your team, it can seem daunting. Start by looking through some of the better defined items or those where the team has some idea of how to tackle them.

First, find an item that’s small in size, but not the smallest item—that’s your first 2-point story. Then find another story that’s between 2x and 4x the size of your 2-point story—that’s your first 5-point story.

It’s usually easier to do this without formal planning poker. Just pick someone to lead the exercise of asking the group to agree or disagree on the 2-point story and then the 5-pointer. Remember, points are an estimate of relative size, not duration in time to implement.

3. Estimate stories with planning poker

Approach estimation sessions as a triage exercise. Don’t get bogged down in fleshing out item details—that’ll be important to do later, but it will only make estimating drag on and on.

Here’s a good approach to in-person planning poker that can help curb analysis paralysis common during estimating:

• Choose someone (often your product owner) to read the backlog item title and description. No one else can talk, and the designated person shouldn’t elaborate any further.
• Before discussion begins, everyone on the team should choose an estimate card and place it face down in front of them so everyone can see when all team members have chosen a number. If you’re stuck between two numbers, choose the larger one.
• Once everyone has chosen a card, ask them to reveal their estimates simultaneously.
• If everyone chose the same number, record it as the estimate and move on to the next item–seriously, don’t dwell on it any longer!
• If the numbers vary, ask the lowest and highest estimate holders to make a case for their perception of the item’s size. Brief follow-up discussion is OK here.
• Return to Step 2 and repeat the hand of planning poker. Alternatively, if all team members verbally agree on an estimate, it’s OK to record and move on, but don’t let debate continue for more than a couple of minutes without calling for a re-vote.

If you’re stuck between two numbers in your scale, always choose the larger number. Focus on determining a number the team can agree on, not a detailed breakdown of the item.

4. Estimate bugs, chores, and spikes

Estimates represent the size of an item’s cost, not the value subsequently created. Since bugs, chores, and spikes cost time and money (just like user stories), they should be estimated—if they’re planned and intermingled in the backlog with other items.

The one exception to this rule is: IF a bug, chore, or spike represents emergent work that must be completed in the current sprint, then it doesn’t need to be estimated. In this case, it could be interpreted as noise and distraction from the originally planned work for the sprint.

How to Tackle a Big New Backlog

If your team is getting ready to start a three- to six-month project, you probably have a long list of un-estimated items in your backlog. Here are a few tips that’ll help you get over the initial hurdle of estimates.

Set aside a couple of days

You’ll need at least one to two days for your team to estimate a three-month project. I recommend planning for the sessions up front. Build in breaks, get snacks, and estimate, estimate, estimate until you’ve made it through the whole backlog.

Use the big numbers: 20, 40, 100

Avoid skipping estimating items “until we have more info” or breaking down items “so we can more accurately estimate them.” If something feels too big (“A user can view reports”) or risky, use the larger number estimates to communicate that risk to your product owner.

Also, any time your team puts one of the three large estimates on an item, consider whether you can add a time-boxed chore to your backlog that’d gather enough knowledge to re-estimate or break it down later.

Take breaks as needed, then keep going

The first few sprints in a project are key to establishing team velocity. If those first sprints are encumbered by catch-up sessions to estimate the rest of the backlog, their velocity won’t accurately reflect the team’s capabilities. That’s why, even if everyone really wants to just get started building, it’s very important to get the first round of estimates done for the entire backlog before starting Sprint 1 in earnest.

As I suggested earlier, I encourage the use of a “coffee” card to take breaks. Let your team drive them as needed. And consider ending the day a bit early to let folks catch up on email and recharge.

Comparing Actuals to Estimates

Don’t do this. If you think an item was grossly mis-estimated after it has been delivered, ask the team about it during a retro–it might yield an interesting learning opportunity. Most items of the same point estimate won’t take the same amount of time.

Keeping track of a good team velocity is more important than scrutinizing estimates as if they were commitments–because points estimates are not commitments.

Happy estimating!