Prioritizing the Backlog

Quick reference

• 00:04 Hi, this is Ray Sheen.
• 00:06 I'd like to talk the product owners now and
• 00:08 give them some advice on how to prioritize their backlogs.
• 00:12 Okay, let's get started.
• 00:14 I've already mentioned several times that the product owner must prioritize
• 00:17 the backlogs from number 1 to number last, no ties.
• 00:21 There is no set formula for this.
• 00:23 At the end of the day, this is a judgement call by the product owner.
• 00:27 But remember product owners, you need to ensure that you're representing
• 00:30 the interests of the stakeholders, not just your functional department.
• 00:34 You're the final say in all priorities, which also means
• 00:37 that you're responsible for much of the success or failure of the project.
• 00:41 So when setting the priorities, you need to approach this from the stand-point
• 00:45 of what is most important to the business.
• 00:48 If the project is to create a new product,
• 00:50 a very important consideration must be what is important to the customer.
• 00:54 If the product does not add value to a customer, there will be no sales in
• 00:57 the entire project is in a waste of business resources.
• 01:01 In some cases, the reason for the project is compliance.
• 01:05 A finding from a regulatory body or a customer created the need.
• 01:09 Or possibly there is a new set of industry standards that precipitated the project.
• 01:13 In those cases, the regulation or standard is used to set the priorities.
• 01:18 After that, you need to consider all the internal business department needs.
• 01:22 One department needs lower cost, another needs less rework.
• 01:26 One wants simpler interactions.
• 01:27 Another wants more timely data.
• 01:30 The product owner must sort through them to decide which is most important.
• 01:34 As the project unfolds, stakeholders will continue to ask if the project results can
• 01:38 provide just one more thing.
• 01:41 The nice thing about agile scrum projects is that you can always say,
• 01:44 yes, I'll add it to the list.
• 01:46 But it may not be the highest priority.
• 01:49 Over time, the product backlog becomes a running wish list of things that
• 01:53 the stakeholders would like to have.
• 01:56 I wanna take a few minutes to differentiate between prioritizing
• 01:59 the product backlog and the sprint backlog.
• 02:03 Let's start with the product backlog.
• 02:05 Recall that the product backlog is the entire list of stories for
• 02:08 the whole project.
• 02:09 On a large project, the product backlog is normally divided into multiple releases.
• 02:14 On a small project, there may only be one release.
• 02:17 I recommend that you start the prioritize based upon the MuSCoWa categories.
• 02:22 Recall these categories are must have, should have, could have, and want to have.
• 02:27 Often when talking with stakeholders,
• 02:29 they will say that they must have their requirements.
• 02:32 I suggest that you probe these statements by asking what the workarounds would be if
• 02:36 they didn't have their requirements, or
• 02:38 at least didn't have the level of perfection that they're requesting.
• 02:41 Many times there's a viable workaround,
• 02:43 and when that is the case, I drop the category to should have or could have.
• 02:48 In my experience, only about 10 to 20% of the stories are really must have stories.
• 02:54 You can continue to add stories to the product backlog right up until the last
• 02:58 sprint on a project.
• 02:59 In fact, I encourage it.
• 03:01 Often as the team or stakeholders get some experience with the new product or
• 03:05 system following a sprint demo they will think of opportunities to increase
• 03:09 the business benefit.
• 03:10 By all means add them.
• 03:11 Reprioritize the product backlog and do what makes sense for the next sprint.
• 03:16 It doesn't mean that you guarantee to do every new story, but
• 03:19 you can put it on the list.
• 03:21 Which brings us to the last point about the product backlog.
• 03:25 Projects seldom complete everything in the product backlog.
• 03:28 There is just too many items on the wish list for the amount of time and
• 03:31 money that is allocated to the project.
• 03:34 That's okay.
• 03:35 Make sure that whatever is delivered is a viable product, and save the list for
• 03:39 the next project, whenever it occurs.
• 03:42 Okay, let's switch over to the sprint backlog.
• 03:45 The sprint backlog is, of course, a subset of the product backlog.
• 03:50 Based upon the release plan, stories are selected for each sprint.
• 03:54 The categories often used with the sprint backlog are the MoSCoW categories.
• 03:59 Must have, should have, could have, won't have for this sprint.
• 04:04 The key here is that this is the sprint backlog category,
• 04:07 not the product backlog category.
• 04:10 The sprint backlog priority is normally different than the product
• 04:13 backlog priority.
• 04:14 The sprint is working up to a minimally viable product for
• 04:17 release that is often not the full and complete project.
• 04:21 Some of the product features may not be in this release that the spring supports.
• 04:25 Therefore, and must have story for the product backlog could be a could have or
• 04:30 even a won't have for particular sprint backlog.
• 04:34 Another change to the sprint backlog is that the infrastructure stores have been
• 04:37 added to the sprint backlog.
• 04:39 Infrastructure stories are not generally known or
• 04:42 understood by the external project stakeholders.
• 04:45 Yet if these stories are not complete, the scrum team is not able to do the other
• 04:49 project work to deliver the stakeholder stories.
• 04:52 This should be a clear relationship between the infrastructure stories and
• 04:56 some of the other stories in the product backlog.
• 04:59 It is possible, that you may have an early sprint
• 05:02 that is made up entirely of infrastructure stories.
• 05:05 That sprint may involve purchasing the equipment and
• 05:07 setting up the system to model and virtually test the product
• 05:10 in order to allow for design optimization and better scenario analysis.
• 05:15 The product backlog may not include any stories associated with that activity.
• 05:19 Yet by doing this infrastructure sprint, the scrum team can perform the testing and
• 05:24 analysis needed to fulfill the demo criteria on other stories.
• 05:29 In addition to the infrastructure stories,
• 05:31 another big difference between the product backlog and the sprint backlog,
• 05:34 is that once the sprint backlog priority is established, it does not change.
• 05:39 That is a priority for that sprint.
• 05:41 The demo criteria on a story card may change with the agreement of the scrum
• 05:45 team and product owner, but the priorities of the stories in the sprint are fixed for
• 05:50 that sprint.
• 05:52 You can't please everyone on prioritizing the product backlog.
• 05:57 So, give it your best shot and stay flexible.
• 06:00 You can change the product backlog priority.
• 06:03 A closer focus, though, needs to be spent on the sprint backlog where the priority,
• 06:08 once established, is fixed.

Lesson notes are only available for subscribers.