Sprint Backlog vs. Product Backlog

Reflection Questions

• What are you currently using to organize the work you or your team needs to do?
• What is the most significant challenge you face when trying to focus on completing work?
• What system do you currently use to prioritize your work?

If you are interested in learning Scrum or teaching it to your team, you'll want to check out Everyday Scrum. It's a guide for everyday people to learn Scrum and is written intentionally to be accessible to those practicing Scrum outside the software development space.

If you want to explore more Scrum related content, I have lot's of Agile and Scrum posts for you and I've highlighted a few of them below.

Scrum Basics

• Why Use Scrum?
• What Is The Definition Of Scrum?
• What Are The Pros & Cons Of Scrum?
• Scrum: Expectations Vs. Reality
• Is Scrum Hard To Learn?
• How To Align The Scrum Values With Your Organizational Culture
• What's the difference between iterative and incremental development?
• Learn To Forecast Progress In Scrum
• What Is The Definition Of Done In Scrum?

Scrum Roles

• What is a Scrum Product Owner?
• What does a Product Owner do each day?
• Getting Certified as a Product Owner
• What is a Scrum Master?
• What does a Scrum Master do each day?
• Getting Certified as a Scrum Master
• Can The Scrum Master And Product Owner Be The Same Person
• How Is A Scrum Master Different Than A Project Manager?

Scrum Books

• Scrum: The Art of Doing Twice the Work in Half the Time
• The Scrum Fieldbook: A Master Class on Accelerating Performance, Getting Results, and Defining the Future

A backlog is an essential tool for collecting and organizing the work that you need to get done. And Scrum takes us to another level by creating both a product and a Sprint backlog, King said. Today here on Everyday Design, I'm going to cover the differences between the sprint and the product backlog and how to use them together. So let's go.

Have you ever had a to do list that grew faster than you could get things done? Or maybe you began working on something and halfway through someone came in and told you, No, wait, no, this is now more important and you switched focus and you start to make progress there. And then they came in again said, no, now focus on this.

Well, that is both really frustrating and really common. It occurs in both small and large organizations. It helps to have a list, but if everyone can change, add to reorder your list, then how can you make progress? I watched teams get sidetracked as executives take turns coming in and reprioritizing everyone's work to their favorite projects. But I've also helped these same kind of teams use Scrum’s two backlog approach to create a safe space of focus to get the work done that they've already agreed to.

So the purpose of a backlog is to delineate both the scope, the priority and the focus and the scrum. There are two backlogs. Like I said before, there's a product backlog and the sprint backlog and the product backlog. It establishes the scope and the priority for the project. So if it's not in the product backlog, then it's not part of the plan.

The product backlog has priority that's demonstrated in the order. So you keep the higher priority, more defined things top the lower priority, less defined things towards the bottom. And that ordering is the job of the product owner. They synthesize input from stakeholders, team members, customers, everybody as they figure out what's the value in that backlog. The product backlog helps answer the question Is this work part of the project?

But because the product backlog is somewhat exhaustive, it is constantly changing and adapting. It's not a great list for the team to work from, and that's where the sprint backlog comes in. And so the Sprint backlog, it clarifies what is the team focused on during this sprint for the duration of their sprint? If it's outside the sprint backlog, like if it's still over here in the product backlog, then they're not focused on it right now.

They're not doing it during the sprint. The expectation is that everything in the Sprint backlog will get completed within that sprint and that the team is protected from having anything else added thrown in their mid-sprint. So the Sprint backlog is essentially the team's sprint to do list. It doesn't change, which is great. So let's look at kind of a workflow.

How does work make it into these backlogs? So you kind of see it in action. So let's say after engaging with stakeholders, team members or customers, the product owner creates a product backlog item or PBI They will then order it within the product backlog according to priority, kind of balancing the value it delivers with all the other items in there and considering any timing factors to do something later on depend on getting it done.

Next the Scrum Team will review items during the backlog refinement session and they'll ask clarifying questions to better understand hey, what's what's this. But problem is is solving what value are we delivering? Then you probably use things like user stories or acceptance criteria to define that. They may add some other details to the PBI and they'll probably use story points to help size the PVI.

In story points is just a measurement that helps estimate how much work it takes to get something done. At this point, the product owner might reorder that PBI within the backlog. Now they have that increased clarity, but they don't have to. That's not a that's not a requirement. So, okay, now we move forward. We got the product backlog item defined.

It's in the the list. Everyone knows what it is. It's time for the new sprint to begin. The team will select the top items from the product backlog and move them to their sprint backlog. And during the sprint they'll focus on just the sprint backlog, choosing items, completing them, moving on, picking another one, completing it and just working their way through.

Now when the sprint concludes, all those completed items are presented during the Sprint Review, they're considered done. Everyone celebrates. Now sometimes something doesn't get done. If it isn't accepted by the product owner, it may that the PBI may get adjusted and added back into the product backlog, and maybe it doesn't. A couple of other notes regarding backlogs, both backlogs, the product and the sprint, are visible to others outside the team.

Stakeholders can see what work is active or coming up and if anyone wants to know how long till this future feature that's here in the product backlog is still delivered, the PO can just look at what work is ahead of it, how many story points does it take, what's the team's velocity? And they can estimate that because that's the backlog is ordered by how they're going to get it done.

You can use scrums, backlogs to protect your team's focus, allowing them to get the highest value work done. I really love how the Sprint backlog protects the team and provides safety by giving them a block of time that's theirs to focus and get the valuable, the selected work complete. Using scrums backlogs you can say goodbye to new coming in and sabotaging the previously selected work or having the team spread so thin across so much work that they don't really finish anything and everything kind of sits at 80% done.

So let's not do that anymore. Check out the product and sprint backlogs from Scrum if you want. There's a lot more resources down in the description and I hope you found this video helpful. If you want more content like it, please like and subscribe. Thanks.