5 Agile Estimation Tips To Help With Backlog Prioritization

Backlog prioritization is a never-ending task for product owners and product managers. As priorities evolve in response to changing business needs, or even as work is completed, or adjustments to team resourcing are made, it's important to maintain focus on the work that will deliver the most value by keeping your backlog in good shape. Agile estimation techniques can make prioritizing your backlog faster and easier.

So, let's take a look at some specific methods to prioritize your backlog and see how agile estimation can help deliver the most value to your end-users and stakeholders.

5 ways to prioritize a backlog

Of course, there are more than five ways to prioritize work items in a backlog. But, we've picked a few of our favorites that, when combined with an agile estimation process, help keep our product backlog prioritized so we can breeze through sprint planning.

1. Weighted Shortest Job First

Wow, is that a mouthful! Let's use the "WSJF" acronym to refer to this SAFe technique. Not as intimidating as it sounds, WSJF is a simple formula that assigns a business value to product backlog items.

WSJF = Cost of Delay ÷ Job Duration

Cost of Delay is the sum of three relative metrics:

• User/Business Value: the relative importance of the work item.
• Time Criticality: the decline of user/business value over time.
• Risk Reduction: the reduction of business or technical risk.

To determine the relative size for Cost of Delay, think of the lowest business value, the smallest decline in value over time, and the least risk reduction as a 1 value. The same as with Fibonacci sequence story point estimation, adjust that score appropriately when comparing work items to score them relative to one another.

The Job Duration is also expressed in relative terms. If you estimate your work items using relative estimation with story points, the story point value equals the Job Duration.

If you're using this technique to prioritize a large amount of work in a backlog where some items have only been t-shirt sized, convert your t-shirt sizes to standard Fibonacci numbers and use that value.

Warning: Be careful with converting t-shirt sizes to story points. You'll need a way to flag the t-shirt size work items that you converted to story points. You and your Scrum Master need to recognize those as t-shirt level estimations rather than the real story point estimates that come with fully refined work items.

2. MoSCoW

Must-have, should-have, could-have, and won't-have are the buckets used to prioritize a backlog with the MoSCoW technique. The product team defines these designations based on the product's unique features and competitive offerings.

Each work item falls into one of those categories. The easiest part of this process is sending Won't-have items directly to the trash and getting them out of your way. Next, prioritize must-haves first and then should-haves. The could-have items naturally fall to the bottom of the backlog.

Take these items through your regular refinement meetings with your team members, and assign each item a t-shirt size or story point value. You're then ready to add the right amount of work items to your sprints or releases based on your teams' velocity or the number of story points they expect to finish during a sprint.

3. Kano

The Kano model of prioritization uses five classifications:

• Must-be: the basic functionality that your users expect.
• Attractive: a pleasant surprise for your users, but no one is going to be upset if it's not there.
• One-Dimensional: work items that make your users happy and will disappoint them if they aren't part of your product.
• Indifferent: work items that are unimportant to your customers. Often, these work items represent technical debt or enhancements that help the software development team develop more efficiently or work in the latest versions of their tech stack — but your customers really don't care about them.
• Reverse: the process of undoing a previous feature or update. If you've ever built a feature or made a UI update that your users hated, you understand reverse work items. Oops. Unfortunately, sometimes these are necessary evils, especially when it comes to security features or transitioning users to a new product after retiring a legacy product.

Like the MoSCoW method, you'll estimate these work items during refinement and then add them to your iteration or release plan. But, different from MoSCoW, you may want to balance out your sprints and releases with work items from each classification.

4. Stack Ranking

The most brutal of all prioritization techniques, stack ranking forces teams to have a linear rank of work items, which means there is only one top priority, one second priority, one third priority, and so on. Brutal!

Once you get used to it, stack ranking is a useful way to force product managers to make tough choices between work items. Even if two work items can be completed during the same sprint, it's up to the PO to determine which one gets done first, and then that choice is reflected in the sprint backlog.

Often, this job becomes easier when it's put in dire terms. For instance, if you only had one day to attract new users to your product, what work would you want in production? BOOM! There's your top priority.

The nice thing with stack ranking is that it allows POs to slide smaller work items into current sprints when other higher-priority work is too large. Adding the larger work item over-commits the team based on their velocity. Those small work items serve to fill up sprints so teams can maintain velocity and be as productive as possible. So, just because a two-story point work item is two-thirds the way down the backlog doesn't mean it will never get done.

5. Story Mapping

Story mapping helps you visualize the customer's journey through your product from start to finish. (Yep, we stole that straight from our other excellent article on story mapping.) For advanced story mappers, take what you’ve learned about story mapping, and think about how you can add MoSCoW or Kano techniques to your story maps.

Perhaps your epic backbone at the top of the user story map could represent the buckets in the MoSCoW method?

If you're like us, your story mapping sessions are productive brainstorming activities, and you'll leave the sessions with way more work than you can accomplish. By applying MoSCoW or Kano principles to the stories in your user journeys, you’ll discover the most important stories to prioritize and the stories that can wait for a later release.

Building agile estimation into backlog prioritization

We've given you five different techniques to corral your work items into an organized, prioritized, value-delivering product backlog:

1. Weighted Shortest Job First
2. MoSCoW
3. KANO
4. Stack Ranking
5. Story Maps

We've also shown you ways to incorporate agile estimates like t-shirt sizes and story points into your prioritization process to keep your team delivering the most important work while maintaining velocity and dazzling your customers and stakeholders.

We encourage you to take these ideas, share them with your team, and give them a try. If you need help using the Story Map concept, try Easy Agile TeamRhythm. However your team prioritizes its product backlog, remember to put the most important work first and then adjust those priorities as needed. Keep it easy and keep it agile!