Deliver the system

A process model becomes useful when a team can turn it into a working change. Delivery connects the proposed design to manageable work, explicit acceptance criteria, and feedback from the people who will use the result.

The toolkit's Scrum component supports this coordination. It can help structure a backlog, prepare a planning discussion, surface dependencies, and maintain a delivery record. The people doing the work remain responsible for priorities, commitments, and review.

Resolution before implementation

Delivery starts from the signed-off design, which states what each AI-supported step needs. Before anyone writes a new prompt or skill, the team checks what the domain library already offers. A reviewed binding is reused unchanged. An installed skill with a fitting method is wrapped in an adapter that keeps its own evidence records. Only a need that nothing fits gets a new method, and its legal rules must come from research, a playbook or the process owner, not from a model's memory.

The toolkit records each decision in a capability resolution record: the need, the candidates considered, the choice, and what still needs review. That record feeds the backlog. Each wrapped or new capability becomes work with acceptance criteria, and a release cannot proceed while any need is still pending.

Choose an outcome before a feature list

“Build a legal AI assistant” is too broad to guide a short delivery cycle. “Allow the pilot team to submit a complete research request and receive a reviewable scope record” gives the team something concrete to demonstrate.

Work backward from that outcome. Identify the inputs, the success path, the exception paths, the review needs, and the minimum integration. Decide what can be delivered without leaving an unusable fragment.

View the relationship model

flowchart TB
    O["Outcome<br/>A reviewable research scope"] --> S["Story<br/>Capture question, jurisdiction, and dates"]
    S --> A["Acceptance criteria<br/>Required facts and explicit unknowns"]
    A --> T["Implementation and tests<br/>Valid, incomplete, and changed inputs"]
    T --> I["Usable increment<br/>Demonstrate with representative cases"]
    I --> F["Feedback<br/>Revise the backlog"]

Keep dependencies visible

A research task may depend on an approved method, source access, a stable output schema, and a reviewer. Coding the prompt before resolving these dependencies can produce a convincing demonstration that cannot operate in the real setting.

For each delivery item, record the dependency and its owner. Distinguish something that is unavailable from something that is merely unfinished. A missing connector permission is not a language-model reasoning problem.

Review the result, not just the task list

A useful review follows a representative request through the service. Include an incomplete request, an unavailable source, and a rejected output alongside the normal case. Ask whether the user understands the status and can take the next action.

Acceptance evidence should be inspectable: the tested input, the observed result, the relevant version, and any limitation. A screenshot can show a page rendered; it cannot establish that the correct branch was persisted after a restart.

Improve how the team works

Retrospectives examine coordination, quality, and the development process. If AI makes implementation faster but reviewers become overloaded, producing more code may make delivery worse. Limit simultaneous work and make review capacity part of the plan.

Small, coherent changes are easier to understand, review, and reverse. Maintain short decision records and update diagrams when boundaries change. Good handover documentation explains the behavior and its rationale, rather than recounting every development conversation.