Finish one useful job in the first release
Define a useful first release through one complete job, an explicit completion point and a reason for leaving some features until later.
You are planning a service website. The wish list includes pages, a customer account, a quotation tool and online payment. Each item may have a purpose. Before deciding which ones belong in the first release, there is a more useful starting question: what should someone be able to finish?
Our suggested starting point is one complete job and a clear completion point. That gives each proposed feature something to contribute to. It also makes room to discuss which parts of the job will be handled by software and which will remain with a person.
Give the release a job
Consider a fictional office cleaning business. The first job is to let a visitor request a suitable service and let the team review that request and reply with the next step.
The visitor chooses a service, provides contact details and explains what they need. The team receives the request, can find the information required for review and has an agreed way to respond. A person may ask for clarification or arrange the next conversation before agreeing a quotation.
For this proposed release, the completion point is that the team has reviewed the request and sent the next step to the customer. The request is not automatically a confirmed cleaning appointment. That distinction helps define the wording, the information required and the work the team must be able to do.
Trace the essential steps
Working backwards from that completion point, the release needs a place where the team can find and review incoming requests. It needs a response route and a person responsible for using it. On the visitor's side, it needs a clear service choice and enough information to make the request understandable.
Those elements might use a mixture of new work and existing tools. In this fictional scope, an agreed existing mailbox could provide the response route. The team would still need to establish how a request reaches the right place and how someone knows it needs attention.
The point of this exercise is to choose the work that belongs in the release. A feature belongs when it supports a necessary step or condition of the chosen job. If an essential step is missing, the release boundary needs to include a way to complete it.
Name what can wait
In this example, customer accounts, automatic quotations and online payment can wait if the chosen job works without them. A visitor can request a service without having a permanent account. A person can review the details before quoting. Payment can be considered when the business defines a later job that requires it.
Each deferred item should have a reason. “Customer account: revisit when customers need to manage recurring requests” is more useful than “customer account: later”. It records the situation in which the feature would deserve another look.
An item should not be deferred merely because it is difficult to build. First ask whether leaving it out prevents the chosen job from reaching its completion point. That is a scope question to resolve before treating the release as small enough.
Include the human work
If a person reviews each request, that is part of the proposed operating model. The release note should name the role, the information they receive and the next action they take. Otherwise, an apparently finished form may end at an inbox nobody is expected to use.
A human step can also be revisited later. The initial choice gives the team a defined way to work; a future change needs its own reason and scope. There is no need to decide every future version while defining the first one.
Write a short release note
The Website & App Build offer at WGMI includes an agreed first release, testing and a documented handover. The boundary is agreed around the actual task. A short release note can start that conversation with four parts.
The job: What should the visitor and the team be able to complete?
The completion point: What has happened when this job is finished?
The essential steps: Which screens, information, tools and human actions make that possible?
What can wait: Which additions are outside this release, and what would make them worth revisiting?
Write these four parts for one job before adding another feature to your first release.
Prepared for WGMI with AI assistance.