Releases, risks and stakeholders
🏠The everyday picture
Opening a new shop branch: the opening date is announced only when the fittings are in and the staff trained; there's a soft opening for friends first; and the owner keeps the landlord, staff and suppliers informed at every step.
📘What it really is
- Releases:
- separate deploying from releasing (Module 70): code goes to production behind feature flags; features are released to users when ready;
- release plan: what's in it, the date range, the readiness checklist (Module 96), communication to users and support, a rollback plan;
- staged rollouts: internal users, then a pilot group, then everyone (Module 90);
- release notes in plain language for users; a changelog for the team;
-
versioning for APIs and apps (semantic versioning: MAJOR.MINOR.PATCH) when others depend on them.
-
Risk management (Module 73's method, applied to projects):
- a project risk register: risks to delivery (payment gateway approval takes weeks; a key developer leaves; a tutor onboarding is slower than expected), with likelihood, impact, owner and response;
- tackle the riskiest work early (spikes, MVP tests);
-
review risks in each sprint review.
-
Stakeholders: everyone affected or able to affect the project (users, business owner, tutors, investors, support staff, partners).
- map them by interest and influence; keep the most influential closely involved;
- communicate regularly and honestly: short updates on progress, risks and decisions; bad news early;
-
manage scope: new requests go into the backlog and are prioritised; they don't silently grow the current sprint.
-
Working with AI and contractors: clear briefs, small deliverables, reviews and acceptance criteria (Builder Path), the same as any team member.
🖱️Try it
Write a release plan for the booking platform's MVP launch: scope, date range, readiness checklist, staged rollout, rollback plan, user communication and release notes. Create a project risk register with eight risks. Map stakeholders by interest and influence, and write a one-page status update as if sending it to the business owner after a sprint.
✅Quick check
Why separate deploying from releasing?
Show the answer
Code can be deployed safely and turned on for users when ready, gradually, and turned off if needed.
What should happen to a new feature request in the middle of a sprint?
Show the answer
It goes into the backlog to be prioritised, rather than silently expanding the current sprint.