Plan a software project by defining the user outcome, the boundaries of the work and the evidence needed for acceptance. Record dependencies with owners before attaching dates to them. Keep estimates, decisions and completed checks separate, so the plan remains useful when a requirement changes or an external dependency is delayed.
What outcome should the plan describe?
Begin with a result the intended user can recognise. For a hypothetical repairs application, a useful outcome might be that a coordinator can assign a reported fault and identify who must act next. Write down which part of that journey is being commissioned before listing pages or technologies.
The GOV.UK discovery guide asks teams to understand the problem before committing to a service build. Discovery guidance recommends a clear goal to help establish scope and completion. The GOV.UK discovery guidance offers a practical method for establishing that starting point.
Ask what evidence would show that the outcome is worth pursuing. Existing records, interviews with intended users or an observed current process may help, depending on the question. Record where each conclusion came from. A requirement copied from a competitor’s feature list still needs a reason connected to your own workflow.
The guide recommends agreeing what is outside the problem being investigated. For the repairs example, an initial release might include reporting and assignment while excluding purchasing replacement equipment. Explain the handover where purchasing becomes relevant, so that an exclusion does not leave the coordinator without a workable next step.
Which dependencies need owners?
Draw a dependency as a decision or deliverable that another activity actually needs. “Waiting for client” is too broad. “The service owner must choose who can reassign an open fault” tells the team what remains unresolved and who can resolve it.
The discovery guidance includes learning from operational colleagues. Ask the people expected to operate the application how incomplete information, unavailable staff and corrections are handled. Include those decisions in the planning record when they affect the commissioned outcome.
Use a dependency register with the required input, its owner, the work it blocks and the next check. Request evidence of completion appropriate to that input: a confirmed rule, an approved content set or documented access to an authorised test service. Do not mark a dependency complete because someone has started a conversation about it.
Separate internal work from external waiting. If an integration requires an account decision, identify who owns that decision and what the team can investigate safely in the meantime. Avoid forecasting a provider’s approval date or promising eligibility that has not been established.
How should estimates be used?
Ask what the estimate assumes. The answer should identify the intended scope, available people, known dependencies and quality work included. Record exclusions such as an unresolved data migration separately, rather than leaving them implied by an optimistic schedule.
The Scrum Guide says the whole Scrum Team collaborates on the plan created in Sprint Planning. Sprint Planning considers why the Sprint is valuable. These statements in the Scrum Guide connect planning with collaboration and a valuable goal. They do not prescribe the commercial terms of a project.
Sprint Planning includes deciding what can be done during the Sprint. The Scrum Guide links confidence in Sprint forecasts with past performance, upcoming capacity and the Definition of Done. If the team uses Scrum, keep that forecast tied to the actual Sprint discussion. Do not translate an example cadence or a team’s local forecast into a guaranteed whole-project completion date.
For the hypothetical repairs app, ask whether the proposed first increment includes only an assignment screen or a complete assignment outcome with agreed permissions and exceptions. Two estimates cannot be compared meaningfully when one includes that work and the other silently omits it.
What belongs in acceptance evidence?
Define acceptance through task outcomes and the evidence required to assess them. For the repairs example, propose synthetic fault records with an ordinary assignment, an unavailable assignee and an attempted reassignment. The service owner should decide the intended result of each before implementation is assessed.
Developers are accountable for creating the Sprint plan and adhering to a Definition of Done. Use the agreed quality boundary to explain which work must accompany a candidate increment. Business acceptance and engineering checks should be traceable to the relevant requirement rather than hidden behind an unexplained percentage complete.
The following original acceptance chain ties a scope decision to a verifiable handover. Complete one row per meaningful outcome and retain links to the actual evidence as it becomes available.
| Outcome | Dependency or rule | Proposed evidence | Decision owner |
|---|---|---|---|
| Report a fault | Required information agreed | Synthetic complete and incomplete reports | Service owner |
| Assign responsibility | Who may assign and receive work | Controlled role-based task attempts | Operations owner |
| Handle unavailable assignee | Agreed alternative route | Observed exception behaviour | Service owner |
| Correct an assignment | Reassignment policy | Before-and-after synthetic record | Operations owner |
| Release the candidate | Environment and release boundary established | Versioned checks and a separately agreed recovery plan | Release owner |
The owner names are suggested responsibilities to allocate. Confirm the actual people and authority for the project. A blank evidence cell should stay blank until the relevant check has occurred; a proposed test description is useful preparation but does not supply its result.
Ask the reviewer to explain the acceptance decision from the record. If they need the developer’s memory to identify which version was checked or which case failed, improve the evidence before closing the item.
How should scope changes be recorded?
Use a short change note: new evidence, affected outcome, work added or removed, dependency changes and the decision made. For the fictional repairs project, a request to attach photographs should explain whose task requires them and which handling requirements follow.
The Scrum Guide says the Sprint Backlog is updated as the team learns during the Sprint. An adaptive working plan can make new knowledge visible while preserving the history of decisions. Keep the original assumption and the reason for changing it, especially where a change affects a previously communicated commitment.
Do not hide a new workstream inside an existing label. If a proposed reporting feature introduces information from another system, identify the new dependency and how acceptance will cover it. That allows the sponsor to choose scope and sequence on an informed basis.
Close each planning review with the next decision, its owner and the evidence needed. A useful plan tells the team what can proceed, what remains uncertain and how completion will be assessed. It should make a difficult decision easier to see, rather than make all work appear equally certain.
For delivery process detail, use the separate Scrum delivery guide. Explore web development, or send Spout your requirements with the proposed outcome and its unresolved dependencies.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.