Scrum Institute, Scrum Framework Episode #11 has been proudly brought to you by International Scrum Institute, https://www.scrum-institute.org

You can also listen Scrum Institute’s Podcast from Apple, Spotify, Castbox and Google Play.

Listen to Scrum Institute Podcast on Apple
Listen to Scrum Institute Podcast on Google Play
Listen to Scrum Institute Podcast on Spotify
Listen to Scrum Institute Podcast on Listen Notes
Listen to Scrum Institute Podcast on Castbox

What Is The Scrum Product Backlog? This Might Surprise You!

Product Backlog (Scrum Backlog) or Scrum Product Backlog is the central element to manage all of the known requirements of a Scrum Project. 

It consists of all customer requirements and work results that are needed to execute and finish a successful project. As requirements, you count functional and non-functional requirements and other features related to user experience and user interface design.

The Product Backlog contains feature requests and their high-level user stories. These can also include pre-requisite or complementary project requirements such as building test and development environments. Moreover, other user stories required to resolve known bugs or reduce technical debt or improve certain software features have also their places in the Product Backlog as well. 

Every Scrum Project has its Product Backlog. The Scrum Product Owner is responsible for the creation, maintenance, and fine-tuning of a Product Backlog. The Product Backlog doesn’t and shouldn’t answer the question of how these requirements will be developed and delivered.

That’s the duty of the Scrum Team. The Scrum Team decides and documents the required tasks to address these requirements in Sprint Backlogs. Note that Product Backlog and Sprint Backlog are physically separate entities although entries in the Product Backlog drive the contents of the Sprint Backlog.

The owner of the Scrum Product Backlog is the Scrum Product Owner. The Scrum Master, the Scrum Team, and other Stakeholders contribute it to build a broader list of user stories to bring the product to success. 

Working with a Scrum Product Backlog does not mean that the Scrum Team is not allowed to create and use other artifacts to manage work. Examples for additional artifacts could be a summary of the various user roles, workflow descriptions, user interface guidelines, storyboards, or user interface prototypes. However, note that these artifacts do not replace the Scrum Product Backlog but complement and detail its contents.

he Product Backlog is a living document. Similar to how the software incrementally improves, the Product Backlog grows in time as well. The Scrum framework doesn’t require a separate change management process per se. The Scrum Product Owner creates the first versions of the Product Backlog based on his best initial understanding of the product.

While the Scrum Product Owner closely observes how the product emerges from sprint to sprint and while the knowledge about client requirements augments, he or she adds, removes and fine-tines requirements in the Product Backlog. 

The Scrum Product Owner prioritizes requirements in the Product Backlog. The more priority an element in the Product Backlog has, the more details it should contain. So the Scrum Team can easily make sense of these high priority requirements and create the required tasks to build them.

Furthermore, by using story points, the Scrum Team regularly estimates the requirements in the Product Backlog. These estimations should be fine-tuned and improved for high-priority user stories to make them ready for Sprint Planning Meetings. 

Each Scrum Product Backlog has specific attributes that differentiate it from a simple to-do list:

• A user story in the Scrum Product Backlog always add a business or technical value to its client, business owner and end-users, 
• All user stories in the Scrum Product Backlog are prioritized and ordered from highest to lowest priority, 
• The level of details stored in a user story depends on its position within the Scrum Product Backlog, 
• User stories are estimated,
• Scrum Product Backlog is a living document,
• There are no action items or low-level tasks in the Scrum Product Backlog. 

User Stories Add Value To Client, Business, and Systems 

Each user story in the Scrum Product Backlog must offer some client value. User stories without any client value are a pure waste of resources, and they should be eliminated. The Scrum Product Backlog can include user stories for: 

• The specification of functional and nonfunctional requirements,
• The summary of high-level break-down of the work necessary to launch the software product, 
• Setting up non-production development and demonstration environments,
• Remediating defects.

Example Scrum Product Backlog

Some tasks may not add direct value to the functionality of software system and business clients. Nevertheless, they should add value by increasing quality, reducing technical debt, and increasing maintainability of the product during the long run.

Product Backlog Is A Living Document

The Scrum Product Backlog is a living document. It changes and evolves throughout the entire course of a project. If needed, new user stories are added, existing user stories may be altered, defined in more detail, or even deleted. Requirements of Scrum projects are no longer frozen early on like we used to have them with the Waterfall Methodology. 

Instead, the final set of requirements within the Scrum Product Backlog are developed iteratively, together with the emerging software increments.That is different from traditional requirements engineering. Still, this new way of handling client requirements allows the Scrum Team to maximize client value and minimize waste of resources. 

Different Level Of Details 

The requirements in the Scrum Product Backlog can have varying depths with their granularities. Only those requirements that will be implemented during the next few Sprints should be defined with greater detail. All other user stories should remain coarse-grained; they should be only processed “just in time” before the Scrum Team needs to know more about them.

It does not make sense to invest time and resources into the specification of these requirements, as some of these requirements may change or disappear until they are needed for implementation. “Just in time” handling of requirements is one of the most excellent benefits the Scrum Framework offers to deal with “unknown unknowns” in your projects.

No Low-Level tasks In The Product Backlog 

The Scrum Product Backlog should not contain detailed task break-down of user stories. The Scrum Product Owner defines the requirements together with the business clients and stakeholders before he or she brings them to the Backlog Refinement or Sprint Planning Meetings. Detailed task break-down and distribution of these tasks among the Scrum Team Members are the responsibility of the Scrum Team. 

The Scrum Product Backlog Is Ordered Based On Priority

All user stories are prioritized, and the Scrum Product Backlog is ordered based on the priority of user stories (from highest to lowest). The Scrum Product Owner performs the prioritization with the support of the Scrum Team. During this prioritization exercise, the added value created for the business of the client, costs, risks, and dependencies are the most common factors which are into account by the team. Thanks to this prioritization, the Scrum Product Owner can decide what the Scrum Team should subsequently build and deliver.

All User Stories Are Estimated 

All user stories within the Scrum Product Backlog have to be estimated according to the agreed norm of story point units such as Fibonacci number or S/M/L/XL/XXL, etc. More about this comes later in this material. These estimations then impact the capacity planning of Sprints, contents of Sprint Backlog, and release plans.

Working With The Backlog 

The Scrum Product Backlog needs regular care and attention. It needs to be carefully managed because it’s the source of truth to understand what your software product is all about.

At the beginning of a project, it’s filled with a lot of high-level stories that may or may not be highly relevant to contribute to the success of the project. While the project progresses from one Sprint to another, the Scrum Product Owner and the team learn more about the project.

Subsequently, the contents of the Scrum Product Backlog will become perfectly reasonable to reflect your product better. 

After this initial setup, the Scrum Product Backlog has to be continuously maintained. The maintenance of the Scrum Product Backlog stands for:

• As new requirements are discovered, they are described and added. Existing requirements can be changed or removed as appropriate,
• Ordering (Prioritizing) the Scrum Product Backlog. The most important (highest priority) user stories are moved to the top,
• Preparing the high-priority user stories for the upcoming Sprint Planning Meetings (usually during Backlog Refinement Meetings), 
• (Re-)Estimating the user stories in the Scrum Product Backlog (usually during Backlog Refinement Meetings). 

The Scrum Product Owner is responsible for making sure that the Scrum Product Backlog is always in good shape. And yet maintaining the Scrum Product Backlog is a collaborative process. A reasonable capacity of the Scrum Team members should be reserved for managing the Scrum Product Backlog for the time they need to spend during Scrum Rituals (Events).

Furthermore, note that, this collaborative maintenance of the Scrum Product Backlog helps to clarify the requirements and creates buy-in of the emerging software product from the Scrum Team members.

What Is The Sprint Backlog? This Might Surprise You!

The Sprint Backlog stores and maintains user stories required to deliver the shippable software increment of a Sprint.

These user stories are the ones the Scrum Team committed during the Sprint Planning Meeting. All user stories in the Sprint Backlog are estimated to enable the monitoring and tracking of the work.

The Sprint Backlog is a living artifact, and during the course of Sprint, the Scrum team members continuously update it. 

When a Scrum Team member works on a task, his or her name is associated with it. The status of the task is set to “Started Tasks” or “Work In Progress”. When the task is completed according to its Definition of Done, its status is set to “Done” or “Completed”.

New tasks (not new user stories) can be added to the Sprint Backlog during the Sprint. At the end of every day, the remaining effort to deliver the full Sprint Backlog is calculated. This helps the Scrum Team and the Scrum Product Owner to monitor the remaining amount of work to bring the Sprint goals to success.

The Sprint Backlog can be kept electronically by using a Scrum Project Management Software or spreadsheet software such as Excel or Google Sheet. Alternatively, for smaller and new teams, cards (or post-its) glued on a real physical board can be used too. 

The latter has some advantages such as transparency of work and easy access for everyone, including the stakeholders. Its downside is that it’s not sustainable if the Scrum Team is distributed over multiple locations.

The figure below shows a sample of how such a Sprint Backlog Board can be built. The structure should be adapted to reflect the needs of the project and the Scrum Team. 

A Sample Sprint Backlog Board 

It’s evident that for a Scrum Team to work productively, they need to understand the difference between a Product Backlog and a Sprint Backlog, and how these two elements interact to execute forward the project.

Remember that there is a complete list of user stories from the Product Backlog. And now, a small subset of this list is being moved to Sprint Backlog to accomplish the goals of the Sprint.

During the Sprint Planning Meeting, all members of the Scrum Team should discuss what tasks must be done and how these tasks will be completed. 

It’s at this point that each item on the Sprint Backlog is broken down into tasks or steps that will be taken to complete the committed user stories. All of this must be clearly communicated and agreed upon, so the Scrum Team members have an unmistakable consensus about what is coming in the Sprint and what it takes to accomplish its goals.

What Is A Sprint? This Might Surprise You!

In the scrum framework, all activities to implement the requirements happen during Sprints.

Sprints are cycles of work activities to develop shippable software product or service increments. Sprints are also sometimes called iterations. 

You think about sprints as if they’re micro projects. As the term “Sprint” implies, a sprint doesn’t take long, and it’s maximum for four weeks.

Sprints are always short, usually between 2 to 4 weeks. But depending on the reliably foreseen amount of work or for Exploration Sprints, a one week long Sprint is also typical. With the approval of the Scrum Product Owner, a Scrum Team may need an Exploration Sprint to investigate new technology, build a mock-up or a proof of concept.

Different from a running race, at the end of a Sprint, the Scrum Team shouldn’t be out of breath and power. Instead, the Scrum Team should be fresh, and they should energetically start the next Sprint.

The Scrum Software Development and Delivery Framework has nothing to do to create pressure and stress for its team members. It’s a well known fact that people perform best when they can work focused, relieved, and undistracted. If it’s applied correctly this is what Sprints help us accomplish.

Every Sprint starts with a Sprint Planning Meeting. During the Sprint Planning Meeting, the Scrum Team decides what and how many requirements they will implement in this given Sprint. Subsequently, the Scrum Team starts the execution of activities to deliver requirements. 

Daily Scrum (Daily Scrum Meeting) happens every day at the same time in the same place. The goal of this meeting is to align all members of the Scrum Team regularly. Scrum Team Members can also ask help from the Scrum Master to remove any impediments which may potentially slow down or block the progress of a Sprint.

The Scrum Team finalizes a Sprint with Sprint Review and Sprint Retrospective meetings. The Sprint Review Meeting enables the Scrum Product Owner to review and control the work results the Scrum Team has created during the Sprint. 

During the Sprint Retrospective Meeting, the Scrum Team reflects the way they work together, how they use the Scrum Framework, and how they can improve. 

So the Scrum Team jointly takes these improvement potentials and feedback into account during the next Sprint Planning Meeting.Sprints enable such feedback loops during short periods with small batch sizes of work.

That’s one of the significant reasons why and how the Scrum framework helps teams and organizations to improve themselves continuously.