The Product Backlog is an ordered list of hypotheses, requirements, features, enhancements, or Product Backlog Items that help the team accomplish the Product Goal.
The Product Backlog is the team’s single source of work. Meaning, anything the Developers are working on should be coming from the Product Backlog. There are no side requests. Any work should go through the Product Owner who determines its relevance and importance and places it in the Product Backlog for the team to work on.
The Product Backlog is dynamic, always changing, frequently reordered, and never complete. Why? Because Scrum is all about empiricism. Knowledge comes from doing the work, gaining experience, and then making decisions based on what is learned. Meaning, from the start the team is saying we don’t know everything. This is what we currently know today and what we think we should do. As we work, we expect to learn more and based on that, we expect this list to change accordingly. The Product Owner is always re-ordering the Product Backlog and ensuring the most important items are towards the top.
At any point in time, if you take a picture of the Product Backlog, it is going to look like this. Towards the top, the Product Backlog consists of fine-grained Product Backlog Items. These are items that have been reviewed, clarified, estimated, and broken down into very small items that are considered “Ready” for the next Sprint and can get pulled into the Sprint Backlog and tasked out in Sprint Planning.
Towards the middle, the Product Backlog Items are less refined, a bit larger, and require clarification before being worked on.
Towards the bottom, the Product Backlog Items are large concepts or ideas that are vague, not yet well thought out, and require a lot of clarification before being worked on.
The Product Backlog will always look like this, with mostly fined-grained items towards the top and coarse-grained items towards the bottom. It will look like this on day 5, on day 25, on day 50, and on day 250. Why? Because as the top items that are “Ready” to be worked on get pulled into the Sprint Backlog, the items below them, move up and get broken down and clarified, and the items below them also move up and get broken down and clarified and so forth, doing this just in time and at the right level of granularity. This happens in Product Backlog Refinement and is referred to as progressive elaboration where we clarify the upcoming work as we are getting closer and closer to working on it.
This is very different from the traditional “waterfall” development with big upfront plans based on detailed upfront requirements and designs. In Scrum, with empiricism, knowledge of what to do next is gained from building and developing, and that knowledge informs the requirements and designs and allows for continuous feedback and adjustments.
Product Backlog Refinement is an ongoing activity that occurs throughout the Sprint. It is not a timeboxed event. Just as the team dedicates time during the Sprint to build a product increment, the team also dedicates time to do ongoing Product Backlog Refinement. Refinement involves the Scrum team, with the key conversation happening directly between the Product Owner and Developers.
The Product Owner decides where a new Product Backlog Item might go, whether it goes towards the top, middle, or bottom based on its relevance and importance, always keeping the Product Goal in mind.
At any point in time, the Product Owner might drop an item deemed no longer important or necessary.
Throughout, the Product Owner regularly re-orders the Product Backlog based on the latest information and knowledge gained.
The Developers seek clarification, research, estimate, identify risks, and break items down into more manageable chunks of work so that by the time the items reach the top of the Product Backlog, they are “Ready” to be worked on.
This is Product Backlog Refinement, an ongoing activity that the Scrum team does throughout the Sprint to add, remove, reorder, clarify, research, estimate, split, or merge Product Backlog items to progressively elaborate on them so that the items towards the top of the Product Backlog are always ready for the next Sprint. Because when one Sprint ends, the next one starts. There are no breaks in between to figure out what to work on next. It’s the Ready items on the top of the Product Backlog.
For more details, sign up for an upcoming foundational ScrumMaster® (CSM®) class or a Certified Product Owner® (CSPO®) class or Certified Scrum Developer® (CSD®) class.
Next check out the entire Scrum in a Nutshell series:
Scrum in a Nutshell
Scrum is a framework for developing, delivering, and sustaining complex products. It all starts out with our stakeholders, customers, and users that have an idea about a product they need and want developed. They collaborate directly with Developers to turn this idea into reality. Developers in Scrum are not just programmers. They are part of […]
Scrum Accountabilities, Artifacts, and Events in a Nutshell
In Scrum, there are 3 accountabilities, 3 artifacts, and 5 events. The 3 accountabilities in Scrum are: The 3 artifacts in Scrum are: The 5 events in Scrum are: And that’s the Scrum Framework as defined by
Scrum Team in a Nutshell
The Scrum team consists of 3 accountabilities, Developers, Product Owner, and Scrum Master. Developers are accountable for building and delivering a quality working Product Increment at the end of each Sprint. They are a small group, typically 3 to 9 members that are cross-functional and self-organizing. Developers are cross-functional to remove bottlenecks and dependencies. Developers […]
Product Backlog Refinement in a Nutshell
The Product Backlog is an ordered list of hypotheses, requirements, features, enhancements, or Product Backlog Items that help the team accomplish the Product Goal. The Product Backlog is the team’s single source of work. Meaning, anything the Developers are working on should be coming from the Product Backlog. There are no side requests. Any work […]
Sprint Planning in a Nutshell
In Scrum, the Sprint starts with Sprint Planning where the Scrum team plans out their work for the Sprint and creates a Sprint Backlog. The Sprint Backlog is the team’s plan to accomplish the work. Sprint planning is timeboxed to 2 hours per week of Sprint, so for a 2-week Sprint it is one event […]
Daily Scrum in a Nutshell
The Daily Scrum is a brief daily planning event by the Developers to inspect their work and the progress they are making toward the Sprint Goal that will result in a Product Increment. The Developers created their Sprint plan or Sprint Backlog in Sprint Planning at the beginning of the Sprint. However, this plan is […]
Sprint Review in a Nutshell
The Sprint Review is a working session for the stakeholders, users, and customers to collaborate with the Scrum team which includes the Developers, Product Owner, and Scrum Master, and inspect the progress made toward the Product Goal based on the latest Product Increment. The Sprint Review is about getting feedback from the stakeholders and users […]
Sprint Retrospective in a Nutshell
The Sprint Retrospective is a reflection event that occurs at the end of each Sprint. It is for the entire Scrum team which includes the Product Owner, Developers, and ScrumMaster to inspect how they are operating and then come up with a continuous improvement plan to adapt and become more effective as a team and […]
Product Increment and the Definition of Done in a Nutshell
The Product Increment is the output of every Sprint and is an increment that brings the team one step closer to the overall Product Goal. This means that each Sprint is focused on a cohesive set of Product Backlog Items that meet a Sprint Goal and not random unrelated items. Once a Sprint starts and […]
Scrum Values in a Nutshell
For teams to succeed with Scrum, team members must become proficient in living the 5 Scrum values of commitment, focus, openness, respect, and courage. Commitment: In Scrum, the team commits to each other, not to other people, but to each other, on supporting each other to deliver on the Sprint Goal and Product Goal. Focus: […]
Scrum Foundations and Theory in a Nutshell
Scrum is a framework for solving complex adaptive problems with high levels of unknowns, uncertainties, or risks around what to build or how to build it. Scrum involves a cross-functional and self-managing Scrum team that uses empiricism to build products iteratively and incrementally to reduce risk and deliver early and often. The Scrum team uses […]
Scrum and the Manifesto for Agile Software Development
Back in February 2001, at the lodge in Snowbird Utah, 17 thought leaders from the software industry got together to discuss the state of software development and compare various lightweight frameworks that popped up in the late 90s because of dissatisfaction with the traditional waterfall approach to building products. The participants shared and learned about […]
