: When – Planning, Estimation, and Prioritisation

Why “When” Turns Design Into Delivery

You’ve identified the users, clarified what needs to happen, understood the value, mapped the technical journey, and chosen where it will live. Now it’s time to determine when, and at what cost, this vision becomes a reality.

The “When” is about orchestration: the thoughtful coordination of time, effort, budget, and value. It’s where software planning meets project management and funding models. It’s 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
Triaging and stakeholder alignment workflows

1. Connecting the Ws: Inputs to Planning

Every “W” contributes to a more accurate and useful plan:

W	Planning Impact
Who	Role-based priorities and stakeholder scheduling
What	Work item breakdowns and complexity estimates
Why	Value scoring and ROI analysis
How	Technical effort and dependency mapping
Where	Infrastructure lead times and deployment planning

A good plan doesn’t just answer when it will be done, but also why this order, what’s risky, and how confident are we.

2. Backlog and Work Item Structure

Break initiatives into epics → features → stories/tasks:

Example Structure:

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 to “How”)
Value/effort scoring (for prioritisation)

3. Prioritisation Models

MoSCoW

Must Have / Should Have / Could Have / Won’t Have

RICE

Reach × Impact × Confidence ÷ Effort

Weighted Shortest Job First (WSJF)

Cost of Delay ÷ Duration

Custom Model Tip: Blend business value, operational urgency, and architectural foundations. Technical debt should be consciously prioritised, not ignored.

4. Estimation Techniques

Effort Estimation (Time)

T-shirt sizing → story points → hours/days
Relative estimation in group settings (planning poker)

Cost Estimation

Combine:

Engineering time (salaries × time estimate)
Infrastructure (VMs, storage, cloud services like Firebase, Redis, etc.)
3rd party (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

Estimation should include variance ranges (best/likely/worst case) and be regularly revisited.

5. Delivery Planning & Roadmaps

Sprint/Iteration-Based

Weekly or biweekly sprints
Regular retros + demos for visibility

Milestone-Based

Key delivery checkpoints (e.g., MVP, public beta, v1.0)
Links to cross-functional dependencies (design, legal, data)

Tooling Examples:

Linear / Jira for backlog and sprints
Notion / Confluence for delivery docs
Gantt chart overlays for exec communication

6. Triaging and Change Management

Not everything planned will happen in the right order. Implement:

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

7. Budgeting and Cost Control

Set runway targets per team (e.g., £XX/month max dev spend)
Link cloud spend monitoring (via billing APIs or dashboards)
Track cost-to-build vs cost-to-run to avoid surprises
Pre-calculate margin pressure for usage-based pricing

8. Realistic Planning Culture

Good planning isn’t about promising dates, it’s about managing expectations. A useful plan:

Highlights assumptions
Tracks confidence levels
Shares risk exposure transparently
Creates space for innovation and iteration

9. Summary

“When” is not just a timeline, it’s a living map of delivery, shaped by value, reality, and responsibility. When approached well, it gives:

Visibility into progress and intent
Confidence for stakeholders and teams
A framework for adjusting with grace

“Plans are worthless, but planning is everything.” – Dwight D. Eisenhower

This is where design gets real, and strategy meets execution.

Conclusion

Software planning doesn’t need to be chaotic. It doesn’t need to rely on blind estimations, vague specifications, or last-minute design compromises. The 6Ws methodology brings structure to creativity, and intention to delivery.

By consistently asking:

Who is this for?
What must it do?
Why does it matter?
How will it be built?
Where will it live?
When will it happen?

you create a compass that guides every decision with clarity.

6Ws: When – The Timeline and Delivery