This short book explores how agile teams decide what to build. Schwartz interrogates a few well-established prioritization techniques, including scrum’s product owner approach (where one person represents “the business” and has final say on what user stories have value); more formulaic metrics such as ROI, NPV, and MVA; and fuzzier measures like customer value, user value, and ultimately business value. Drawing on his experience as a CIO in both the private sector and large government agencies, Schwartz ends up making a compelling argument that business value is something the development team should develop on its own with input from the product owner, and that to do so, strong business metrics must be put in place early in the project lifecycle and collected as quickly as possible. A key component of this is a continuous delivery pipeline that exists both to codify the team’s understanding of business value at a given point in time and to allow for quick feedback loops in evaluating the impact of changes made.

The conclusion isn’t revolutionary, but the evidence he ties together to make his case (including a lengthy exploration of bureacratic rule making and compliance activities) would resonate with my non- and semi-technical colleagues working in a large government bureaucracy. Business value as a formulation is non-specific enough to allow for value that is not directly tied to financial performance (such as the value derived by an organization from learning, transparency, and human capital development) while also being specifically not a purely technical measure.