A key feature of the Scrum framework is the ability to plan our sprints and releases by evaluating the work capacity of our team. This becomes much more difficult if we don’t have a standardized way of estimating the size of our tasks. In this article, we will cover the two most common approaches to product backlog item estimation, story points and ideal days.
What Is A Product Backlog Item?
The product backlog, or the desired list of functionalities for our product, consists of Product Backlog Items, or PBIs for short. PBIs are mostly features that will provide a tangible value to the end-user or customer and are often written as user stories. They could represent something brand new (like a login screen for a new website), or an update of an already existing feature (an update to the loading screen of an older website). Additionally, PBIs can include defects that need repair, technical improvements, or knowledge acquisition.
User stories are a way of representing PBIs so that they can be easily understood by both the business and the technical side of the company. They are written from the user’s perspective and clearly state what the feature is, as well as the benefits it will have to the end user.
Characteristics Of A Good Product Backlog
When managing your product backlog, it’s important to keep in mind some basic principles that constitute a good backlog. Those principles are contained within an easy-to-remember acronym, DEEP.
1. Detailed Appropriately
Not all items will be at the same level of detail at the same time. As a story progresses through the backlog it should become more and more detailed so that the items at the top of the backlog are very specific and elaborate so that they can be worked on in near sprints, and the things at the bottom are broad and more extensive. As a larger item progresses it will be broken down into smaller and more specific items that can be worked on.
2. Emergent
As long as the product is being developed or maintained the backlog should never stay frozen. Through the process of grooming, new PBIs are constantly added, old ones are refined, and some are even discontinued. It is very important that the backlog is updated frequently and failing to do so can cause a mountain of problems down the line.
3. Estimated
Now comes the product backlog principle that interests us the most in the context of this article. Each PBI should have a size estimate that represents the amount of effort needed to complete that item. The product owner then uses this estimate as one of the several inputs to determine the priority of an item in the backlog.
4. Prioritized
Even though the product backlog is a prioritized list of PBIs, not all items should be subjected to careful prioritization. If an item is scheduled for Release 2 or 3, it might be wasteful to dedicate time and resources to prioritizing it so far in advance as a lot of aspects of our project may change. As a general rule of thumb, you should try to keep your prioritization efforts confined to the items scheduled for the current release.
PBI Estimation Concepts
Before we dive deeper into tools you can use to estimate your product backlog items, let’s quickly reflect on 4 important concepts that you should keep in mind while conducting the estimation:
- Estimate as a team: The whole team should participate in the estimation process as this is one of the principles connecting Scrum with Agile, it’s methodological parent. The product owner should be there to describe the PBIs and provide any clarification that is needed, however, the development team should provide the final estimation as they are the ones that will be doing the work.
- Estimates are not commitments: If estimates are treated like worker commitments, the workers will in most cases overestimate the effort to not risk breaching the due date and incurring some penalties. For this reason, estimates should stay exactly that, estimates.
- Accuracy over precision: We should aim for the estimates to be accurate, without being overly precise. In other words, they should be in the ballpark of the actual effort that this item will take to complete. Aiming for precision will often expend too many resources without providing much additional benefit.
- Relative size estimation: The estimates should be size comparisons to other items and shouldn’t be in the form of absolute sizes as people are generally much better at the former.
What Are Story Points?
Story points measure the magnitude of a PBI by taking into account the size of the item as well as its complexity. Some items may not be that large but are deeply technical and complex, while others are large but fairly trivial. These stories represent different challenges, however, they will require a similar amount of effort. That’s why both of these parameters need to be taken into account. The final goal of story points is to be able to say “If story 1 is two story points large, then story 2 is an eight”, implying that story 2 is four times the size of story 1.
When our story sizes are properly estimated, we can use our team’s average velocity (the average amount of story points our team completes in a sprint) to calculate how many sprints it would take to complete some parts of our backlog. We can do this by taking the total story points from the PBIs in that part of the backlog and dividing them by our team’s velocity.
Pros of story points
- It’s much easier to estimate velocity than with ideal days
- It abides by the “relative measures only” rule for product backlog items much better than ideal days
Cons of story points
- Abstract and harder to understand- It’s Harder to get a time estimate and create a schedule
- It will require a decent amount of work to educate the team and the stakeholders about this method
What Are Ideal Days?
An alternative approach for estimating PBIs is to use ideal days, or the number of effort-days or person-days that are needed to complete a story. One thing that you should keep in mind is that ideal days are not the same as elapsed time, they represent the number of days a team or a person will take to complete the story if they had no other distractions or interruptions.
Pros of ideal days:
- It’s intuitive and concrete
- Clients and stakeholders understand it more easily than story points
Cons of ideal days:
- People are usually bad at estimating time
- Risk of stakeholders misinterpreting ideal days as time commitments
Which Is Better, Story Points Or Ideal Days?
This question doesn’t have write or wrong answer. The best thing you can do is evaluate the pros and cons of each of the characteristics of your team. Even trying out each of these for some time wouldn’t be bad as you can better get a grip on what works better in your context. I tend to sway in the direction of story points primarily because of the advantages it has when it comes to calculating velocity, as well as the great risk of ideal days being misunderstood as commitments.
Even though most teams tend to go for story points these days don’t let that stop you from trying other approaches and determining what’s the best approach for you and your team!
Also published here.
