Planning by ROI.  Hmmm.  Isn’t that impractical?  In an econometric way, yes.  But you can still estimate the relative value of the capabilities / stories you’re planning for your scrum sprints.  The point is - don’t look only at value - also look at costs.  While “ROI” may be a poor choice of terms, “bang for the buck” is not.

Mea Culpa

In the previous article, Plan Your Next Spring By ROI: Part 1, I made a bad choice of sloppily using ROI (about a dozen times) to describe “bang for the buck.”

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.

[...]

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.

Plan Your Next Sprint By ROI: Part 1

[Editor: Note - the author has also messed up again, this time by burying the lead at the end of the article.]

Giants.  And Their Shoulders.

I had a great conversation over the weekend with Luke Hohmann, founder and CEO of Enthiosys, and realized my mistake.  Consider the titles of three (excellent) articles Luke wrote earlier this summer:

1. Why Prioritizing Your Product Backlog for ROI Doesn’t Work (Part 1 of 3)
2. Developing Attributes for Backlog Prioritization (Part 2 of 3)
3. Prioritizing for Profit (Part 3 of 3)

Not to mention giving a presentation at Agile’08.

You’d think I would have noticed, and been more careful in my use of language.  Sorry about that.

Luke, in his first article, provides several arguments against econometric assessment of ROI, and I agree with all of his points.  In his second article, Luke goes into details about defining attributes for reflecting the goals of internal stakeholders, external stakeholders (buyers and users), and the system.  I promised to do the same in this article, but frankly, why reinvent the wheel?  Our differences from Luke’s article would at best be nuanced, so the best use of your time (and mine) is to just go read his second article.

Our experience is that successful Agile Product Managers have an almost natural, intuitive feel for prioritizing backlog items to drive profitable growth. Fortunately, this natural ability is greatly enhanced when they make the link between the backlog and their ability to drive profit explicit. As an aside, it is this set of attributes that most clearly distinguish the Scrum-centric role of a Product Owner with the full responsibilities of an Agile Product Manager.

Developing Attributes for Backlog Prioritization (Part 2 of 3)

Including Costs in Sprint Planning

There are two dimensions by which to keep costs in mind when planning a sprint.  The first is in determining how much work to schedule for any given sprint.  When you use timeboxing to plan a sprint, you’re saying “we have the capacity to do X work per sprint” and “we should only schedule X work per sprint.”  Your plans are based on estimates, so you need to have a feedback mechanism to make sure you’re doing a better job in planning each sprint than you did with the previous sprint.  Burndown graphs are a great way to do this.  The burndown provides feedback within the sprint too, not just at the end.

Mike Cohn, of Mountain Goat Software, gave a great presentation on how to estimate costs for an agile project.  Without giving it away, he proposed (starting on slide 14) using planing poker to get quick estimates of user stories [more details] at the product backlog level.  Then, more detailed estimates are created for the tasks within the sprint.  If your team uses use cases, you can choose to use use case points as a low-overhead estimation method (but not nearly as low as planning poker) to determine the initial estimates of costs.

A Planning Example

You have the following set of items being evaluated in your product backlog.  Note that there are a mixture of strategic, user-centric, and code-refactoring items under consideration.

• Profile Editing - As an insurance agent in the community, I want to be able to edit my profile to personalize my identity within the site.
• Data Abstraction Refactoring - The system’s data model is inelegant and needs to be refactored, if ongoing development is to be easier.
• Action Notification - As a manager of agents, I want to be notified whenever my agents submit quotes to potential customers.
• Grouping Items - As an insurance agent, I want to be able to group contacts, proposals, communications and other items, so that I can organize my work.
• Reporting - As a manager of agents, I want to be able to run reports to track financial metrics and activities by agent, product, geography, and time period, so that I can manage my team effectively.
• Serializable Objects - The system’s implementations for data backup and data export are redundant and brittle and should be refactored to clean up the code.
• Customer Centric UI - The user interface is currently product-centric in approach.  Our strategy to offer multi-vendor product lines will require agents to focus on customers first.

Using the value-estimation and cost estimation techniques outlined by Luke and Mike you determine the following value and cost estimates for each “story.”

If you were to ignore the cost estimates you would do the data abstraction refactoring and customer-centric UI stories first, followed by the profile editing, action-notification, and other tasks in order of descending value.  As it turns out, that is not the way to maximize value over time.  At first glance, the profile editing story looks like the biggest bang for the buck.

Create a scatter plot of value versus cost.

[larger version]

You can clearly see the differences in value and differences in cost of the different stories.  If, however, you add the element of value/cost - bang for the buck - and prioritize by it, you will schedule stories in a different order.  Value / cost is also the slope of a line from the origin of the graph to each story.  If you draw those lines, you see the following:

[larger version]

To maximize value delivery over time, work across the chart in a clock-wise direction.  Profile editing is the first task, but grouping items and data abstraction refactoring are tied for second place.  This is different because you’re prioritizing by bang-for-the-buck, not just bang.

Collaboration And Agile

When you consider the agile manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

© 2001, the above authors. this declaration may be freely copied in any form, but only in its entirety through this notice.

you see that there is an opportunity to take this even further.

Have Developers Improve ‘The Plan’

I proposed an idea to the development lead on an agile team a couple weeks ago.  A couple hours later, he pinged me to let me know he had just applied it and was very excited.  A quick whiteboard session (started with a version of the diagrams above), and he was able to immediately make his sprint better.

I told him that when I was still slinging code, and later, when working with teams of engaged and talented developers, I often ran into the problem of having a “cool capability” and wanting to get that capability into the current release.  I wasn’t pushing for the capability because it was high bang-for-the-buck, or even high-bang - I just thought it was cool.  So I would implement it.  Bad Scott, no biscuit.

What I proposed was that when a developer has a favorite feature, instead of just trying to squeeze it in, the developer should figure out how to make it cost less, until it had the highest bang for the buck.  Each initial cost estimate is a planning-poker estimate.  By spending cycles on design, a developer can figure out a cheaper way to implement it.  And that moves the story to the left on the chart.

Your challenge, visually, if you want to bump reporting up in the planning backlog, looks like the following:

[larger version]

You, as a member of the implementation team, have to come up with a design for reporting that is roughly one-third the cost that was originally estimated.  Do that, and it gets bumped up in the queue.  [And yes, I realize that very few developers get excited about reporting.]

The product manager’s job is to make sure you get all the dots in the right place vertically.

The implementation team puts the dots in the right place horizontally.

Everyone embraces the ability to change the graph.  The product manager moves the dots up and down as she learns more about the needs of the market.  The implementation team moves them to the left (and sometimes to the right) as they design better solutions.

Quoting Luke again - “Our experience is that successful Agile Product Managers have an almost natural, intuitive feel for prioritizing backlog items to drive profitable growth. Fortunately, this natural ability is greatly enhanced when they make the link between the backlog and their ability to drive profit explicit.”

This feels intuitive to me.  What about you?

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment