Leaning Scrum for the first time can be a bit overwhelming. There are many new terms and concepts in Scrum. The backlog is one of those terms, and you may be wondering:

What is the backlog, and how is it used in Scrum?

Well, there are actually two backlogs in Scrum. And I’ll walk through both of them and why they matter in this article as we cover:

• The two backlogs in scrum
• How the backlogs impact teamwork
• Using the backlog with multiple teams

Sprint backlog vs product backlog.

Let’s talk about the backlogs. A backlog is a prioritized collection of items for the Scrum team, each representing value the team could add to the product. These two backlogs organize the primary work of the team.

A good product backlog is shaped like an iceberg: small items at the top, big items below there, and who knows what under the waterline. ​A good product backlog is shaped like an iceberg: small items at the top, big items below there, and who knows what under the waterline.​
- Mountain Goat Software

The Product Backlog

The product backlog prioritizes the features needed in the product. It creates clarity by serving as the singular visible source of requirements for the product. It is visible both to the members of the Scrum team and the whole organization.

These requirements often take the form of user stories. As the requirements are refined, they are given success criteria for quality assurance and story points for estimating size.

The product owner is responsible for curating the product backlog. This curation is the focus of the backlog refinement session and happens continually as more is learned about the product being developed. 

The product owner has the final say in the ordering and thus the prioritization of the backlog. Having the backlog as the singular source of truth for what work should be done and what is priority provides enormous clarity and focus for the team.

There are no ties, and if one item is higher than the other, it’s more important.

The development team reviews the user stories from the product backlog during sprint planning. Because the product owner keeps the backlog up to date and prioritized, the development team stays focused on the top of the backlog. 

With the sprint goal as guidance, the team selects stories to complete during the next sprint. At this point, they move stories from the product backlog to the sprint backlog.

The Sprint Backlog

The sprint backlog represents the work to do in a given sprint. It is a definitive list, meaning the team doesn’t do any work during the sprint outside of what’s in the sprint backlog. This restraint provides protection for the team to focus on the work given to that sprint.

The development team pulls stories from the sprint backlog throughout the sprint and works them until completion. A team member shouldn’t select more work from the sprint backlog until they complete the work already pulled.

At the end of the sprint, the sprint backlog should be empty. During the sprint review, the team presents completed stories for approval. Any incomplete stories or new stories are added to the product backlog, and the cycle repeats, selecting new stories and moving them to the sprint backlog.

The backlogs are critical to effective teamwork in Scrum.

These two backlogs play essential roles for the Scrum team by providing clarity and safety for the team.

Have you ever asked a leader about the priorities, and they said something like, “It’s all top priority!” The order of the backlog sets the priority. There are no ties, and if one item is higher than the other, it’s more important. This clarity about priority empowers the team because they know they are doing the right work. 

Having the backlog as the singular source of truth for what work should be done and what is priority provides enormous clarity and focus for the team.

If someone outside the team disagrees with the order of the backlog, they can take it up with the product owner. This clarity of responsibility frees the team from burning time and focus on unnecessary debates. 

The backlog items are usually written using a user story format. “As a… I want… So that…” This format identifies who they are building a feature for, what need it meets and what overall goal it achieves for the customer. This clarity of purpose equips team members to create value that doesn’t just check the box but makes a difference for the end-user.

I mentioned this earlier, but it bears repeating. The sprint backlog is all the team needs to focus on during a sprint. This clarity of focus provides a safe, closed environment that invites creativity, collaboration and innovative problem-solving.

How does the backlog work with multiple teams?

Sometimes you will have more than one team working on a product. So how do you order the work? A single product should have a single product backlog, visible to any team working on the product. 

However, each team should have its own sprint backlog, defining the team's work during the sprint. All teams will coordinate to pull items from the same product backlog into their different sprint backlogs during sprint planning. 

Be mindful of dependencies between requirements selected by different teams. Ideally, if two requirements have dependencies or exceptionally tight integration, both requirements are selected by the same team.

All the teams must share the same definitions of done to ensure the work produced can be integrated together into the product. Teams will likely need to add additional items to the definition of done to keep the development in sync. 

During the sprint review, as work is accepted, the Scrum team must take care to ensure the integration of all team's completed work into the product.

If you are trying to implement this on a scale beyond two Scrum teams, I suggest you look into the Nexus framework. It’s produced by the same people you run scrum.org, and gives a process framework for running Scrum at scale. 

In the framework, each team functions as a Scrum team with its own Scrum Master. There are some additional roles and meetings that account for the additional coordination and integration of working at scale.

Next steps​ for applying Scrum.

There are a lot of new terms when learning the Scrum essentials, and I hope this post helped clear up some of the vocabulary. If you want to learn more about Scrum in general, check out my What is Scrum? A Guide for Everyday People to Learn Scrum. If you have more questions, please feel free to reach out on LinkedIn.

Still not sure about your next step with Scrum? I offer a couple of free coaching sessions each month. You can signup for a free 1-hour coaching session, and we can work together to identify a good next step for you.