Delivery
Architecture
This is the planning phase. Discovery said what and why. Architecture says how, in what order, and with which risks accepted. Nothing that customers will depend on is coded until this baseline is approved.
In brief, then in detail
- The system shape. Boundaries, major components, data stores, and the integrations that carry the business. Drawn so a CTO can challenge it.
- Security and operability. Identity, sensitive data, logging, backups, and who can reach production. Designed now, because retrofitting them is how dates slip.
- A backlog the team can start. Features sliced so the first sprints produce something a user recognises. Size is honest. Order follows value and dependency.
- A roadmap with room. The first release, the following releases, and the decisions that are allowed to wait. A roadmap is a forecast, not a vow.
How it is run
Planning produces baselines: design, initial scope, and a view of schedule and cost. The sponsor approves them. From that point, Scrum can run without relitigating the foundation every Monday. When new learning breaks a baseline, the change is visible. The phase is usually one to three weeks, longer only when the estate or the regulation demands it.
GateApproved before the build
DurationUsually 1–3 weeks
HandoffA backlog and a roadmap
Planning outputs
- Context and design
- Security notes
- Ordered backlog
- Sprint roadmap
- Cost view
- Accepted risks
Terms, in plain language
- Planning. The work that turns a charter into a design, a backlog, a forecast, and a set of risks the sponsor has seen.
- Sprint roadmap. The intended sequence of sprint goals. It guides, and it is updated when the review teaches something.
- Dependency. Work that cannot finish until something else exists: a decision, an API, a vendor, or another team.
- Forecast. A dated view based on what is known. It is updated. Pretending it was a promise is how trust is lost.