4.5: Prioritization in Agile - Video Tutorials & Practice Problems

<v ->Let's talk about prioritization in Agile.</v> It is important to prioritize element in a product backlog. This is done top to bottom in a thoughtful and methodical way. There are some common mistakes. Let's look at those. Number one is when a product backlog items comes before its prerequisites. For example, if there is a user story to select a book from the list, then the repository of books available for sale should be established first. As an exception, it's possible to test the user story with some mock data. In this case, they should be a sub-task to set up mock data in a relevant format for testing purposes. But it's better to avoid it all together. Number two. Product backlog items on the bottom of the backlog are all defined. Acceptance criteria there, details are there, but the items closer to the top lack acceptance criteria. This violates the lien just in time principle and creates waste. Because by the time the team gets to work on the lower priority items, either the need will change or there will be further details that require rework and further redefining those user stories. So don't work too much on the items on the bottom of your backlog. The third one is about prioritization. How do you actually, as a product owner, decide what's the highest priority? The worst way is if you base it on the loudest voice in the room. It could be whoever is the boss, or the most assertive person, or literally the loudest voice. And this happens a lot when more senior stakeholders insist on prioritizing requirements, and then those requirements are considered most important. The team should argue, but sometimes they don't because of the seniority of this person. It is important for the product owner to validate any assumptions. And do user research as described in lesson three. This way prioritization becomes objective and straightforward. Fourth one is when prioritization is based only on user value. Because prioritization is usually a combination of multiple factors, however, you have two primary criteria. The primary criteria are user value and the effort to develop this functionality. The higher value and low effort user stories are usually prioritized top to bottom in the backlog. You can see an effective prioritization technique shown in this slide. But these are not the only criteria that impact prioritization. Experienced product owners usually have comprehensive prioritization rules. And usually those are based, besides business value and complexity, on the whole set of criteria. That could include government regulations, contractual responsibilities, prerequisites, system and business constraints, and so forth. For example, the logic presented in this slide is impacted by the number of constraints. For example, user story 1.2 describes a regulatory requirement. And it has to be implemented by a specific date. In this case, it doesn't matter if there is a significant effort to have it implemented. In this case, the user story gets prioritized just in time based on the date when the regulation goes into effect. While product backlogs represent a hierarchical structure and usually have parent-child relationships, they're not usually created as such. An effective technique of creating a balanced and well thought through product backlog is referred to as user story mapping. We'll discuss it later when we talk about product backlog refinement.