Please find highlights from Satya Narayan Dash’s webinar – Practical Scrum Using MS Project Agile – being provided by MPUG for the convenience of our members. You may wish to use this transcript for the purposes of self-paced learning, searching for specific information, and/or performing a quick review of webinar content. There may be exclusions, such as those steps included in product demonstrations, or there may be additions to expand on concepts. You may watch the on-demand recording of this webinar at your convenience.
What is a Product Backlog?
A Product Backlog is an ordered list of items to build and improve a product, service, or result. It typically contains user requirements, process improvement items, bugs, enhancements, change requests, and feature requests. Essentially, any item related to the product can be part of the Product Backlog.
The Product Backlog is a prioritized list, with the high-priority items at the top and the low-priority items at the bottom. This prioritization is represented in a visual format, with high-priority items being fine-grained and low-priority items being coarse-grained. The items at the top of the backlog are clearly defined, estimated, and detailed, and can be taken into the upcoming Sprint.
Who Owns the Product Backlog?
The Product Backlog is owned by the Product Owner, who is responsible for making sure that the backlog items are aligned with the product goal. The product goal is the commitment made by the Product Owner, and it is part of the Product Backlog. The Product Owner decides which items go into the Product Backlog and when they should be done.
However, any stakeholder can raise a requirement to be part of the Product Backlog. This means that stakeholders can provide input on what they think should be included in the backlog, but the final decision rests with the Product Owner.
Want to learn how to use Microsoft Project for Scrum?
Refining the Product Backlog
A refined Product Backlog is presented to the team before the sprint planning meeting, which is the first meeting of each sprint. Refinement is a separate event, with around 10% of the time being dedicated to refining the Product Backlog. For a two-week sprint, one to two hours of Product Backlog refinement is recommended.
During refinement, the Product Owner and the Scrum Team members participate in the process of clearly defining the Product Backlog items. The goal is to have a clearly defined and detailed Product Backlog that can be presented in the upcoming sprint.
Who Determines the “How” and “Who”?
The “How” and “Who” of the Product Backlog are determined by the developers, who are responsible for breaking down the Product Backlog items into individual tasks. The Scrum Team is self-organizing, self-managing, self-directing, self-motivated, and cross-functional in nature. This means that the developers decide how they will do the tasks and who will do what task in the upcoming Sprint. The Scrum Master does not assign tasks to the developers. Instead, the team members discuss and decide on the tasks among themselves.
Conclusion
In conclusion, the Product Backlog is a key tool in Scrum methodology for building and improving a product, service, or result. It is owned by the Product Owner and contains a prioritized list of items that can be refined before each Sprint. The developers are responsible for determining the “how” and “who” of the Product Backlog items during Sprint planning.
For further reading on the Sprint Backlog, check out this article by Scrum.org: https://www.scrum.org/resources/what-is-a-sprint-backlog-in-scrum
