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?
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.
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:
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:
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:
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.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.