Now vs. Not-Now Prioritization Along with Medium-Term Goals

In last month’s newsletter I wrote about how we make personal financial decisions in a now vs. not-now manner. We don’t map out must-haves, should-haves, could-haves, and won’t haves. And I promised in this month’s newsletter, I would cover a simple approach to now vs. not-now planning while still accommodating working toward a bigger vision for a product.

I always recommend having a medium-term vision for where a product is headed. I find a three-month horizon works well. At the start of each quarter, a product owner should put a stake in the ground saying “Here’s where we want to be in three months.” This is done in conjunction with the team and other stakeholders, but the ultimate vision for a product is up to the product owner.

A product owner doesn’t need to be overly committed to the vision—it can be changed. But, without a stake in the ground a few months out, prioritization decisions are likely to be driven by whatever emergencies erupt right before sprint planning meetings. Without a vision, the urgent always wins over the strategic.

For choosing between competing ideas for a medium-term vision, I like using a formal approach—that is, something I can explain to someone else. I want to be able to say, “I chose to focus on such-and-such rather than this-and-that” and then show some analysis indicating how I made that decision. I’ve written elsewhere about relative weighting, theme screening and theme scoring—and we have tools on this website for performing those analyses.

But at the start of each sprint, a product owner needs to make the smaller now vs. not-now decisions of prioritizing user stories to be worked on in the next one sprint. Rather than using a formal, explainable approach for that, I advise product owners consider four things about the product backlog items they are evaluating:

1. how valuable the feature will be
2. the learning that will occur by developing the feature
3. the riskiness of the feature
4. any change in the relative cost of the feature

I do this by first sorting the candidate product backlog items on attribute one, the value of each feature. There’s nothing special about this; it’s how product people have prioritized features for years.

But I don’t stop there. I use items two through four to adjust the now sorted backlog. For the most part, I will move product backlog items up rather than down based on the influence of these additional factors. Let me explain what each factor is about.

The second factor refers to how much learning will occur by developing the feature. Learning can take many forms—for example, a team might learn about the technology being used (“this vendor’s library isn’t as easy as we were told it would be”) or a product owner might learn how well users respond to a new user interface. If the learning that will result from developing a particular product backlog item is significant, I will move that item up the product backlog so it is developed in the coming sprint.pro

As for riskiness, if a given risk cannot be avoided, I prefer doing that product backlog item sooner rather than later so that I can learn the impact of the risk. And so, I will move the product backlog item up into the current sprint. If, however, there is a chance of avoiding a risk entirely (perhaps by not doing the feature at all), I will move that product backlog item out of the current sprint. I’ll then hopefully continue to do that in each subsequent sprint, thereby avoiding that risk entirely.

Finally, some features can be cheap if they are done now or expensive if they are put off. When I see such an item on a product backlog, I will move it into the current sprint to avoid the higher cost of delaying the feature.

By combining the use of these four factors when selecting items for a sprint with a formal approach to establishing a medium-term, three-month vision, you’ll be able to successfully prioritize in a now vs. not-now manner within the context of achieving a bigger goal.