- X (development story, one for each alternative flow); and
- Stress-test the feature for 500 simultaneous users (test story, done when we have a validated testing regimen that passes).
Work Breakdown Structure
Management needs a view of the work that shows the "big picture." Luckily, standard project management has such a structure already invented for us - the Work Breakdown Structure (WBS) - which is a "deliverable-oriented grouping of project elements which organizes and defines the total scope of the project. " Many agilists cringe at the mention of a WBS because of its ‘high ceremony' connotations, but I use it merely as a way to categorize or organize my stories into areas. The WBS that I use organizes the work into three main areas:
- Product - work that is directed to actually producing the software product;
- Team - work that allows/enables the team to be able to produce the product; and
- Business - work that allows the business to market, sell, install, or deliver the product to users.
Each project is different and the actual structure of the WBS (what rollup buckets there are) is a business matter, because the WBS is primarily used as a tool for organizing the work in ways the business can understand. The stories that live at "the bottom" of these buckets define the work being done. A WBS for a fictional development project appears at Figure 1.
Figure 1: Sample WBS
Let's use this WBS to calculate business value.
Calculating Business Value
We do this in a straightforward way and provide the business value of any WBS bucket, including stories (the ones at the bottom). We note that the Business Value metric we are calculating is actually a percentage, not a dollar value.
First, we assign additive weights to the buckets of the WBS, which represent features and other organizations of stories. In the simple view in this article, we only get business value in our sample WBS by either putting features in the code or by doing something that lets the business market or sell the product - there is no business value in other parts of the WBS.
I'm using relative weights on the WBS here - each WBS bucket is compared to its siblings - and the following WBS with weights is telling the following story:
- Our Product Leg is worth 3 times as much as our Business Leg, and our Team leg provides no business value;
- Adding features to the product supplies business value, but modifying or cleaning up code that already works does not;
- Improving the User Interface is the most important feature, worth 1.5 times as much as being able to Update Customer Info; and
- User Documentation is the most important business bucket, but is still not worth very much compared to any of the features.
It is up to the business, or customer, to assign the weights to the WBS legs and stories - this is not a technical matter. There is no guaranteed formula; there is only the requirement that the weights be additive. For example, is "Team Training" something with business value or not? I don't know, it's up to your project. Typically it doesn't provide value if paid for out of project funds, but might if paid for out of overhead (training) funds. Our WBS (with weights) could look something like Figure 2.