This article looks to discuss what the Scrum Product backlog is and what role the Scrum Master plays when defining the Product Backlog. The article covers the differences in the roles between the Scrum Master and Product Owner. It also covers the feedback mechanisms used during an Agile Project.

************************************************************************

The History of Agile

A 59 Seconds Agile Video Animation
The History of Agile with 59 Seconds Agile

************************************************************************

The Scrum 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 requirement. Think of a shopping catalog of User Stories. It is ordered by value. Items can be selected from to determine what will be worked on during the current project iteration. Product Backlog prioritisation is a preliminary activity to a Sprint Planning Meeting. The Sprint Planning Meeting looks to discuss and review the highest prioritized items. By the end of the meeting, there should be team consensus on which User Stories to add to 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. The work is estimated and the team determine if they can complete it in the time available.

The person who makes all this possible is the Scrum Master. They are relied upon to facilitate the meetings. The Scrum Master ensures there are no obstacles hindering team members.

Who is Responsible For Prioritizing Product Backlog

The Product Owner is responsible for prioritizing the Product Backlog. The Scrum Master is key to providing clarity around the roles and responsibilities of the team. They ensure that strategic questions are asked and tasks are assigned and accomplished within the Scrum guidelines.

Scrum Product Backlog and the Process Experts

Scrum Masters are expected to be process experts. They do not get involved in the decision making but act as a coach. They guide the team in self-organization as needed.

A Sprint Planning Meeting will not begin without the Scrum Master validating with the Product Owner that there is an updated Product Backlog. They need to be confident that the priorities and dependencies are known.  Without this the Scrum Team may begin work on poorly defined features or low priority functionality.

59 Seconds Agile - The Agile Product Backlog
59 Seconds Agile – The Agile Product Backlog

How to Solicit Feedback about Priority: The Scrum Priority Levels

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. As a starting point, there are some common prioritization tools, two of the most common approaches are the MoSCoW and the 100-Point Method.

Our Favourite Agile Books

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

Scrum Product Backlog and MOSCOW

The first approach known as MoSCoW. This is an acronym for Must Have, Should Have, Could Have, Won’t Have.  These acronyms refer to whether the prioritized features will be in the next product release. MoSCoW 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. In other words, if any one of the Must Have’s is not completed 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. Everything else will be either a Should Have or a Could have.  The goal of this approach 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 team member knows something of significance that has not yet been discussed with the rest of the group.

The 100 Point Method

The second approach, known as the 100-point method, gives equal voice to all participants. The participants function 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.

Prev <— Continue Reading —> Next

Share
Translate »