20.The Scrum Product Backlog
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, usually during Backlog Refinement Meetings： • Preparing the high-priority user stories for the upcoming Sprint Planning Meetings, • (Re-)Estimating the user stories in the Scrum Product Backlog.
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.
Sprint Planning Meetings
The Scrum Product Owner uses the Groomed Scrum Product Backlog during the Sprint Planning Meetings to introduce the highest priority user stories to the Scrum Team. The Scrum Team then determines which items they can complete during the upcoming Sprint.
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 These estimations then impact the capacity planning of Sprints, contents of Sprint Backlog, and release plans.
Scrum Product Backlog intial setup
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.
The Scrum Product Backlog Is Ordered Based On Priority
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 taken into account by the team. Thanks to this prioritization, the Scrum Product Owner can decide what the Scrum Team should subsequently build and deliver.
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 exploration of client needs or various different technical options, • 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.
Scrum Team is 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.
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. The final set of requirements within the Scrum Product Backlog are developed iteratively, together with the emerging software increments. This new way of handling client requirements allows the Scrum Team to maximize client value and minimize waste of resources. Requirements of Scrum projects are no longer frozen early like the Waterfall Methodology.
"Just in time" handling of requirements
It is one of the most excellent benefits the Scrum Framework offers to deal with "unknown unknowns" in your projects. 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.
Working With The Scrum Product Backlog
It's the source of truth to understand what your software product is all about. 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. Scrum Team members should reserve a reasonable capacity to manage the Scrum Product Backlog during Scrum Rituals (Events).
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.
The 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.
Sprint Backlogs
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.
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.
Product Backlog (Scrum Backlog) or Scrum Product Backlog
The Scrum Product Owner is responsible for the creation, maintenance, and fine-tuning of a Product Backlog. It is the central element to manage all of the known requirements of a Scrum Project. 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. It consists of •all customer requirements: functional and non-functional other features related to user experience user interface design. •work results that are needed to execute and finish a successful project. •feature requests and their high-level user stories •other user stories required to resolve known bugs •other user stories required to reduce technical debt or improve certain software features. •pre-requisite or complementary project requirements such as building test and development environments.
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 in Scrum Grooming meeting to make them ready for Sprint Planning Meetings.
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.