Product value and how it is measured

What Scrum counts as value

Scrum does not define value as a score, a business case or a stakeholder's opinion. It points at one thing you can put your hands on, and the Scrum Guide sets the bar for it in a single sentence: "In order to provide value, the Increment must be usable." Usable is a hard word. Something a user can pick up and do their work with is usable; something that compiles, demonstrates on a laptop and needs three more days of integration is not, however much effort went into it.

Two more properties come with the Increment and both are examined. Each Increment is additive to all prior Increments and thoroughly verified, so that everything created so far works together — an Increment is the product as it now stands rather than a parcel sitting beside last Sprint's parcel, which is why verification covers the whole thing and not just the new part. And an Increment is born the moment a Product Backlog item meets the Definition of Done, so several may appear inside one Sprint and none of them waits for the final afternoon.

There is no fourth property, and the missing one is the trap. Nothing in Scrum makes an Increment valuable by being approved: there is no acceptance step, no stakeholder sign-off at the Sprint Review, no gate at which value is conferred. What makes an Increment capable of delivering value is that it is usable and that every part of it meets the Definition of Done. Work that misses that standard cannot be released or even presented at the Sprint Review — it returns to the Product Backlog — and no amount of honest labelling at the Review buys it an exception, because an item marked pending test is exactly the thing stakeholders cannot give useful feedback on. Nor can the Product Owner accept it as Done to get the feedback: the Developers are required to conform to the Definition of Done, and her accountability is for what the product is worth rather than for suspending the standard that makes the word mean anything.

Everything an organisation instinctively measures instead describes the work rather than its result. Velocity, hours logged, items closed, percentage of plan delivered: every one of them can be raised without a single user being better off, which is precisely what happens when one becomes a target and performance reviews start quoting it. The measure that cannot be gamed is the Increment itself, because someone outside the team has to be able to use it. Ask what the product can now do that it could not do a fortnight ago, and re-scoring the backlog does not change the answer.

The uglier version of the same failure is a reporting one. A team that marks items done when the code merges and books the remaining test work as separate items for a later Sprint has not accelerated anything; it has produced an artefact that overstates its own state. The Increment is one of the three artefacts important decisions get based on, so a number that says ninety-five per cent when the product is not finished quietly corrupts every decision downstream — what to release, what to fund, what to promise a customer. Amending the Definition of Done to make the practice legitimate is worse still: quality does not decrease during a Sprint, and where the organisation carries a standard, no team may drop below it.

Who is accountable for value

The Product Owner is accountable for maximising the value of the product resulting from the work of the Scrum Team. That accountability sits with one person, not a committee and not a role split across a department, and the reason is that a decision about what is worth building next is only answerable if there is exactly one person to ask. A portfolio manager with a revenue-ranked spreadsheet, a market analyst's model, a founder's conviction — all of these are inputs the Product Owner is free to use, argue with or set aside. Holding the budget is not the same as holding the accountability.

The work behind that accountability may move; the accountability may not. A Product Owner covering three markets can hand the writing and ordering of one market's Product Backlog items to a business analyst, and Scrum explicitly permits it. When the ordering drifts away from the Product Goal six weeks later, the drift is still hers to notice and correct. This is why the Guide says accountability rather than responsibility: responsibility for a task can be delegated to anyone, accountability is the obligation to answer for the outcome, and the exam tests the gap by describing a delegation and asking who is on the hook. The answer never changes and it never splits between two people.

The mirror-image obligation runs from the organisation back to the Product Owner: for Product Owners to succeed the entire organisation must respect their decisions. That is stated as a requirement on the organisation, not a courtesy it may withdraw. A monthly governance board that invites the Product Owner without a vote and reorders the top ten items to match departmental commitments has not strengthened accountability, it has abolished it — the board cannot be accountable for the product's value because Scrum does not make it so, and the Product Owner cannot be, because she can no longer decide. Nothing forbids the board existing. Stakeholders influence the Product Backlog by convincing the Product Owner, and a body that asks hard questions and inspects the Increment is doing exactly that; only the overrule breaks the mechanism. Note where this leaves the Scrum Master, because the exam offers his rescue in three disguises. He does not take the ordering decision away from a budget holder, he does not go to the board and argue the Product Owner's ordering on her behalf, and he does not write a Sprint Goal for a Planning that has stalled. Each of those substitutes his judgement for the accountability he is meant to be making answerable; his work is on the arrangement, and coaching both parties through the conversation is the whole of it.

A second accountability sits alongside the first and gets swallowed by it constantly: the entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Neither absorbs the other. So a Developer who tells the Scrum Master that value is the Product Owner's problem and that he builds what he is given has misread his own accountability — Developers who can see that an item will not do what the Product Owner hopes are the cheapest source of that information anybody will ever have, and staying quiet is not neutrality. It does not follow that the Developers take over ordering the backlog. Sharing accountability for a valuable Increment moves what people say, not who decides.

When value is proposed, released and judged

Value enters the Sprint before any work does. The first topic of Sprint Planning is why this Sprint is valuable, and the Product Owner proposes how the product could increase its value and utility in the current Sprint; the whole Scrum Team then collaborates to define the Sprint Goal, and Planning may not end without it. Watch the division, because two plausible wrong answers live in it. Opening the top of the backlog and pulling items until capacity is used up produces a batch of work and no reason for the Sprint to exist. And a Product Owner who writes the Sprint Goal herself and presents it to the Developers for acceptance has skipped the collaboration that makes it something they can all commit to.

Value leaves the Sprint whenever it is ready to leave. The Guide is unusually blunt about this: "The Sprint Review should never be considered a gate to releasing value." An Increment may be delivered to stakeholders before the end of the Sprint, so a Done fix for a checkout bug that is costing sales daily goes out on day six, and a release manager who insists nothing ships before it has been shown at the Review on day ten is holding four days of value hostage to a ceremony. Releasing early removes nothing from the inspection either, because the sum of the Increments created in the Sprint is what is presented. Whether and when to release is a decision about the product's value, so it belongs with the Product Owner rather than with the Developers who made it releasable.

Value is judged at the Sprint Review, whose purpose is to inspect the outcome of the Sprint and determine future adaptations. Outcome is the operative word: it is the one event that turns the Increment outward, where the Scrum Team and key stakeholders look at what the product can now do and at what has changed in the environment around it. The near miss the exam keeps offering is the Sprint Retrospective, which inspects how the Scrum Team works — people, interactions, process, tools — and never asks what the product is worth. Review looks outward at the product, Retrospective looks inward at the team. The Daily Scrum is the third event offered here and the easiest to dismiss: fifteen minutes in which the Developers inspect progress toward the Sprint Goal and adapt tomorrow's plan, which is a question about the work in flight rather than about what the fortnight was worth.

The Review earns its place only in what follows. A Sprint can produce an Increment that is Done, usable and released, and still deliver nothing, because the assumption behind it turned out to be wrong — the largest customer changed data format while the team was building the importer. That Sprint is an empirical success and a value failure at the same time, and the two verdicts do not cancel. Meeting the forecast is output; nobody using the result is the outcome. What decides whether the fortnight was worth anything is that attendees now collaborate on what to do next and the Product Backlog is adjusted. The expensive instinct is to call it a failed Sprint and rework the feature so the effort is not wasted, which converts a cheap lesson into a costly one. Nor is this a cancellation: the Sprint Goal was achieved, cancellation is for a goal that has become obsolete, and Scrum has no notion of re-running a Sprint.

Aiming at value, and what a forecast can tell you

A product is a vehicle to deliver value, and the Product Goal describes the future state of that product the Scrum Team is heading for. It is held one at a time. The Guide gives a team exactly two ways out of a Product Goal — fulfil it, or abandon it — before the next one is taken on, and abandoning is a legitimate move that is often the valuable one. Carrying two long-term objectives at once is not, however it is dressed up: giving each its own section of the Product Backlog does not create focus, and alternating which one each Sprint Goal serves is the more sophisticated version of the same mistake, because Sprint Goals being singular says nothing about how many long-term objectives may compete for the same team.

The rest of the Product Backlog exists to define what will fulfil that goal, which is what makes a single goal load-bearing rather than tidy. Two goals means two competing accounts of what is worth doing next, and the ordering stops being answerable to either of them. Note also whose work this is — developing and explicitly communicating the Product Goal is part of the Product Owner's Product Backlog management, not something the Developers pick between.

Measuring progress toward that goal is welcome, and it is not the same as evidence. Scrum names burn-downs, burn-ups and cumulative flows as practices proven useful, so an option claiming a team using them is not doing Scrum is wrong — the framework wraps around existing practice rather than banning it. What it will not allow is treating the projection as the thing projected. The Guide states the constraint plainly: "Only what has already happened may be used for forward-looking decision making." A programme office that wants a trend line turned into an external commitment nine months out has crossed exactly that line, and more Sprints feeding the line make it steadier without making the unknown knowable.

The overcorrection is worth naming, because an option offering it usually appears once the velocity target has been discredited: stop estimating altogether, since Scrum does not require velocity. Scrum prescribes no estimation technique and never names story points, but it does say that the Developers who will be doing the work are responsible for the sizing, so abandoning sizing throws away something the framework does expect and leaves refinement with nothing to say about whether an item fits in a Sprint. The defect in a velocity target was never that the number existed. It was that the number became a goal, and the goal was pointed at the work rather than at what the work was for.