Agree the first release

Define a complete user task

A first release should let an agreed user complete a useful task. The task may be requesting a service, using a portal or moving information between two systems. Its boundaries should be clear enough to demonstrate without relying on unbuilt features.

1. Name the user and the task they will complete.
2. List the systems, access and data needed for that task.
3. Agree how the team will check the result and who will accept it.

• A working design review and a production release are different milestones.
• Provider approvals and migration work need their own owners and checks.

Plan the operating handover

Include the people who will support the release. Agree what happens when a step fails, how a team member finds the responsible owner and what information belongs in the handover. Training and support coverage should match the agreed engagement.

• Acceptance examples for normal and failed cases.
• A release and recovery plan proportionate to the change.
• Responsibilities for documentation, access and ongoing work.

When the scope changes

Record the new requirement and its effect before adding it to the release. A clear change decision protects the original acceptance criteria and gives the team a reliable plan to review.

• The requested change and the business reason.
• Its effect on dependencies or acceptance.
• The person approving the revised scope.