Backlog Tips

Blog:

Tips for prioritizing a backlog

One of the most important concepts for maintaining a product backlog is ensuring that everything (or at least enough for the next couple of sprints) is prioritized. I’ve seen that this can be pretty tough for some people, so here are a few tips.

Specific priority is key

I’ve been involved in some projects at other companies (mostly in traditional development methodologies) where the level of prioritization never goes beyond High, Medium, and Low. For an efficient agile project, user stories need to be prioritized specifically. Why? Knowing what’s next on the stack makes it easier for everyone on the team. The developer knows which user story to start working on next. The QA team knows which story they’ll be testing next. The BA and IA know which items they need to research and begin developing requirements for next, and so on.

Starting from scratch? Start with relative priority buckets

This may sound contradictory, but it’s not. I promise. If you’re just starting a project and everything needs to be prioritized, it can be daunting to put everything in a priority order. Instead, start with the relative buckets of High, Medium, and Low. Then, come back and provide a specific priority for each story.

If everything is high priority, nothing is high priority

A lot of product owners have a really difficult time even getting to the first step of relative priority. It’s easy to fall into the trap of labelling everything (or at least a significant majority of things) as high priority. Here’s how I like to look at the priorities:

High

  • The application will literally be a failure without this feature.
  • The user would get little or no value from the product without this feature.
  • The user will be unable to perform a critical function without this feature.
  • One of your project goals will not be met without this feature. (Hence, a good reason to have well-defined goals at the start of a project.)
  • In the case of an upgrade/rewrite project, I’ll also throw in, “This feature already existed in the system” - though you could often argue that one, too.

Medium

  • The project could ship without this feature and still provide adequate value to the user.
  • This feature is needed to keep up with a competitive product. (In some cases, this may be enough to push to “high” priority.)
  • This feature is an industry standard that most users will expect, even if not completely critical to usage or value from the application.

Low

  • This feature is generally regarded as “nice to have.”
  • This feature does not directly relate to any project goals.
  • This feature would enhance usability of an existing feature, but that existing feature isn’t causing significant, widespread barriers for users.
  • This feature will be utilized by a low percentage of users (ex. The 80/20 or 90/10 rules.)

After relative priority, then move onto specific priority

After putting everything into a bucket, start with all the high-priority items and begin putting those in a specific order. If you’ve got enough items identified for roughly two sprints, you can even stop prioritizing at this point, if you want. As long as there’s enough identified so that the analysis efforts know which order to continue, you’ve got enough priority. But if you’re feeling ambitious, it never hurts to have a rough idea of what’s coming down the road.

Start with business priority, then apply technical priority if needed

Sometimes even the business-focused product owners fall into the trap of putting things into an order that makes sense (or that they think makes sense) for the development team. For example, they prioritize “log in” as the highest priority because they think it makes sense for that to be done first. Simply stated, don’t do that. Start with business priority – what will give you the biggest bang for your buck. When you start “Sprint 0,” go through the backlog priority with development. Much of the time, they can work in that order, and build in the prerequisite pieces they need as they go (for example, define the concept of a user and have one default account without fully implementing log in functionality). If necessary, the development team can tell you when they really should (or absolutely must) do a specific story first because of technical priority. Keep revisiting this priority with the team each sprint so they can catch any upcoming technical priorities that may not have been obvious early on.

“Not now” does not mean “not ever”

For a lot of product owners, it’s difficult to flag a user story as anything other than “high” because they feel that it means the story will never get done. I won’t sugar-coat it. Sometimes that is the case. All projects are subject to deadlines and budgets, and often it can’t all get done. But, missing out on a medium or low priority items is a lot worse than the alternatives…

Pitfalls of bad prioritization

Here are a few examples of the bad stuff that can happen when you prioritize poorly and spend time on lower-priority items before the higher-priority ones:

  • You run out of budget for one of the critical items later in the project.
  • You identify another high priority item mid-project, but have no wiggle room to add it in.
  • It takes longer to get a product to your users.

Triumphs with good prioritization

If you do prioritize well, and put items in the correct order, some of the benefits you can see are:

  • Have a functional application to share with stakeholders or customers sooner, and be able to make changes based on that feedback.
  • Be able to react to market factors without losing critical functionality (Ex. A new feature idea comes in and you can put it in the backlog, bumping out a lower priority item.).
  • Save budget / time on features that you originally planned for, but later decide aren't needed.

Conclusion

Prioritizing well often requires some tough (and sometimes unpopular) calls from the product owner. But taking the time and thought to do it well can reap significant benefits later in the project.