Skip to main content

Using Agile to Optimize Value of Projects

I was asked recently for guidelines on "how to use value points in agile projects".  I was glad to get the question, since some people, like the blogger who writes "Agile 101," say stuff like: value points are "not appropriate or particularly necessary in all cases."  Gah!  The Agile 101 author actually goes on to do quite a nice job describing how to use value points, and I recommend you visit the blog, but I would like to explain why I don't think all of this is an optional nicety.

If you were CEO of your company and you were being briefed on your project every two weeks, what do you want to hear from your agile team?
  1. "We delivered 14 value points this iteration" (which translates into some specific thing the company values, in terms of cost avoidance, expected revenue within a portfolio, increased quality, or faster time to market)
  2. "We delivered 14 story points this iteration" (which translates directly into "2 weeks of effort")
I think the answer is pretty clear.

Jim Highsmith first published details of this proposition in this blog entry on the Cutter Consortium site, and expands on it in the second edition of his watershed book, Agile Project Management.  In his book, he also expands on this concept of the "Agile Triangle" of Value, Quality, and Constraints, which replaces the traditional Project Management Triangle of Cost, Schedule, and Scope.

From Highsmith, Agile Project Management, Second Edition, 2009.
Highsmith's proposition is that when your company embarks on a project, you are making a financial investment in order to produce something of value to the company.  That value has two dimensions:
  • Value (extrinsic quality), which must be determined by the people in your company who are going to use the new software to create revenue for your company.  They will sell the software, or sell the things the software help them to build, and they should have an idea from market analysis and company strategic goals why they want to spend money on the project at all, and how much money the project is worth to company owners (stockholders, public bodies, or a private individual).
  • Quality (intrinsic quality), which must be determined by your software architects.  They will maintain the software you are building over time, and their goal should be to minimize the cost of this maintenance over time.
Product managers can predict the revenue your company will gain from completing each feature of the project, and architects can predict the revenue your company will lose over the projected lifespan of the project by cutting corners in design at the outset.  "Cut corners" in design are what Highsmith and others call "technical debt."  Bad software is a hidden cost waiting to hit your company in the future, when you suddenly want to do something new and find you can't do it without starting all over, because what you built isn't flexible.

So as a company invests in a project, it should maximize the immediate and long term value from that investment, while operating within the constraints of cost, time, and potential features to be included.

Okay, you say, I feel motivated today.  I want to maximize my project's value, not just track the cost of the effort to deliver it at full scope.  How does that work?

Here are some mechanics:
  • For each project, assign an IT Lead to monitor what Jim Highsmith and others call "technical debt," so that as the software is developed, expected costs of maintenance do not cut into the financial values being tracked by the Product Owner.
  • For each project, assign a Product Owner, a decision maker whose job it is to predict, record, and then update the business value parameters for the project.  These consist of:
    • Project value:  the overall value of a planned software project to your company (predict at project inception, and update before each release planning meeting as needed).  This can be a financial return on investment, or some other appropriately quantified measure, such as increased speed to market, increased quality, or avoidance of future costs.  Cost avoidance could include such factors as regulatory compliance to avoid fines or building software to allow something new to be done in an automated way, rather than taking on new staff. 
    • Feature value:  the relative value of each requested software feature which is planned as part of the overall project (predict during project inception and update before each release planning meeting as needed).  Feature value should be determined through a method such as planning poker, which allocates value to specific features on a relative basis.  So the Product Owner should gather the right people together to think about the expected high level features of the project, and assign a "points" value to each feature.  Once a sum of points is established, that can be mapped to the overall predicted financial value of the project as a whole, and each value point is worth some fraction of that overall value.
    • Story value:  the amount of feature value delivered by each story, where each feature is divided into stories which can be delivered in 1-5 days.  The rule is that the story must provide some recognizable business value on its own.  (Assign as stories are carved out of features, during release and before or during sprint planning).  After the team determines which features should be targeted for a release, the first features to be delivered within a release should be divided into stories which deliver some proportion of the feature's business value in their own right, end to end.  Stories should be things which can be completed within a sprint.
You can readily see that once you are tracking value at project, feature, and story level, you can do a whole bunch of excellent things, each of which optimizes your company's bottom line:
  • Plan your portfolio:  now that you know the overall expected return on investment of a project, you can weigh that project's risks and potential returns and determine when to make it part of your active portfolio.
  • Speed up and maximize the return on investment for all of your projects:  each project is executed as a series of releases which have the most valuable features in the earliest release, and the most valuable work delivered earliest within each release.
  • Graphically track the value delivered by the project during each sprint and for whole releases, using a "value burn-up," (exactly like an "effort burn-up," but measuring something a lot more interesting to your CEO)
  • STOP your project once you get decreasing returns on investment, in favor of starting a different project in the portfolio which has higher-value features still to be delivered.
  • Collect returns on the working software through the expected lifespan of the design and beyond.
One final point.  Agile software development is premised on avoiding "Big Upfront Design" (BUFD), and so projects are started with some minimal inception phase to lay out an initial architecture design and an initial effort estimate.  All designs and estimates are expected to change over the course of the project as more is learned.   

Value points should not take years to estimate any more than your effort points do, even though they result from different techniques.  Do not leap out of the frying pan of the BUFD into the fire of Big Upfront Value Modeling (BUVM, sadly not pronouncable). 

Your decision-making Product Owner should try hard to limit the time she spends estimating its value.  Just as you shouldn't "start coding" on day 1 of an agile project, you shouldn't "pick a number out of a hat" as your business case.  But neither should you over-analyze, since you expect to be enhancing and revising your business case as the project proceeds.  And of course the market is going to be changing during that time anyway!  So as the project unfolds, the Product Owner should plan to revise the overall predicted project value and value of desired features on a regular basis, and the whole team should plan to adjust release plans appropriately as they go.

The main point is that value points, like their better known cousins, effort (or "story" points), can and should be estimated, written down, adjusted, and used for planning and reporting purposes by project teams.  They can be estimated in Planning Poker, burned up, burned down, and written in the upper-left-hand corner of your story cards.  ONLY value points, however, can tell you how well the project is returning on investment.  And that's why I don't think they're ever optional.

Comments

  1. Hi Elena

    I found this very interesting and in line with a lot of my own idea.

    I wrote some stuff on Value Driven Development which you may find useful: http://jupitermoonbeam.blogspot.com/2009/07/value-driven-development.html

    ReplyDelete
  2. Thanks for the link, Peter--sorry I didn't get back to you sooner! -E

    ReplyDelete
  3. Hi,

    I think this approach assumes that features are parallel, largely independent things that each have value in their own right? This assumption does not hold for systems that are a sequential pipeline of operations - the entire system has value, but each component in isolation has zero value. As a metric to characterize this, we could use the ratio of the 'minimum marketable feature set' to the entire feature set / backlog (though one could argue that in this scenario, the entire system is really one huge feature).

    Regards,

    David.

    ReplyDelete
  4. Hey David, for pipelines, I would use a tool like Jeff Patton's Story Maps, where the "base level" assumption would be that the pipeline as a whole (or perhaps some separable chunks, if they are meaningful) would need to be delivered almost from the first iteration, but the amount of embellishment and depth of feature around each stage of the pipeline could be valued comparatively.

    So you might allow for some manual processing in your first release, either as part of an automated step, or instead of an automated step, if the rest of the automation gave you a big operational savings boost on its own.

    I agree that almost nothing in corporate software is as conveniently "chunkable" as the pizza store web app. :-) Cheers,

    Elena

    ReplyDelete
  5. Hi Elena,

    Thanks for the link to Jeff's blog, that nicely pulls together a few ideas I'd seen elsewhere from Jeff and others.

    I agree the 'walking skeleton' with incremental embellishment is a good model in many cases (though there remain some tough cases when dealing with embedded systems, security reviews, etc...)

    Cheers, David.

    ReplyDelete

Post a Comment

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica