Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery. Over the past couple of weeks, we’ve looked at how to write good user stories, how to use themes to manage your backlog, and how to measure and predict the impact of user stories. Today, we’ll take a high-level look at how to prioritize user stories.
Prioritization is a complex task. There is rarely one right answer. There are many factors at play and the best you can do is try to balance all of them. Here are a few factors you should keep in mind.
Themes
We’ve already looked at how to use themes to organize our backlogs. In general, you are going to want to prioritize user stories within each theme and then fill your sprint according to how your themes tie to business needs.
For example, if we continue with our event site example from previous posts where we have two themes: increasing number of events and increasing RSVPs, you can imagine that at any point in time, one theme might be more important than the other. If you are seeing that event creation is adequate but RSVPs are low, you might prioritize RSVPs higher than event creation. Or vise versa.
Typically, you want to start with understanding your high-level priorities before you start prioritizing user stories. Themes are a great place to start. For the rest of this point, we’ll assume that we are prioritizing user stories within a theme.
Expected Impact
As we discussed in this post, you should be able to predict the impact of each user story. This prediction can then inform your prioritization. This one is pretty straightforward. All things being equal, you will wan to prioritize higher impact items over lower impact items.
Time To Build
Time to build is often the counterbalance to expected impact. If one story takes 4 weeks and another takes 1 day, you probably want to do the one day story first. However, it’s not always this straightforward. Suppose one story takes 2 weeks with an expected impact of a 10% increase in event creation and a second story takes 3 weeks to build with an expected impact of 20%. You can start to see how these two factors might interplay.
What makes it even more complex is that we know going in that both our expected impact and our time to build estimates are likely to be wrong. Prioritization is much more an art than a science.
Fading Opportunities
Sometimes something will come up that won’t have the highest impact of may not be the quickest thing to build but due to some external factor may make it necessary to build right now. I refer to these as fading opportunities.
For example, you might want to add a feature to support the Superbowl. This only happens once a year, so regardless of expected impact or time to build, you are going to want to time the development to align with the event itself.
These types of things come up all the time. It might be a one-time event. It might be development to support a partnership. It might be an opportunity to ride a hot trend. Whatever it is, you want to make sure that your prioritization scheme isn’t so rigid that you can’t accommodate these one-off opportunities.
The People Factor, Or the Value of a Quick Win
Similarly, there will be times when you need to throw out your prioritization scheme altogether and go for the quick win.
Suppose your sales team is hearing the same request over and over again. You estimate it won’t really have an impact. It’s not something you would normally build but you don’t see it negatively impacting the product. Assuming it doesn’t take away too much from other priorities, this is the type of thing where you might want to build it anyway to garner good will with both your customers and your sales team.
Now I can already hear the product purists scream about feature creep and an unfocused product. But there’s a lot of gray area here. There will be times when this is the right decision. Don’t underestimate the value of good will and satisfying a customer request even if it doesn’t fill a real need. Of course, you want to make sure that you also satisfy the real need as well.
Technical Debt
Technical debt is a special kind of people factor / quick win. Technical debt is what is incurred when you take engineering short cuts to satisfy a business need quicker than you really should. It happens all the time. But if you do it too often, your engineers will start to get stressed out. You can alleviate this pressure by prioritizing some stories to pay off some of this technical debt.
This can be a hard thing to balance. Your engineers will always tell you there is way too much technical debt and that they need more time. The business side will tell you that there’s no time to invest in technology that doesn’t have an immediate impact on the business. Both are true. It’s your job to make sure that neither gets too far out of balance.
Putting It All Together
If you Google product prioritization, you’ll find many articles on the subject. There are countless spreadsheet templates that help you align time to build with must-haves and nice-to-haves. Some people argue that everyone should get a vote. I don’t think any one prioritization method is more right than any other. Different situations call for different methods. But no matter what method you use, you should take into account all of these factors. And more importantly, don’t kid yourself, product prioritization is more art than science.
What do you think? Are there other factors that you take into account when prioritizing your backlog?
