Delivery Stage

What question does this solve?

When work is tracked only as a broad set of activities, it is hard to tell which conditions allow it to move on. An implementation can start from an ambiguous rule while a later evaluation uses a different understanding from the one adopted during execution. And when several resources take part, an output has to make sense to whoever evaluates or uses it, not only to whoever produced it.

Definition and role

A Delivery Stage is a unit of transformation: it uses available inputs to produce outputs that can be evaluated, with an explicit purpose in the route of a demand. When it ends, it should be possible to recognize what was produced and whether it meets the established conditions.

Clarifying a business rule, developing an alternative solution, implementing a behaviour and checking an integration are possible stages. They are not a mandatory sequence, and not every implementation needs them as separate stages.

A stage is bounded by the transformation and by the usefulness of evaluating its output. Its duration, the number of people involved and the tool used do not define that boundary. A meeting can be a clarification activity, but holding it does not show that the rule was clarified. Running a code-generation tool can be part of a stage without being, on its own, a transformation complete enough for the next decision.

The Delivery Unit represents the demand being tracked; a Delivery Stage represents a transformation within its route. The same unit can go through several stages, and finishing one can leave work needed to meet the full commitment. The Stage Contract specifies the conditions of the transformation. The stage is the bounded work; the contract states the conditions under which that work can be carried out and evaluated.

Why it matters for the hypothesis

If interpreting, experimenting and evaluating become cheaper, smaller transformations may produce useful information at a cost that did not previously pay off. The stage marks where such an advance can be recognized. It does not create the economic gain, and it must not add a layer of coordination that consumes it.

How it works

Inputs sufficient for the purpose

Inputs can include information about the intention, business rules, constraints, existing artifacts, access and earlier decisions. Whether they are sufficient depends on the transformation. A clarification stage can start from an incomplete intention, because producing understanding is its purpose. An implementation stage may need decisions that clarification has not produced yet. The same missing information can be acceptable in one case and blocking in the other.

When a gap is recognized, someone has to decide whether the work waits, seeks clarification, or proceeds under an explicit and authorized assumption. The assumption does not become a confirmed requirement just because execution started. Inputs can also change during the work, so it must be possible to identify which understanding supported the output produced and whether it is still adequate.

Outputs, evidence and acceptance

Artifacts are products of the work, such as a description of rules, a prototype, a code change or a set of tests. The stage should state which outputs are expected and what they will be used for. Evidence is the information that supports a judgment about those outputs. The Quality Gate decides on technical or quality acceptance against the established conditions.

Producing an output, evaluating it and accepting it are related events with different meanings. Acceptance can rest on human judgment or on authorized automated checks. An accepted output shows that the stage’s conditions were met within the scope of the evaluation. It does not guarantee there are no unknown problems, and it does not automatically authorize deployment to production.

Bounding in proportion to the work

For a small presentation fix, implementation and verification can be handled in one stage, provided the acceptance conditions are explicit. For an integration with external dependencies, separating analysis, implementation and validation can allow different decisions and surface relevant obstacles. A split is useful when the output supports its own evaluation or decision, when dependencies must be checked before continuing, or when the commitment needs an explicit boundary. A specialized activity alone does not call for a separate stage.

The model sets no universal size. Granularity has to weigh risk, uncertainty, coordination cost and the usefulness of intermediate outputs. An exploration can go only as deep as needed to compare a simple solution with a more complex one and to form conditions for the next advance. Deferring clarification that is not needed yet can save work; omitting clarification that is needed only moves cost and risk elsewhere.

Execution under explicit conditions

The Execution Policy governs the eligibility, selection, autonomy and supervision of the Execution Resources used in the stage, and the expected result remains the reference for judging the transformation. A professional can clarify a rule with the person asking. An agent can produce an alternative from the context provided. A hybrid composition can combine automated production and human evaluation. Choosing automated execution does not lower the quality bar by definition, nor must every procedure be identical to a human one.

A stage can contain an adaptive cycle: interpret the inputs, propose an output, examine it, correct it and evaluate again. The policy can authorize people or systems to run that cycle and to decide when it is complete, based on the relevant evidence. The stage boundary identifies a useful transformation. It does not impose a meeting, a human intervention or a new charge.

Returns, parallelism and repeated execution

Stages do not assume a single linear pass. Correcting an implementation to meet the current rule can stay within the same stage. Revising the rule itself may require returning to clarification. A change in commitment may need authorization before work resumes. Stages can also run in parallel when their inputs and dependencies allow, as long as outputs used together remain consistent. Flow coordination keeps track of which execution produced each output and which decisions allowed the work to move forward, return or stop.

In the running example

At the barbershop, a clarification stage receives the intention and the available information about services and the calendar. Its purpose is to produce rules and technical questions sufficient to design an alternative and discuss the conditions for continuing.

Execution can combine a conversation with the customer, analysis of the existing system and assisted or autonomous exploration. An agent can spot conflicts in duration, look up authorized information and test an interpretation. If it has authority to choose between alternatives consistent with the policies it received, it can settle the question; otherwise it routes the decision to whoever can make it.

The output includes the rules in force, the dependencies and the limits of what was clarified. Accepting it does not authorize implementation. It can complete an intermediate delivery that was purchased and feed the next offer. Prototype and technical analysis can proceed in parallel and reveal that a rule must be revised; returning to clarification keeps the link between the new decision and the outputs it affects. See intent to production for the stages of the full case.

Boundaries and failure modes

A stage is not an economic commitment. Finishing a stage can inform Progressive Estimation: a constraint may increase the forecast work; a discarded alternative may reduce the scope under consideration. Progressive Commitment relates that understanding to the work authorized. An accepted analysis can support an implementation offer without authorizing it. A Commercial Gate can sit at a stage boundary, but the model does not require a commercial decision or a charge at the end of every stage, and one commitment can cover several transformations. Creating more stages does not create more commercially independent deliveries.

Formal progress without substance. Bounding stages does not remove uncertainty or ensure quality. Vague contracts, weak evaluation or out-of-date inputs can let work progress formally without adequate support.

Approval at every step. Turning each small activity into an approval boundary increases waiting and fragments the understanding of the demand. Each stage should produce a useful output, and the decision attached to it should justify the cost of keeping it separate. The right granularity by context, and when a specification can be reused across demands, remain open questions.

Connected concepts

• Structures overview
• Previous: Delivery Unit, the demand a stage transforms
• Next: Stage Contract, the conditions of the transformation
• Artifacts and Evidence, what a stage produces and what supports judging it
• Reference pipeline, the five stages of the barbershop case
• Glossary