We can argue that a Scrum Team exists to create value. Scrum has historically called this value ROI. However, the term ROI evokes an image of capitalized machinery that is atypical of software and other intellectually intensive businesses. Most Scrum products do not depend on intensive financial capitalization but tend to draw most of their value from “intellectual capital,ˮ and Jeff Sutherland has even said that he created Scrum to help people make something from nothing. In any case, there are other measures of financial value such as net present value (NPV), cash flow, and many more. Scrum applies to products seeking to optimize any and all of these.
Yet not all worthy businesses are in this for the money. Scrum is making ever deeper inroads into public service and government software, where the goal is to responsively develop public services. There, we might measure value in terms of citizen satisfaction with public services, or lives saved by first responders. So the term ROI appears nowhere in The Scrum Guide, but the term value recurs frequently. The Product Owner is accountable for optimizing value, yet value can founder if either Development Team members or the ScrumMaster are delinquent in their tasks.
As every Scrum Team serves several sets of stakeholders, each team should be attentive to multiple facets of value. We value that our team members have ample, quality vacation time, which is the main reason behind Vacation PBI. We value that the team has a challenging, humane, and reasonably stress-free environment, and the ScrumMaster has the mandate to sustain a healthy culture. We value that our end users have defect-free products, so we fix defects now with Whack the Mole. And we may value excellence, and improvement for its own sake, so we relentlessly focus on improving both the product and process (see Kaizen and Kaikaku).
Even on the economic front, the value question becomes more interesting in subcontracted product development. If a subcontractor develops a product for a corporate client, at a modest fixed cost, and the client makes a record profit from the product, it in some sense sets up an unfair economy. (The vendor may think twice before developing another product for the same client.) An equitable sharing of value is part of any sound Development Partnership. The same principle extends more broadly to all stakeholders that contribute to product development.
In the old days of system development, we found a role called system engineer whose job it was to optimize value. System engineers worked with three theories of value; an economic theory, a psychological theory, and a casuistic theory ([1]). The economic theory of value harkens back to where we started with ROI, NPV, and cash flow. The psychological theory of value relates to the mental health and contentment, and maybe even passion, of the team. And the casuistic theory of value relates to tradition and to “doing the right thing.ˮ In its most vulgar form, it may manifest itself as the Scrum Values; we find a more finessed version in The Spirit of the Game. Systems engineers previously used parameterized mathematical models to optimize value equations by adjusting coefficients for each of several kinds of value. While we are not recommending such a reductionist approach, to informally consider the tradeoffs and to discuss them as a team will likely both leave the team with a greater legacy, and better leave it with a feeling of a job well done at the end of the day.
Value should be more than just a matter of locally optimizing the profitability of each Product Backlog Item (PBI) in isolation. Re-ordering PBIs to hit the best market windows can increase the profitability of every item in the Product Backlog Item. The team might optimize different PBIs for different theories of value. Value emerges over time as a property of the entire backlog and its ordering (e.g., consider cost of delay as one exemplary consideration). The Vision plays a crucial role both in assessing value and adjusting work to increase value—and the team may adjust the Vision itself to recharter the team on a trajectory to higher value.
So when a Scrum Team aspires to create the Greatest Value, each team should consider what is really important to their end users but also to themselves, their colleagues, their loved ones, and their fellow world citizens all together. Scrum can help you optimize any theory of value.
The next pattern, ROI-Ordered Backlog, is explicitly about value. Most of the rest of the Product Backlog patterns also deal principally with value. Product Owners often annotate each Product Backlog Item with some measure of incremental value. While we usually think of this annotation as representing profitability, consider using another measure—such as the corporate image in the community—as a refreshing alternative. You may ultimately evolve to using two or three informal indicators of value to help guide Product Backlog ordering.
[1] Arthur David Hall III. A Methodology for Systems Engineering. New York: Van Nostrand Reinhold, 1962.