The Agile Product Backlog for Scrum Masters

A Product Backlog is an organized collection of the existing User Stories (A.K.A. Wants and Needs) for an explicit business endeavor. Think of a shopping catalog of User Stories, ordered by urgency, that can be perused and selected from to determine what will be worked on during the current project iteration. As a preliminary activity to an iteration a Sprint Planning Meeting will be held, to discuss and review the highest prioritized items; by the end of the meeting, there should be team consensus on which User Stories have made the cut and these become the Sprint Backlog.

Scrum Master versus the Product Owner Role

Reaching this objective is usually harder than it sounds; the team must work together to substantiate the acceptance criteria for each Story, that the amount of work effort can be estimated and that the measured volume of work can be adequately completed and tested in the amount of time that has been set aside to work within. In addition, all the above should be true without unfairly demanding more work from one player than another or by neglecting to account for work that, if not ready, could prevent other work from being completed. The person who renders all this possible is the Scrum Master who is relied on to facilitate and drive meetings; ensuring there are no obstacles preventing team members from attending or external interruptions vying for their attention. The Scrum Master is also key to providing clarity around roles and responsibilities of the team, making sure that strategic questions are asked and that tasks are assigned and accomplished within the proper guidelines.

Scrum Masters are expected to be process experts and it rests on them not to get involved in the decision making but instead act as a combination of coach and referee; guiding the team in self-organization or course correcting as needed. A typical Sprint Planning Meeting will not begin without the Scrum Master validating with the Product Owner that there is an updated Product Backlog and if they are confident that the top priorities and dependencies are known.  If the answer is not yes, it is of great consequence as these prioritized User Stories set the theme of the Sprint. Although there may be a small window of opportunity for last minute decisions around what will be included in a sprint; for example, there may be an item that fits the timeline better or that is essential functionality to test properly, ultimately the Backlog should already highlight the items with the highest importance at the top of the list.

How to Solicit Feedback about Priority

Prior to the Sprint Planning Meeting, the Product Owner solicits feedback on the prioritization. The Product Owner has the final say on the prioritization as they have an overall view of all requirements. The Product Owner, therefore, needs to have a good understanding of the business value of each requirement, and the associated costs that may be incurred. They must also understand the dependencies or risks that need to be managed, and the complexity of implementation efforts. The Scrum Master can assist with this process and suggest appropriate methods to do so. As a starting point, there are some common prioritization tools, two of the most common methods are the MoSCow and the 100-Point Method.

The first method known as MoSCoW, is an acronym for Must Have, Should Have, Could Have, Won’t Have.  These acronyms refer to whether the prioritized features will be the next product release. Because there is an expectation of delivery built into each category it is a slightly more sophisticated version of High, Medium, Low and other similar labeling categorizations. All items identified as Must Have’s are the highest priority requirements, or in other words, if any one of the Must Have’s is not completed and implemented successfully the project/product will not be ready for the release. Anything that can be considered out of scope or a goal for the future will be listed as Won’t Haves and everything else will be either a Should Have or a Could have.  The goal of this method is to obtain consensus from the team that the right priority has been assigned. If there are differences of opinion, it is a good opportunity to find out why; it may be that one member knows something of significance that has not yet been discussed with the rest of the group.

The second method, known as the 100-point method, gives equal voice to all participants by functioning like a panel of judges. Each member starts with a bucket of points and is asked to vote by dispersing the points across the requirements. The trick is that the total of their individual votes cannot be a greater amount than they were initially given thus encouraging a well thought out distribution of points.

The ‘Agile Scrum Master Training Course With 59 Seconds Training‘ is now available for free. This free Scrum Master Certified Online Training Course provides an in-depth understanding of the Agile Scrum Master roles and responsibilities, where you find out what a Scrum Master does and how to do it. During this free course you will learn all of the tools needed to succeed as an Agile Scrum Master.

Thank you for choosing us to learn about the Agile Scrum Framework.

<– Continue Reading –>

Our Book Recommendations

We found these books great for finding out more information on Agile Scrum:

Master of Agile – Agile Scrum Master With 59 Seconds Agile (Video Training Course)

Introductory Offer: Free Course