Plan Your Next Sprint By ROI: Part 1

You’ve got a giant backlog of user stories and product capabilities. How do you determine which stories to implement right now? By the estimated value of each story? Pick the ones the developers want to build next? How about picking the stories that maximize the ROI of the sprint? To do that, you need to estimate both value and cost. While remaining agile.

ROI Refresher

In our earlier Definition of ROI: Return on Investment article, we provide an explanation and example of calculating ROI. In short, ROI is the acronym for return on investment. How much return do you get, as a percentage of what you have to invest. If you invest $100 to get $120, your return is $20 (the profit). Your investment is $100. Your ROI is 20% (20/100). Another way to think about it is bang for the buck.

Prioritizing by ROI versus Prioritizing by Value

You can prioritize based on value – “Do the most valuable thing first.” And that is a good, but suboptimal approach. We even suggested it as “the best” prioritization technique in our prioritization article from almost three years ago. Since then, by continuing to focus on software product success, I’ve learned to believe in a better way.

Just over a year ago, we showed how prioritizing by ROI delivers value faster. The reason this works is that each sprint (or timebox) has a fixed capacity for work, so you want to cram as much value into that box as possible – not just do the most valuable thing first. Here are a couple images from the previous article that show the impact of using this approach.

Identified stories, from highest value to lowest value (V = Value, W = Work (or cost)).

If you can schedule 30 units of work in a sprint, your first sprint will deliver 19 units of value, and your second sprint will deliver an additional 9 units of value. The thirs sprint delivers the remaining 15 units of value. Why more value in the third sprint than the second? Because you didn’t sort by ROI, you sorted by value – but were constrained by cost. When you sort by ROI, you get the same tasks, in the following order:

With this sorting, your first sprint delivers 25 units of value, your second sprint delivers 9 units, and your final sprint delivers an additional 9 units of value. There are more details in the original value-maximization article.

This is critical to executing a market-driven strategy that will dominate your competitors. You not only have to stay tapped in to the market needs, but you have to deliver faster than the other guys, or your distinctive insights will be wasted.

Political Prioritization

Really? Yes. The first risk to the success of a project is that it gets canceled. Only the projects that don’t get killed even have a chance to be right, and therefore maximize value for your customer (or company). That means you need to prioritize in a way that satisfies your stakeholders. After attending last year’s IBRF, I wrote the following article as an interpretation (and slight extension) of Roger Burlton’s very good presentation about process improvement. When you’re tasked with improving a company’s processes, the first question you have to ask is “which ones should we improve first?”

From that article:

This analysis focuses on principal stakeholders. The goal of this analysis is to encourage your principal stakeholders, or sponsors, to prioritize the most valuable processes first. Not all stakeholders are created equal, so you have to weight the relative importance of each stakeholder. You can weight them politically, by influence, or by whatever factor is most likely to get buy-in from the executives.

Stakeholder Value Matrix

The end result is a prioritized list of processes to improve, based upon which ones cause the combination of most pain (current state) and most gain (when improved) across your stakeholders, based on maximizing the utility of the group of stakeholders.

Visually, the preceding diagram shows the end results of aggregating the stakeholder inputs in terms of pain and gain. A couple utility curves are overlaid (arrow shows increasing utility) to show what to do first. The 1,2,5 processes are clustered together in the “highest utility” or “most value” range. This approach would focus on those processes first.

Persona Prioritization

When developing software, you should primarily be user-focused. [Note: this is somewhat of a religious debate, I guess we worship at the chapel of UX.] Luckily, most of the time, stakeholder goals and user goals are not in conflict. However, to sell your solution, you need to make sure you are addressing both buyer goals and user goals. Sometimes they are the same, like with consumer products, and sometimes they are not, like many enterprise software products.

As a product manager, you have to know when to listen to, and when to ignore the squeeky wheels. If you’re in a start-up doing its second product, solving a new problem for a new market segment, you’re dealing with founder’s dilemma. That founder has a bunch of stakeholder goals for you, and the juice to make sure you address them. If you’re trying to get analyst’s attention [good article by April Dunford at Rocket Watcher], you may feel pressured to prioritize “check the box” features that may be important only to buyers and analysts, without actually adding value for the users.

Of course, you can’t ignore analysts and buyers and internal stakeholders. If your product gets cancelled before you get to market, you’re done. If analysts criticize or ignore your product (for some markets), you lose a lot of sales. And if buyers don’t “think they want it”, they won’t buy. You never get a chance to demonstrate value to the users.

But focusing solely on those folks means you won’t have a product that people love, and you won’t generate word-of-mouth, customer loyalty, or value for your customers.

So any solution needs to account for the needs of the users. Organizing users into personas, and making strategic decisions about which ones are important will help. Include the other people (buyers, etc) but use a persona-centric model for describing what you’re doing – just to make sure the users are at the center of your decisions.

Intermission

So far, we’ve argued that prioritization should be by ROI, and while accounting for other people, should be user focused. Actually, nothing above is sprint-specific, the same concepts apply to any product planning and development approach.

In part 2, we’ll look at defining user stories and user persona. We’ll look at the value of each story relative to cost, and show a couple low-overhead ways to easily visualize this info – both driving scheduling and motivating the team to improve.