- Managing the Product Backlog
- Collaborating to Groom the Product Backlog
- Ranking User Stories with a Dot Voting Method
- Illustrating User Stories with Storyboards
- Sizing User Stories Using Comparison
- Splitting User Stories Along Business Values
- Tracking User Stories with a Collaboration Board
- Delivering a Coherent Set of User Stories
- Planning Work with User Stories
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Sizing User Stories Using Comparison
The biggest and most common problem product owners encounter is stories that are too big. If a story is too big and overly complex while being a top priority, the sprint is at risk of not being properly completed. To avoid this issue, product owners must identify, as early as possible, if a user story is the right size and therefore ready to be built during a sprint.
It is not the responsibility of the product owner to estimate the work that needs to be done to complete each story. Only the development team can identify the size of a story. After the development team makes those estimates, the product owner can then determine if the story is too big. If that is the case, with the help of the team, she will split it into smaller stories.
To estimate the size of the top stories in the backlog, the product owner must organize recurring backlog grooming meetings. All the members of the development team must attend these meetings. To answer any questions addressed during these meetings, subject matter experts (stakeholders) should also participate. Before the meeting occurs, the product owner prioritizes the story list, thereby ensuring the most important stories will be estimated. The meeting is then time-boxed, at usually one hour, and each story is considered. Don’t worry if you don’t have time to discuss all the stories in the backlog. They will be addressed in future meetings.
Sizing a story requires that the development team estimates the work to be done to complete it. This should be simple, but unfortunately human beings are not good at estimating. Actually, we are not good at all. Cognitive scientists tell us that our brain is wired to imagine the possible. We are reluctant to identify limitations, especially if they are not obvious. It seems that we are too optimistic, and indeed, we would not have survived the evolution of our species without this trait. With this bias built into our genetic background, it is almost impossible for us to accurately estimate, at least in a short time. It is obvious that with a lot of resources and enough time, humans just get there. However, this is not our case as we seek to estimate a user story in less than 5 minutes.
Does this mean that the development team should not estimate? Yes, at least according to what the word “estimate” means today. I propose that you estimate differently. Stop measuring absolute values and start comparing relative values. When estimating, you should not measure effort but instead compare efforts using a reference point.
Humans are poor at estimating absolute sizes. However, we are great at assessing relative sizes. For example, imagine that a team must estimate the weight of a young child and an adult. It will be difficult to agree on the exact weight of each. However, it will be extremely easy to decide which one is heavier.
When you measure stories, you need to be concerned with only relative sizes. You can easily do this by using the Fibonacci sequence or series, which is “A sequence of numbers, such as 1, 1, 2, 3, 5, 8, 13..., in which each successive number is equal to the sum of the two preceding numbers”. What is of interest, in this sequence, is the ratio between any number and its counterpart. This series gives you a relative size you can work with to compare effectively.
Our cultural tendency is to estimate based on how many hours it will take to complete a story. Unfortunately, estimating using duration reduces the team to measuring absolute values, which is what we want to avoid. Because of our incapacity to anticipate the unknown and to predict risk, we should steer clear of estimating based on time. There are three reasons for this:
- The time necessary for teams to build one unit of work fluctuates from sprint to sprint. In a complex situation, there is no other choice than to work collaboratively. When a member of the team is absent, due to vacation periods or members leaving the team, the team’s capacity to deliver changes. As a result, if you measure effort based on the number of hours, you must perpetually revisit the estimates in the backlog.
- Estimating based on time requires you to take into account the slack time. This adds accidental complexity, which results in a more imprecise measure. Factoring slack time appropriately is difficult. You must take into consideration the fact that people have to check their emails, participate in other meetings, eat lunch, take breaks throughout the day, and so on.
- Each team will gauge risks differently. Some will plan for a large cushion of time to mitigate risk, whereas others will approach the challenge without compensation.
The best way to evaluate effort is to use a degree of difficulty summarizing numerically the effort, complexity, and risk. For every degree of difficulty, you will assign points. Story points are independent of variations engendered by units of time. Furthermore, they are the perfect unit for comparing relative values.
The challenge of using a points system is calibrating what the number of points means. Some team members may think a story is worth one point, whereas others may think it is worth 10 points. So, how do you solve such a problem? One of the ways of calibrating stories, and getting a joint agreement by all team members, is to look at previous examples of stories as a referential. The team ranks the stories from most difficult to least difficult. The most difficult will have more story points than the least difficult. The goal is to end up with representative stories of 1, 2, 3, 5, 8, 13, and 20 points. After those representative stories have been identified, the team can then decide how many points the new stories should be awarded. Calibrating by story points enables a team to easily reach a consensus.
During backlog grooming meetings, you want insights from all team members. As a result, you should favor a consensus-based estimation technique. A well-known and effective technique is the planning poker technique. It was first introduced by James Grenning and later popularized by Mike Cohn in his book, Agile Estimating and Planning 3.
Approach this technique as though you were playing a game of poker. Each bet should target one story. Before each bet, the product owner presents a short overview of the story and demonstrates the storyboard to define the success criteria needed to finish it. While answering questions posed by team members, the product owner enhances these criteria, which could double or even triple the work needed for each story. When the question period is over, the Scrum master then chairs the meeting and gives each team member a deck of Fibonacci cards, as shown in Figure 5.5.
)
Figure 5.5. Deck of Fibonacci cards.
The idea is to have all participants use one of the Fibonacci cards to give a rough estimate of how many points she thinks a story is worth. When betting, everyone turns over their card simultaneously so as not to influence others. Those who have placed high estimates, as well as those who have low estimates, are given the opportunity to justify their reasoning. After the members have explained their choices, the team bets again until a consensus is reached. This estimation period is usually time-boxed at five minutes by the Scrum master to ensure structure and efficiency. If consensus is not reached within the set time, the product owner moves to the next story where the betting process begins again. The goal is to address and reach an agreement on as many stories as possible within one meeting.
When the meeting is over, the product owner takes into consideration the number of points assigned to each story. Some stories may be worth 20 points, whereas others are worth 5 points. The product owner must determine which stories are too large and therefore need to be divided into smaller stories. Splitting large stories allows the development team to approach each smaller story in a more productive manner.