13.4 Backlogs & Sprints 🎯
This section includes a mandatory Activity 🎯
A big part of your role as a product manager will be maximizing the use of your developers' time. You will do this by maintaining a prioritized backlog of user stories. Then, you will work to make the stories developer-ready and assign them to your team. This process is known as backlog refinement and sprint planning.
In this checkpoint, you'll learn about planning sprints, preparing stories, and refining the backlog for your development team. You'll also learn about common issues product managers face during this part of the development process.
By the end of this checkpoint, you should be able to do the following:
- Knowledgeably discuss the process of refining a backlog and planning a sprint
Backlog refinement​
Developers rarely use the first version of user stories and epics. The team uses feedback, discussions, and other information to refine stories and epics into their final versions. A company's or team's priorities may shift as well, and the product manager may need to update the backlog or modify user stories as a result. It's also important to remember that user stories are ultimately a communication tool designed to improve product development. If a story isn't clear enough to the team working on it, it should be refined until it is.
The process of getting your backlog and user stories prioritized and ready for developers is called refinement. You may also hear the term backlog grooming—this is a previously used name for the same thing (many people still use grooming, although the terminology was officially changed in the Scrum Guide between 2011 and 2013).
Refinement is all about organizing the backlog, prioritizing and revising user stories, and preparing the stories for developers. The product manager (or product owner) completes one part of the refinement process on their own and then collaborates with others to finalize the process. Individually, the product manager prioritizes the backlog, ordering the work to align with the company's goals. They break down epics and user stories into a reasonable size so that they can start time estimate discussions with stakeholders. User stories should have enough detail to be useful but shouldn't include extraneous information that would distract from the objective. As you gain product management experience, you will develop a sense of how to strike this balance. Then, the product manager works with their team—developers, designers, and possibly PM peers—to review the refined backlog and top-priority stories and epics.
The team should address the following questions:
- Does each user story have a clear expected outcome? Is it clear why the team is working on it?
- Are the stories and epics prioritized correctly? If not, what stakeholder input is needed to reorder them or verify the prioritization?
- Are there any blockers (obstacles or issues) that will prevent the team from working on a story or epic? For instance, does the team need to do more research? Does the team need to complete other stories before they can work on the stories that are on deck?
- Are the stories and epics the right size? Should any stories be split up (or sliced) or combined?
As you can imagine, the process of bringing your prioritized backlog to the team for discussion can be emotionally challenging. After all, you've already invested lots of time and energy in refinement. Many new product managers will struggle with the team questioning their prioritization and the way the user stories were initially drafted. But to become a truly successful PM, you need to recognize this difficulty and figure out how to set aside any defensiveness. Your initial work is crucial and lays the foundation for development. But it's also critical that you constructively incorporate your colleagues' feedback—this helps you build rapport with your team and move forward with the best implementation solutions.
Following the review with your team, you should update the backlog and revise the user stories accordingly. These refinement meetings should occur on a regular basis. Typically, refinement meetings take place one week before a sprint planning meeting—this gives the product manager time to complete follow-up work and make any necessary updates.
The video below provides more insight into how to successfully refine your backlog.
Sprint planning​
Another regular team meeting led by the PM is the sprint planning meeting. During sprint planning, the team reviews upcoming, top-priority stories in detail—most likely only those they'll consider working on in the next sprint. Team members confirm estimated story points and pick stories to complete during the sprint. All the team's developers, not just the leads, participate in sprint planning.
But how do you organize a sprint planning meeting? Reviewing the epics and other top-level goals with the team is a good way to start a sprint planning meeting. This helps give context for the stories to be discussed and keeps everyone focused on the overarching priorities. It is also helpful to share new data or other analytics and explain how it relates to the team's work.
Next, the team should assign story points to any upcoming user stories that don't yet have points assigned. To nail down those estimates, you can play planning poker with your team. Before the meeting, print a set of cards for each team member with one of each type of point, based on your team's story points system (for example, if your team is using T-shirt sizes, cards should read small, medium, large, and extra-large). Include an additional card with a question mark (?) for each person.
In the meeting, describe each user story, then let everyone consider for a moment the time and effort that story requires. Ask them to choose the card with the appropriate story points. At this point, team members keep their card choices secret so as not to influence each other's estimates. After everyone has picked their card, you will count down from three and have everyone reveal their selected cards at the same time. Set the story's points as the average of the points that have been selected.
Some stories require more discussion. If a team member is unsure about an estimate for a story, they'll choose the question mark card. This should lead to an in-depth discussion about the user story. After the discussion, have the team pick cards again. Similarly, if you find that there's a wide range of points—say 1, 2, 8, 8, and 13—you should discuss the story and repeat the process. Finally, imagine that the team decides a story is really large; for instance, your five team members pick 13, 13, 21, 21, and 21. This indicates that the story is too big and must be broken down into smaller user stories.
Once the team has assigned points to upcoming user stories, they will select stories to work on in the next sprint. The team commits to completing the selected number of story points and those specific stories in the next sprint. But how do they make this decision?
Some of this will come with experience. Once a team has gone through a few sprints, they will have a good sense of the number of points they can complete per sprint. In agile development, this measure of productivity is called velocity. Velocity is calculated by averaging the number of completed story points over the last four sprints. Plotting velocity over time lets a team monitor their productivity and identify patterns or changes.
The graph below is a velocity chart. It shows the number of points the team committed to compared to the number they actually completed in each sprint:
What can you see in this chart? You'll note that the completed story points increased during the last few sprints, which indicates that the team's velocity is improving. The number of points committed also went up. That can happen when additional developers are added to a team or when internal changes increase team productivity.
In the first three sprints, the number of points completed was lower than the number the team committed. That means the team was overcommitted—they overestimated the number of story points they were able to complete. When this happens, the team should adjust the expectations they are setting to a more realistic level and decrease the number of points they commit to for the next sprint. If the opposite occurs and there are more points completed than committed, that means your team undercommitted and should increase their committed points in the next sprint.
It may take a little time for you and your team to settle into a groove, and it's okay to miss the mark in the first few sprints. If you're not sure what velocity to use at first, make a reasonable estimate with your team. As you monitor the gap between points committed and points completed, you will learn more about your team's velocity and improve your estimates.
Common issues during refinement and planning​
The problems encountered during sprint planning are often similar to those encountered when creating and getting feedback on user stories. Fortunately, product managers can use similar strategies to guide their team through these issues.
A story is too big​
When a user story requires technical work that you, as the product manager, weren't aware of, the number of points your developers assign it will be larger than expected. This happens a lot. For example, the user story "As an account creator, I can choose my preferred method of contact in my settings" seems pretty straightforward. But, if that area of your product—especially the database—isn't set up to support a pulldown field, it may involve more work than you anticipated. In addition to the frontend interface for users to input the information, your team has to make changes in the database and build the connections for transferring the new data. What seemed like an easy story can turn out to be a lot more complex.
The best way to handle this situation is to break the too-big story into the individual pieces involved. How do you do this? Start by asking your developers, "What work needs to happen to accomplish this story?" Identify the specific dependencies that can become their own user stories and assign points to those smaller stories. If any user stories are still too large, go through the process again until the user stories are of reasonable size.
Lots of questions​
Sometimes when reviewing user stories, the team will get stuck on one of the stories. Maybe the story is unclear and the team is asking a lot of questions in an effort to understand it. Or perhaps a few of the developers pulled out the question mark card when assigning points. Or maybe someone asked about an ambiguous part of the story, and you don't have a good answer.
In all of these cases, it's a sign that the user story needs clarification and additional details. Discuss what's needed with your team. Ask your team, "What additional information do you need so that you can estimate this story?" Work with them to figure out what is missing. Sometimes it is something simple and can be provided during the meeting. At other times, that user story will need to be postponed until you can resolve the issues and bring back a version of the story that is clear enough for your developers to work with. In these cases, move on to other stories in the backlog that are ready to go.
Disagreements about prioritization​
Sometimes, a team member will disagree with the prioritization of user stories. One common reason for a disagreement stems from the difference in the amount of work the stories can take. For example, imagine that two of your upcoming stories propose a change in the database. One story involves adding a new table to the database, and the other involves optimizing the database. In your original priorities, the optimization work was given higher priority over the new table. Your developers, however, recommend swapping the order. Adding the new table, they say, is easy to do while the optimization will take much longer and will block the new table work. Getting this information is helpful, and that's why sprint planning includes the whole team.
Another common reason for prioritization disagreements is that the team doesn't understand the prioritization rationale. For example, if there's an upcoming project that the development team is excited to work on, they may be reluctant to put it aside in favor of other items in the backlog. Depending on the situation, the disagreement may influence you to shift the prioritization of user stories. Or, you may have to explain the factors influencing the prioritization that outweigh their objection. Reviewing the top-level company goals and KPIs is a great way to keep the team in sync. Your goal is to always provide your team with the why—establish a clear connection between organization goals and the prioritization of user stories in the backlog. This puts their efforts in context and ensures that everyone is on the same page.
Activity 🎯​
Read through the following common scenarios. For each scenario, write up a short list of the next steps you would take.
- Your team is overcommitted for your current sprint. Two stories have hard deadlines you must meet, but during sprint planning, it becomes clear that the team can only complete one.
- When reviewing one story, several developers put out the question mark card for points.
- Your team uses T-shirt sizing. On one story, your team puts out the cards: XL, XL, L, XL.
- A few of the developers on your team will be on vacation or off for holidays over the next few weeks. How would that affect your sprint planning?
- During sprint planning, it becomes evident that several stories need refinement. You (the PM) need some developers to do research into the source code and help you clarify technical aspects of the user stories that were too vague.
As you consider these scenarios, document any additional questions they spark in regard to dealing with backlog refinement and sprint planning.