7.1 The Business Case Practice in an Agile Context

7.1 The Business Case Practice in an Agile Context

Quick summary: The business case practice exists to judge whether the project is desirable, viable and achievable — at the start and continuously. Its agile expression is progressive benefit realization: releases produce measured evidence, the MVP tests the riskiest assumption cheaply, and the benefits management approach is tailored to the frequency of planned releases.

Purpose and the three tests

The purpose of the business case practice is to support decision making by establishing mechanisms to judge whether the project is — and remains — desirable, viable and achievable, and therefore worth the continuing investment.

These are re-tested at every stage boundary, which is what gives the ensure continued business justification principle something concrete to do.

Artifacts

• The business case itself: the reasons, the options considered, the expected benefits and dis-benefits, timescale, costs, investment appraisal, major risks and the sustainability assessment.
• The benefits management approach: how and when benefits will be measured, by whom, and how measurement continues after the project closes. Many benefits appear only months into operation, so this artifact typically outlives the project.
• Supporting agile artifacts: the project canvas (which can carry a small project's justification on a single page), the release map (which shows when each benefit starts to accrue), and the project dashboard (which reports benefit forecasts alongside progress).

Tailoring the artifact, not the purpose. A small project may hold its business case within the project canvas. What is never tailored away is the requirement that the project be justified and that the justification be re-tested.

Tailoring the benefits management approach

The examinable tailoring point: in an agile context, the benefits management approach should be tailored by emphasizing the frequency of planned releases.

The reasoning is direct. In a plan-driven project, benefits begin after a single hand-over, so benefit reviews are scheduled from that one date. In agile delivery, each release can start realizing benefits, so the measurement regime has to follow the release cadence: what does release one enable, when will we measure it, and what does that tell us about the forecast for releases two and three?

Note what the tailoring is not. Defining the MVP is a technique within the practice, not a tailoring of the benefits management approach. Describing how agile will be used belongs in the project's approach documentation. Detailing the impact on operations and maintenance belongs to the transition into operations.

Agile techniques in the business case practice

The minimum viable product

The MVP is the business case practice's sharpest instrument. It is a version of the product with just enough features to generate the feedback needed to learn whether an assumption holds.

Its governance value is that it converts a forecast into evidence at a fraction of full cost. Instead of asking the board to approve eighteen months of spend on a projection, you ask for three months to test the projection's riskiest assumption. If the evidence contradicts the business case, the project is stopped having spent a sixth of the budget — and stopping a project for good reason is a success under the continued business justification principle.

Progressive benefit realization

Because increments are usable, benefits do not have to wait for project closure. A release that automates one high-volume process starts saving effort immediately, while later releases are still being built. The consequences for governance are significant: the payback period shortens, the benefit forecast can be corrected using real data, and the board's stage boundary decision is informed by outcomes rather than by activity.

Prioritizing against benefit

MoSCoW prioritization is only honest if the ordering reflects benefit. The product owner's ordering of the backlog is, in effect, a continuous restatement of the business case: what is at the top is what most advances the benefits. This is why the product owner needs to understand the business case even though the executive owns it.

Value assessment and personas

Personas identify the specific benefits a solution can deliver to each user group, which turns a vague benefit ("improved efficiency") into something measurable for a named group.

Sustainability in the business case

Since PRINCE2 7, sustainability is one of the seven performance targets and is assessed within the business case. The business case therefore considers environmental, social and economic impact — energy and materials consumption, accessibility and social outcomes, and the long-run maintainability of the product — alongside financial return. Sustainability can carry its own targets and tolerances.

Who owns what

The line that matters: the product owner does not own the business case. Ordering a backlog to maximize value is not the same as being accountable for the investment. Conflating the two is a common exam trap and a common real-world failure, because it leaves nobody accountable for stopping a project that has ceased to be justified.