When: planning, estimation, and prioritisation

You have identified the users, clarified what needs to happen, understood the value, mapped the technical journey, and chosen where it will live. Now: when, and at what cost, does this vision become reality?

The When is about orchestration. The thoughtful coordination of time, effort, budget, and value. It is where software planning meets project management and funding models. It is where delivery becomes predictable, visible, and measurable.

What you define here#

• Delivery timelines and phases
• Cost estimates and effort scoping
• Backlog structure and grooming strategy
• Value-based prioritisation methods
• Risk and impact assessments
• Triage and stakeholder alignment workflows

1. Connecting the Ws to planning#

Every W feeds the plan:

A good plan does not just answer when it will be done. It answers why this order, what is risky, and how confident we are.

2. Backlog and work item structure#

Break initiatives into epics, features, stories, tasks:

• Epic: Leave Management
  • Feature: Submit Leave Request
    • Story: UI for date selection
    • Story: Validation logic (frontend + backend)
    • Story: Approval service integration

Every item should include:

• Acceptance criteria
• Dependencies
• Technical notes linked back to the How
• Value and effort scoring for prioritisation

3. Prioritisation models#

• MoSCoW. Must have, should have, could have, won't have.
• RICE. Reach x Impact x Confidence / Effort.
• WSJF. Cost of Delay / Duration (weighted shortest job first).

A custom model tip: blend business value, operational urgency, and architectural foundations. Technical debt should be consciously prioritised, not ignored until it blows up.

4. Estimation#

Effort:

• T-shirt sizes, then story points, then hours or days
• Relative estimation in group settings (planning poker)

Cost combines:

• Engineering time (salary x estimate)
• Infrastructure (VMs, storage, cloud services)
• Third-party costs (licensing, APIs)

Example:

Feature: Approval System (2 developers, 1 designer, 3 weeks)
Infra: Redis + MySQL HA = ~£40/month
Dev cost: £15,000 (blended)
Total: ~£15,120 + ongoing ops

Always include a variance range (best, likely, worst) and revisit it as the work progresses.

5. Delivery planning and roadmaps#

Sprint or iteration based:

• Weekly or biweekly sprints
• Regular retros and demos for visibility

Milestone based:

• Key checkpoints (MVP, public beta, v1.0)
• Cross-functional dependencies (design, legal, data) tracked alongside engineering

Tooling we often see working well: Linear or Jira for backlog, Notion or Confluence for delivery docs, Gantt overlays for exec communication.

6. Triage and change management#

Not everything planned will happen in the right order. What helps:

• Weekly triage calls with delivery leads and product owners
• Red / Amber / Green boards to flag blockers
• A rolling four-week plan with flex zones
• Change control for cost, scope, or risk shifts

7. Budget and cost control#

• Runway targets per team (e.g. a monthly dev-spend cap)
• Cloud spend monitoring via billing APIs or dashboards
• Track cost to build vs cost to run so you do not get surprised
• Pre-calculate margin pressure for usage-based pricing

8. Why estimates drift (and how to recover)#

Estimates slip for predictable reasons. Naming them makes them easier to catch.

• Hidden dependencies. A story that looked self-contained in refinement turns out to need a schema change, which needs a migration, which needs a deploy window, which needs an approval from a team on holiday. Catch this in refinement by asking "what does this depend on that we do not own".
• Unscoped integrations. Connecting to a third party is never as quick as the third-party marketing page suggests. Add a deliberate spike for anything that crosses a company boundary.
• Testing debt. A feature is only done when it is tested. If test writing is treated as optional, your estimates have been lying to you.
• Rework from unclear acceptance criteria. If you are writing code before the acceptance criteria are nailed down, you are paying for that twice. Good What work is the cheapest time you will ever spend.
• Unplanned operational work. Incidents, security patches, dependency upgrades. If your sprint assumes zero overhead for these, you will consistently under-deliver.

Recovery is boring but effective. Re-estimate what is left when a story is half-done. Move the blocked items out of the sprint, not the deadline. Tell the stakeholder early. The cost of telling a stakeholder two weeks before a delivery that it is slipping is a fraction of the cost of surprising them on the day.

9. Cadence matters more than speed#

The teams that ship consistently are rarely the fastest teams on paper. They are the ones with a rhythm the business trusts.

A useful cadence has four properties.

• Predictable. Stakeholders know when work will land, not because a date was promised but because the team has landed work on that cadence for the past six cycles.
• Pressure-resistant. When a deadline is threatened, the team does not compress quality to hit it. They descope, communicate, and reset expectations.
• Transparent. Anyone who wants to know what is in flight can find out in under a minute. The backlog is current, the board is honest, the retro notes are public.
• Responsive. Priorities shift without drama. The team does not treat a pivot as an insult. They treat it as information about the Why.

That kind of culture is slow to build and fast to lose. Guard it.

10. A realistic planning culture#

Good planning is not about promising dates. It is about managing expectations. A useful plan highlights assumptions, tracks confidence, shares risk, and leaves space for iteration.

It also accepts that the best plan is the one that is cheap to change. A gantt chart that takes a week to redraw is a gantt chart that will quietly be ignored the second reality diverges from it. A plan that fits on one page and can be re-sorted in an hour is a plan that the team will actually use.

One more principle. A plan should tell you what you will not be doing as clearly as what you will. The items explicitly dropped from this cycle are as important as the ones scheduled in. Dropped items are decisions. Undropped items are weight.

11. The anatomy of a useful status update#

A good When is judged not by the plan itself but by how the team reports against it. A status update that buries trouble wastes everyone's time.

A useful weekly update fits in a paragraph and answers four questions.

• What moved this week, and how does that compare to what we said last week?
• What is genuinely at risk, and what decision would unblock it?
• What have we learned that changes an assumption in the plan?
• What do we need from stakeholders before the next update?

No colour coding, no aspirational language, no bullet lists padded out with low-signal activity. The teams we work with who write updates like this find that stakeholders actually read them, trust them, and stop calling emergency meetings. That is the point.

Summary#

When is not just a timeline. It is a living map of delivery shaped by value, reality, and responsibility. Done well it gives visibility into progress, confidence for stakeholders, and a framework for adjusting with grace.

Plans are worthless, but planning is everything.