Appendix B. Estimating Business Value

“What’s it worth to you?”

Anonymous

Creating software is about delivering business value. Without some measure of business value, it’s hard to determine whether the software has any.

Business Value

Every feature in a system such as Sam’s should have business value. Business value can come from numerous areas, such as these:

• Increased revenue (sales, royalties, fees)

• Decreased expenses

• Using fewer resources

• More efficient use of resources

• Customer satisfaction

• Product promoters/satisfiers/detractors

• Staying in business

• Avoiding risk

Business value in some areas is easy to quantify because it is straight dollars. However, in other areas, quantification is more difficult. But without some way to compare these “apples and oranges,” it is hard to determine which stories should have higher priority. For example, should a story that saves $10,000 be prioritized over a story that gives customers more satisfaction?

One way to compare is to assign a relative business value to every story. The customer unit has the responsibility to assign business value. The business value does not have to be an exact measure. It’s just relative. If the $10,000 savings seems to be the same as giving customers more satisfaction, the stories have the same business value.

Relative determination may be made by putting the stories on the wall one at a time. If a story has more business value than another story, place it above that story. If it has less value, put the new story below, or if about the same, on one side. If a story fits between two stories, move the stories and make space for the new one in between. For example, in Figure B.1, Story Two has the highest value, Story One and Story Three are about the same, Story Four has less than those, and Story Five has a lot less.

Figure B.1. Relative Story Placement

You can use a Fibonacci series (1, 2, 3, 5, 8, 13...) or a power-of-two (1, 2, 4, 8, 16, 32, ...) series to assign stories in each row a value (see Figure B.2). Where you start with the numbering is not important, as long as you assign the same numeric value to equivalent stories in the future.

Figure B.2. Relative Story Values

Periodically, you can measure the cumulative business value of the delivered stories (see Figure B.3). Because the key in agility is to deliver business value quickly, such a chart provides feedback for everyone to see the project is progressing.

Figure B.3. Business Value Chart

The developer and tester unit can estimate story effort in story points using the same technique they used for business value.¹

A story’s business value estimate divided by the estimated story effort yields rough return on investment.² It is a rough guide to the relative return on investment. It can provide another value when the customer unit decides what stories to develop.

If the iterations involve approximately the same relative amount of effort, then the slope of the business value curve is roughly the return on investment. The rate of increase in business value may be lower in the initial phases of a project as either the business or technology domain is being learned. After an increase in the rate, it may slow down when stories that have a lower return on investment may be worked upon. At some point, the rate will be such that the project should be terminated. There certainly will be other potential projects that have higher return on investment.

Developer Stories

If a story is estimated to take a long time to implement, you can break it into smaller stories. However, the customer unit must be able to realize business value from one of the smaller stories. If he cannot, the smaller stories are developer stories; they exist to make it easier to track units of work. There may be technical value in completing a business story, such as having a new display component or a new service. When the technical value story is incorporated into a business story, the business value is credited.

As noted in Chapter 15, “Events, Responses, and States,” and Chapter 16, “Developer Acceptance Tests,” the developer should create an acceptance test for every developer story. Depending on the story, it may not be possible to create a specific test until there is collaboration with the implementer, but you should have at least some criteria to be able to know when the story is done.

Summary

• Estimate the business value for stories.

• Track the cumulative business value for delivered stories.

• If necessary, break stories into developer stories for tracking.

• The business value for a story is not achieved until all associated developer stories are completed.