Locked lesson.
About this lesson
The Product Owner must regularly prioritize the Story Cards that make up the Product Backlog and at the beginning of a Sprint he or she must prioritize the Story Cards selected for the Sprint Backlog.
Exercise files
Download this lesson’s related exercise files.
Prioritizing the Backlog.docx62.7 KB Prioritizing the Backlog - Solution.docx
61.2 KB
Quick reference
Prioritizing the Backlogs
The Product Owner must regularly prioritize the Story Cards that make up the Product Backlog and at the beginning of a Sprint he or she must prioritize the Story Cards selected for the Sprint Backlog.
When to Use Prioritizing the Backlogs
As soon as the Product Owner has created the initial Product Backlog for the project, it should be prioritized. This will aid the Product Owner in the definition of Releases and the selection of Stories for each Sprint Backlog. The Sprint Backlog is prioritized as part of the initiation of the Sprint. Following a Sprint Demo, there will often be new and modified stories added to the remainder of the Product Backlog. At that time, the Product Backlog should be reprioritized.
Instructions
- As has been discussed in other sessions, the Product Owner is responsible for establishing the priority of every Story Card in the Backlog. The priority is from number one to number last with no ties.
- The Product Owner can use any tools, techniques, or criteria that they believe are relevant when doing the prioritization.
- Priorities are usually driven by business goals or objectives for the project – such as customer/market needs and goals, compliance requirements, or productivity goals.
Product Backlog
- The prioritization is not fixed in the Product Backlog for the overall project. New stories can be added by the Product Owner based upon stakeholder input.
- Changes in project, business and industry conditions may result in changing the priorities of the stories in the Product Backlog.
- Normally the Stories are categorized using MuSCoWa
- Must have, Should have, Could have, Want to have
- The Product Backlog is normally prioritized to place all the “Must haves” in the highest priority positions.
- The Product Owner then considers the other categories and the number of Releases and Sprints to decide how to prioritize the remaining Stories – it is a judgement call.
- Expect that the Product Backlog will be revised following each Sprint.
- Some Stories are completed, some are not.
- Information learned in the Sprint may lead to the rewriting of a Story or the change in importance of some Stories.
- Most projects do not complete all the Stories on the Product Backlog. The “wish list” is greater than the amount of time and resources available.
Sprint Backlog
- The Sprint Backlog is normally a subset of the entire Product Backlog and is the focus of the activities of the Scrum Team during the Sprint.
- The priorities of the Stories in the Sprint Backlog are fixed for the duration of the Sprint.
- The priorities of the Stories in the Sprint Backlog are often different from the priorities in the Product Backlog because the Sprint is focused on the minimally viable product that supports the upcoming Release.
- The Sprint Backlog is often prioritized based upon Story category from a Sprint perspective with regards to supporting the Release. The categorization normally uses the MoSCoW categories:
- Must have, Should have, Could have, Won’t have
- The Scrum Team may need to add Infrastructure Stories that were not generated by a project stakeholder. These Stories are for capability that must be created in order to do the work in other stakeholder-requested stories. These Stories normally have a priority that ties them to the Product Backlog Story that they are supporting. These are identified during Sprint Planning and added to the Sprint Backlog at that time.
Hints and Tips
- Don’t agonize over getting the priority precisely right or wrong. There is always the opportunity to change it at the end of each Sprint.
- Start your prioritizing with the categories as a guide, but if prioritizing for an early Sprint or Release, consider what will make a minimally viable product for the upcoming Release. This often leads to some very different priorities for the Sprint Backlog.
Lesson notes are only available for subscribers.
PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.