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.
Share It With Your Colleagues and Friends to Help Them Learn:
What Is The Scrum Product Backlog? This Might Surprise You!
|
|
|
|
|
|
|
SCRUM INSTITUTE™
