Prioritizing the Backlog

What is prioritizing?

An ideal product backlog is a list of all the product-related tasks that need to be completed. This includes only the tasks needed to be done to complete a project or product and nothing else. Unfortunately, in the real world product backlogs are rarely so well defined as to know exactly what needs to be done to complete a project. Project goals may shift, other products may come on the market, the customer may want something not originally discussed. Prioritization is a way of cutting the bloat from the backlog and helping a team focus on the important tasks. It involved identifying the important features to make the product work. On top of identifying and ranking the core features to get a product working, prioritization also identifies those features that may not be necessary but are desired by the customer.

Benefits of prioritizing.

Prioritizing helps the team understand what is important to the client. If the client isn’t involved in prioritizing the backlog then features that are not important or not needed may get built before those that are critical to the client’s success. It also helps the team to see where a project is headed and know what to expect in upcoming sprints. When the backlog is not prioritized each sprint’s tasks are at the whim of the scrum master or product owner or worse, the lead developers.

Prioritized backlogs allow the team to manage dependencies so that they are built in order and remove obstacles before they impede work. Time is saved in planning meetings because the next sprint is based on the top priorities, or filling in space based on the capacity of the team. Having a prioritized backlog means you know what stories will be coming next and if there is extra capacity in a sprint know which stories to pull into it. More likely there will be reduced capacity, knowing the importance of each story means you know which ones that you can remove from a sprint if the capacity is reduced.

Pitfalls to avoid when prioritizing.

The prioritization methods do not make sense to the team. Without specific methods it can lead to the product owner or scrum master assigning priority based on whim or what they think is important.

Items dependencies are not considered when prioritizing so that a high priority task may depend on a much lower priority task that won’t be built yet. This can happen when there is a limit understanding when prioritizing or when the product owner doesn’t understand the technology.

Customers are not involved at all in the prioritization process. This leads to an internal only view of the project so that the actual users aren’t involved in what is being created.

There are too many items in the backlog that are of low priority. Many times these slip through the cracks and the product owner doesn’t know how they even made it into the backlog.

Stack Ranking

Each item in the backlog is placed in a ranked order (1st, 2nd, 3rd…nth). When selecting tasks to complete start at the top and work down. Items can be prioritized in relation to other items in the backlog reducing confusion. The absolute value assessment means that there is only one top item in the backlog and removes the chance of everything being high priority. This is good for smaller projects or backlogs or subsets of a larger backlog. However it can get cumbersome when ranking a large or very large backlog. Stack Ranking can also cause troubles when dealing with dependencies between tasks because you have to know the dependencies up front and build the tasks in a particular order.

ICE Scoring Method

ICE was created by Sean Ellis as a way to prioritize growth experiments, however it has come to be a popular method of prioritization for any project. ICE is an acronym that stands for Impact, Confidence, and Ease. Each one gets its own numeric score compared to other items in the backlog. Impact asks the question of how impactful the feature will be in the overall application or project. Confidence asks how confident are we that the feature will prove the hypothesis, or in software development how confident are we that the feature will solve the problem that needs to be solved. Ease asks how easily is it to move from initial development to launching the feature. The three scores are multiplied together to form the total ICE Score. This is used to rate the backlog and determine which features are the most valuable.

MoSCoW Technique

Data scientist Dia Clegg created the MoSCoW method of prioritizing tasks based on his work in Agile software development. It’s an acronym for 4 criteria for prioritization: Must have, Should have, Could have, and Won’t have. Must-Have criteria are the features and items that your project must have in order to function. Not having one of these items will delay deployment of the application. These are non-negotiable items as there is no work around for not having these items in your application. Should-Have criteria are important to the functioning of the application but are not essential or absolutely vital for it’s functionality. They are necessary but can wait as a work-around can be built or put into place until the item is developed. Could-Have criteria are the items that are not essential nor important. These are desired features that are not critical to the applications functionality. Won’t-Have criteria are ones that will not be in the current release. They are still considered important to the project but reserved for a future release. Each item in a product backlog is placed into one of these categories. The sprint backlog is then taken from the top categories to fit into the sprint.

Kano Model

Whereas the MoSCoW technique is more product driven, the Kano Model has a market-driven approach to prioritization. It derives it’s name from Professor Noriaki Kano who created it in the 1980’s. The backlog items are categorized based on the needs and expectations of the end user. There are several variations of the Kano Model. The original uses five categories: Must-be, Attractive, One-Dimensional, Indifferent, and Reverse.

Must-be features are the ones that must be in the product for it to function as expected. They are not up-sales or “big WOW” features. Attractive features are ones that make the customer happy when they are included, but the customer is not disappointed if they are not there. These are window dressing for the application. One-dimensional features are attractive in that the customer is happy when they are there, but they are also not happy if these features aren’t there. The difference between these and Must-be is that the basic functionality of the application is not hindered by these features. Indifferent features or backlog items are ones that do not affect customer satisfaction. These may be boilerplate or setting up items. They could also be refactoring that will make code easier to read and maintain but not directly affect the user experience. Reverse features are those that make the customer unhappy when they are there and happy when they are not there. This could be a two factor secure login. Customers not interested in extra security may find this feature annoying.

Adopt or develop a way to categorize or group the items in your backlog.

Breaking down the prioritization process starts with creating categories to place tasks. The idea is to be able to quickly chunk tasks into these catagories for organization. Catagories can be things like task size (large, medium, small), priority (high, second-level, low), or need (must have, want to have, nice to have). They can even be things like requirement status (refined, to be refined, not started). Tasks will fit into multiple catagories. You will have high priority tasks of all sizes and stages of refinement. However, if you have a low priority, must have task consider that it is either higher priority or not a must have. Priority is a matter of imminence whereas need is a matter of prominence.

Once you have your catagories you can quickly place tasks into them and organize your backlog by category. For example, you may choose to organize by need then filter by status followed by size. This would give you a catalog where the top items are the must have tasks that are refined and the largest pieces of work. The tasks at the top of your backlog will be the ones you pull into your next sprint. You may find that you pull up a second-level must have because it is smaller and you don’t have any small high priority must haves.

Remove tasks that are below second level priority from your backlog.

This is a way of keeping the focus on what is important and not falling into bike shedding. Removing the lower priority tasks from your backlog will keep the team from losing focus on what is important. It also applies to categories like need, don’t have anything below want. However, this concept doesn’t apply to all categories, you may have a very small but highly important task. The idea here is to make your product backlog as lean as possible while still getting the essential tasks and features needed to build a working product.

As for the lower priority, lower need tasks, build a secondary backlog or list of ideas. This may be feature requests that are not essential to the initial product or placeholders for features in future releases. Don’t throw away ideas because they are not the most essential or important right now, they may be the next million dollar idea just waiting to be developed. On the same note, ideas that come up during brainstorming sessions shouldn’t be tossed away just because they don’t relate to the current project. Keep track of ideas that you have working on this project for your next one.

Develop or adopt a system of allocating resources to each item in the backlog.

Each task should have an estimate on how much work it will take to complete. This could be the altered Fibonacci of SCRUM or directly assigning the number of hours it will take a developer to accomplish the task. Developers aren’t the only ones to consider when determining resources. Code review and any other types of processes need to be considered here. Some tasks will also require Ops or DevOps to help set up. Most will need to go through some sort of QA process, hopefully you have a separate QA on the team.

When estimating time lean toward overestimation. There will almost always be something that you don’t expect. If you get a task done in less time than expected you look like a hero, if you take longer you look like a zero. Be the hero your team deserves and overestimate. Developers aren’t interchangeable cogs, no matter how much some places want a fully cross functional team. We each have strength in some areas and weaknesses in others. We also have different interests and will want to work in specific areas or have more knowledge in some than others. Therefore, don’t expect the system you use to be perfect at estimating what any one developer can do on any given task.

Re-prioritize your backlog on a scheduled, regular basis.

Your backlog is like your code, it’s going to change as the project evolves and grows. Items at the top of the backlog will be moving off with each sprint and the ones further down will get moved up toward the top of the backlog. As you go through further refinement previously un-prioritized tasks will now have a place in the backlog. They may even bump some tasks down based on the priority. The top of the backlog is not likely to change much from refinement as that needs to be stable to prepare for the next sprint. However, emerging needs may require a task to be placed at the top. This includes occasionally reviewing and reordering the low priority list. As the project grows and changes an item that was once low priority may move up because it relates to a functionality that you didn’t know was needed.