According to the 2020 Scrum Guide, “Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.” But how do you know whether you’ve sized your Product Backlog items such that the team can complete them within one Sprint? The Scrum Guide leaves that up to you.
One way is to estimate Product Backlog item (PBI) size. In a recent article, we talked about three ways to estimate: Exact estimation, relative estimation, and flow metrics. This week, I’d like to dive a bit deeper into the most popular estimation technique: relative estimation.
The most common way to implement relative estimation is by using points. Relative estimation arrives at an estimate by comparing each PBI to a standard-sized item. It is different from hour estimation in that it relies upon comparing similar PBIs to each other to estimate size rather than establishing an “exact” estimate. For example, you might size all text changes similarly, and all simple form updates similarly. When you need to size a new PBI, you compare it to a similar PBI within its category. Similarly sized PBIs get the same point value.
You might be wondering how a team selects a point system to use and how to assign the PBIs to the various levels. Let’s examine that next.
Step 1: Select point System
To select a point system, the team looks at the list of available options and selects one that feels comfortable. Pick one and give it a try. That’s all there is to it.
Here are a few of the most common point systems.
5-point estimation
This one is as simple as it gets. Teams use a scale of one to five as their point system. When estimating in person, a five-point estimation system makes it very easy for teams to share their opinion on the size of a story. The downside of this point system is that there are not many options to choose from, which doesn’t allow the team to estimate sizes granularly. However, what it lacks in specificity, it makes up for in simplicity! Scrum is all about keeping things simple, and teams often overlook the point system.
T-shirt sizes
This option uses the same groupings that T-shirt sizes do—small, medium, and large. If the team wants to map the sizes to a number system (to calculate velocity or the number of points they can close per Sprint), they simply replace small with 1 and medium with 2 and so on.
Fibonacci
Agile teams favor the Fibonacci numbering system for estimating. You create a Fibonacci sequence by adding the two preceding numbers. For example, if your first number in a Fibonacci series is zero, your Fibonacci sequence is as follows: 1, 2, 3, 5, 8…). This point system is popular because there is about a 40% difference between each number in a Fibonacci sequence. In daily life, humans generally can’t detect a size difference of anything less than 40%. For example, if you held a 1lb weight in one hand and a 1.2 lb weight in the other, it might be hard to tell them apart. You are far more likely to tell the difference once one of the weights tips to 1.4 lbs.
The Fibonacci system can be confusing to teams new to it, but being able to distinguish size differences makes it a popular choice.
Animals
I have worked with teams that have mapped different animals to the Fibonacci point system as a shorthand when discussing relative size. The number is just used behind the scenes (to calculate velocity, for example) but when they’re in discussions they talk about the animal. This system is fun, engaging, and more memorable for teams using it.
Tens
Teams can simply count by tens, designating the smallest item size 10 going up on the scale for subsequent items according to the team agreement. This system makes it very easy to calculate velocity for each Sprint.
Doubles
Teams can count by doubling the previous number in a sequence (2, 4, 8, 16 …). This point system allows teams to distinguish between the size of two PBIs more easily, but some people find it difficult to get their heads around it.
There is no right or wrong point system. Select a system that works for your team.
Step 2: Associate a sample work item with each level of the point system
Once the team has selected a point system, they need to decide which types of items to classify as a 1, 2, and so on. It is possible for the team just to use its judgment, documenting that information in their team agreements. Alternatively, let’s look at an exercise that can help your team create a point system organically no matter what’s in the Product Backlog.
Identify a representative list of Product Backlog items
Start by pulling together a small sample of PBIs from the backlog. This sample should represent your various PBI types. Depending on the size of your Product Backlog, you might pull a larger or smaller items sample, but 15-20 items is a good start.
Your list might look something like this:
Estimate High/Medium/Low
Next, for each PBI in your representative list, ask team members to estimate each one as small, medium or large for complexity, effort and uncertainty.
When you are done, your list might look something like this:
Group similarly sized Product Backlog items
Next, visually group similarly sized PBIs together. For example, if you have a PBIs that are small in complexity, effort and uncertainty, group these together Even if the sizes are not an exact match, they may be grouped together if they are similar in size. There should be about a 40% difference in size between each number on the point scale. To put that another way, each number on the point scale should have a PBI type associated with it which is noticeably bigger than the previous number on the point scale. Use your judgment when creating groupings; it should be easy to distinguish the size from one number on the scale to the next, but you don’t want such a big difference that you are not representative of the variability which actually exists in your backlog.
Assign numbers
Go back to the point system that your team identified and apply each point in ascending order to your groupings. For example, if your team had selected Fibonacci, your groupings would look like this:
Select a sample PBI from each Group
Select a sample PBI from each group and use it as the “example” item for each point size. Document this information in your team agreement so that if anyone needs to know what type of item should be a 5 in the future, this information is available.
And that’s it!
Your team can complete this exercise in two hours or less, depending on the number of PBIs you select as representative of your Product Backlog. Make sure you don’t spend too long assigning a high/medium/low estimate for complexity, effort and uncertainty.
You might choose to carry out this exercise in a stand-alone meeting or during refinement. Alternatively, you can use your retrospective to create this point system if the team decides that this is a good use of time. Regardless, ensure you document it all in a centralized location. If your team uses the complementary practice of creating team agreements, that’s a good place to document your point system.
Use your new point system
Once you’ve created a number system and established relative sizes, you can use it when new items arise during refinement. You will be able to determine the type of PBI the new one is similar to, and bam, you’ve got an estimate.
The benefits of relative estimation are that over time, as the team delivers PBIs estimated this way, they can get a sense of how much work they can actually deliver each Sprint using a calculation called velocity. You calculate velocity by taking the estimate for each PBI you delivered in a Sprint and adding them up.
For example, if the team completed five PBIs in a Sprint sized as a 1, 5, 1, 2 and 3, then by adding up the points assigned to each Done item, the team can learn that their velocity in the previous Sprint was 12.
Over time, the team may learn that they typically deliver between 10 to 15 points worth of PBIs per Sprint. This calculation helps improve predictability, the ability to plan a Sprint, and forecast delivery throughout multiple Sprints. This information is helpful because the team can only pull in as much work as they can actually deliver in a Sprint. The Product Owner can use this information to forecast how long it might take the team to deliver 50 or 100 points worth of work.
Keep in mind that most Scrum Teams will experience a level of variability—that’s why it’s called a forecast and not a plan! See forecasting for Scrum teams for more information about dealing with variability in estimates.
Conclusion
The best point system is the one that the whole team creates organically so that everyone understands it. Document your point system in your team agreements and revisit it occasionally to ensure that the team understands it and your point system continues to be representative of your Product Backlog.
What to learn more about Scrum?
Signup for one of Rebel Scrum’s upcoming classes:
Introductory class for those new to Scrum
Geared towards Scrum Masters coaching teams
Advanced class for Scrum Masters
For leaders and managers of Agile teams
Professional Scrum Product Owner
For Product Owners
Professional Scrum with Kanban
For anyone interested in learning about implementing Kanban principles within a Scrum team
Rebel Scrum offers both private and public classes to help you deliver value sooner to your organization. To sign-up for an upcoming class, view our class schedule. Contact Rebel Scrum to schedule a private training for your organization.
Comments