What makes an increment of delivered work 'potentially releasable'?
answer
- A claim about state, not intent
- Could ship; shipping is a separate call
- Coded is not the same as integrated
- One completion standard, no per-item exceptions
basics
~20 sPotentially releasable means the increment is finished to the team's shared completion standard and could ship as it stands, with no hidden integration, testing or change-review work left. Whether the business chooses to release it is a separate decision.
solid answer
~50 s**Potentially releasable** describes the state of the work, not a promise to ship it. The increment — everything finished in this window plus everything finished before — is complete to the team's shared completion standard, so releasing it would take a business decision and no further engineering. That standard has to mean the same thing for every item, or the increment is a bundle of private definitions. The hard part is the gap between *coded* and *integrated*: work sitting on a separate line of development, never built or tested alongside the rest of the window's changes, is not in the increment however finished its author feels. A useful tell is a stabilisation period before shipping — if one was needed, the earlier increments were never releasable. Whether the business actually releases is its own call about timing or packaging.
go deeper
Be ready to define the term in one sentence and say who makes the release call. Knowing that 'potentially' points at a business decision rather than at unfinished engineering is most of the answer at this level.
Explain what is still outstanding when someone says work is coded: combining it with the shared line of development, a build and test run alongside the window's other changes, and a second reader. Name the shared completion standard as the thing that makes the claim checkable.
An interviewer expects you to spot undone work in a team's reporting — unmerged lines, a stabilisation period before every release, demonstration-only builds — and to describe how you moved a team back to integrating inside the window without stopping delivery.
Own the argument for why the completion standard is not negotiable item by item, and be honest about the tradeoff when a stakeholder wants the exception. Be able to say what an organisation loses when 'finished' quietly means something different in each team.
## What the claim actually is An **increment of delivered work** is everything the team has finished, taken together with everything finished before it. Calling that increment **potentially releasable** is a claim about its *state*, not about anyone's *intention*. It says: if the business decided this morning to put this in front of users, nothing on the engineering side would stand in the way. The word *potentially* carries the whole distinction. The team guarantees the work **could** ship; whether it **does** ship is a business call about timing, packaging, marketing or regulation that the team does not make. The claim is only meaningful if "finished" means the same thing to everyone on the team. A shared completion standard — written down, applied identically to every item, with no per-item exceptions — is what turns one engineer's private "I'm done" into an inspectable fact. Without it, "done" means "done as far as I was personally involved", and an eleven-person team's increment is a bundle of eleven different definitions. ## Coded is not integrated The gap most candidates are really being probed on is the one between *written* and *delivered*. Work that is coded but not integrated is not part of the increment, because nothing has yet shown it can coexist with everyone else's work from the same window. What is typically still outstanding when someone says "it's coded": - it sits on a separate line of development and has never been combined with the shared one - it has never been built and tested alongside the other changes made in the same window - it depends on a change that landed after this work diverged from the shared line, and the two have never met - it runs behind a switch that nobody has exercised on production-like data - it has passed its author's own checks, but no second reader and no shared test run - its data migration is written and has never been run against realistic volumes | Claim at the window's close | What is still unknown | Part of the increment? | | --- | --- | --- | | "The code is written" | whether it combines, builds and passes with everyone else's work | No | | "It combined cleanly" | whether the combined build and test run actually passed | No | | "It works in my environment" | behaviour on production-like data and configuration | No | | "It is behind an unfinished switch" | the untested side of the switch | Only if the switched-off behaviour is what ships | | "It meets the completion standard, on the shared line" | nothing technical; only the release decision remains | Yes | ## Why the distinction is worth defending Take an eleven-person team building a beekeeping-records product. At the close of a window they report 9 of 11 planned items finished, and 4 of those live on unmerged lines of development because "it's only the combine left". Two windows later, bringing those four together takes three days and reopens six defects that nobody could have seen in isolation. Nobody lied, and the report was still wrong: what the team held was not an increment but a queue of unintegrated work carrying an unmeasured amount of risk. Undone work behaves like a debt with no interest schedule — you discover what it cost at the moment you try to ship, which is the worst possible moment to discover it. Keeping the increment genuinely releasable buys four things: 1. **Release becomes a decision, not a project.** Someone can say "ship it" at any window boundary and the answer is yes. 2. **Risk surfaces while it is cheap.** Integration problems are found in the window that created them, by the people who created them. 3. **Progress reports mean something.** Counting finished items only informs anyone when every counted item is finished in the same sense. 4. **Feedback is about something real.** Stakeholders react to software that runs, not to a description of software. ## How the claim goes soft - **"Done except…"** A standard with exceptions is not a standard, and the exceptions are exactly where the work hides. - **A stabilisation period before shipping.** If the increment needed one, it was never releasable when it was declared finished; the period is the repayment. - **Demo-only work.** Something assembled to survive a scripted walkthrough on a demonstration environment proves the walkthrough, not the software. - **Deferred integration.** Postponing the combine to the end of a larger window converts many small, diagnosable problems into one large, undiagnosable one. - **Counting partly finished items as partly delivered.** An increment is not a percentage; a half-integrated item contributes nothing releasable. ## What an interviewer is listening for A junior answer defines the term and knows who makes the release call. A stronger answer reaches for the integration gap unprompted and can list what is left over when someone says "it's coded". The strongest answers treat *potentially releasable* as a discipline the team enforces on itself rather than a label applied afterwards, and can explain why the team, not the stakeholder, has to be the one holding that line.
- At the close of a window, where does work that is coded but not integrated actually sit?Outside the increment, in a queue of its own. It is finished from its author's point of view and unproven from the team's: it has never been built or tested alongside the other changes made in the same window, so the cost of finishing it is unknown. Treat it as work in progress that has been reported as complete, and it will distort both the increment and every forecast built on it.
- If the business never actually releases the increment, was insisting it be releasable still worth it?Yes, because the guarantee is what makes the option real. The value is that release stays a decision anyone can take at any window boundary, rather than a project that has to be scheduled. It also forces integration and testing to happen while the work is fresh, which is the cheapest moment. An increment that is never shipped but could have been still tells you the truth about what is finished.
- How would you handle an item that is genuinely half finished when the window closes?It contributes nothing to the increment and should be reported that way — no partial credit. Leave the work where it is, carry the item, and resist recording a percentage, because a percentage of an unintegrated item is a guess. If half-finished items are normal rather than occasional, the real problem is that too much was started at once, not that the reporting is too strict.
It is the difference between a meal plated and sitting on the pass and one still spread across three pans — both are cooked, but only one can be served without further work.
saying these in an interview costs you the question
- Says potentially releasable means the team has promised to release it
- Counts code on an unmerged line of development as delivered
- Treats integration and testing as a later, separate phase
- Accepts 'done except for the tests' as finished
- Believes a successful demonstration proves the work is releasable