Maximize Your Leadership Potential

Leadership isn’t a journey you should take alone. What if you had someone to come alongside you? I provide coaching to help you reach your vision, lead others and grow as a leader.

Schedule a Free Coaching Appointment

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:

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.

Does life ever feel like a hack rather than on purpose?

You want your life to have meaning and impact. Daily life is made up of the spaces we gather and the moments we interact with one another.

What if your spaces, moments, and interactions not only felt natural and intuitive but also aligned with your priorities and positively impacted those around you?

Discover your Everyday Design so you can focus on what’s important.

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.

Maximize Your Leadership Potential

Leadership isn’t a journey you should take alone. What if you had someone to come alongside you? I provide coaching to help you reach your vision, lead others and grow as a leader.

Schedule a Free Coaching Appointment

This post is part of an upcoming guide called Everyday Scrum? A Guide for Everyday People to Learn Scrum where I will explore and explain the key elements of Scrum.

Perhaps you have heard about Scrum but are not exactly sure what it is. Or maybe you know some about it but are not sure how to apply it, especially outside a software development context.

You find my my current and future guides on everyday.design. Signup to be the first to know when new guides are released.

There are a lot of new terms when learning the Scrum essentials, and this post probably introduced you to some of the vocabulary.

If you want to learn more about specific Scrum topics, here are a few to choose from or check out the scrum FAQs.

Applying Scrum

Agile in Everyday Life

Scrum Roles

Scrum Meetings

Scrum General Topics

Scrum Advanced Topics

To learn more about Scrum, 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.

FAQs

Scrum backlog

What is the backlog in Scrum?

A prioritized list of work to be done by the Scrum team.

There are actually two backlogs, the product backlog and the sprint backlog. They each contain the definitive list of work to be done. The product owner keeps the backlog ordered by priority. 

Learn to use the backlog in Scrum and check out the sprint backlog vs product backlog in Scrum.

How are the product backlog and sprint backlog different?

Product backlog contains work for the product and sprint backlog contains work for the sprint.

The product backlog prioritizes the features needed in the product. It is a singular visible source of requirements for the product.

The sprint backlog represents the work to do in a given sprint. It is a definitive list of all the scrum team is being asked to produce for the sprint. 

Learn more about the sprint backlog vs product backlog in Scrum.

What is a PBI (product backlog item)?

The container for work organized in the backlog.

Each item in the backlog represents precise work and value to deliver. Often these PBIs are written using both user stories and acceptance criteria. The PBIs are what gets refined during the backlog refinement session, and if one is too large, it may be broken down into smaller PBIs.

Learn more about how backlogs are used in scrum, the sprint backlog vs product backlog in Scrum and explore the essential Scrum glossary.

Scrum elements

What is the definition of done?

Criteria shared by a Scrum team for what constitutes done.

The definition of done is a list of what must be true to consider a PBI done. The whole team creates and agrees to what is in the definition of done and is updated as needed for the team to function effectively. 

Learn to use the definition of done and explore acceptance criteria vs definition of done.

What is the increment in scrum?

The increment is the new functionality or value delivered at the end of a sprint.

It is the next complete piece added to build the product. The increment is complete in the sense that it should be ready to release to the end-user even if the team chooses to wait.

Learn more about incremental and iterative development or explore the essential Scrum glossary.

Scrum design

What are the three pillars of Scrum?

Transparency, Inspection and Adaptation.

Scrum is founded on three essential pillars, and each leads the team to ask a critical question.

  1. Transparency. How does this make things more visible?
  2. Inspection. Where does this create space to evaluate?
  3. Adaptation. When does this encourage growth?

Learn how to apply the three pillars of Scrum and then explore the most common terms in a Scrum glossary.

What are the values of Scrum?

Commitment, courage, focus, openness and respect.

There are five values critical to the practice of Scrum: commitment, courage, focus, openness, and respect.

  1. Commit to achieving the goals of the Scrum Team.
  2. Courage to do the right thing and work on challenging problems.
  3. Focus on the Sprint's work and the Scrum Team's goals.
  4. Open about all the work and the challenges with performing the work.
  5. Respect each other to be capable, independent people

Learn how to align Scrum values with your organization and then explore the most common terms in a Scrum glossary.

What is the sprint goal in scrum?

A vision and theme to guide the sprint.

The sprint goal encapsulates the product owner’s vision into a concrete statement for the development team to measure the sprint against. The sprint goal provides a theme for the sprint’s work helping the team see how all the parts come together. 

Learn more about the role of the sprint goal in scrum and explore the essential Scrum glossary.

How to use Scrum

Why use Scrum?

Scrum is vital for teams to deliver value amidst changing circumstances.

It forces clarity and prioritization, which provides the focus necessary for teams to be effective. Scrum embraces complexity and change by keeping many things simple and iteratively evaluating and adapting. 

You can learn more about why to use Scrum and three challenges Scrum solves. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

When does Scrum not work well?

Scrum can fail when there is a substantial mismatch between organizational culture and the Scrum values.

Scrum isn’t always the best option for teams. Scrum can fail when there is a substantial mismatch between organizational culture and the Scrum values. It also depends on the nature of the work you do. If you work if very linear, predictable and tightly defined, you may not experience many benefits Scrum provides.

Find out more about aligning your organizational values with Scrum or how Scrum might fit in your context. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

How do I know when to use Scrum?

When you have a dedicated team, a singular product and are facing uncertainty.

Scrum functions at its best when you have a dedicated team focused on developing a singular product. Its agility shines when there are time constraints combined with uncertainty. 

Explore the pros and cons of Scrum along with expectations vs. realities with Scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.