Planning: Flow, Small Batches, and Forecastable Work
The Planning domain tests lean and agile planning for flow: backlog shaping, work-in-progress limits, dependency management, forecasting, and aligning plans with architecture and operations. The exam favors plans that expose queues and variability over detailed long-range schedules.
Core rules
- Plan in small, vertical slices that deliver value or learning. Large batches hide defects, increase integration risk, and delay feedback.
- Visualize work on a Kanban board and apply its practices: make work visible, limit WIP, manage flow, make policies explicit, use feedback loops, improve collaboratively.
- Use Little's Law as a queueing model: average lead time equals average WIP divided by throughput. It explains why 100% utilization and excessive WIP lengthen delivery time.
- Forecast with historical cycle-time ranges and percentiles, not single-point commitments. Rolling-wave planning is appropriate when uncertainty is high.
- Manage dependencies explicitly through team interfaces, architectural runway, and sequenced slices. Story mapping and impact mapping connect backlog items to user journeys and outcomes.
- Reserve capacity for unplanned work, technical debt, and operational duties; otherwise hidden work consumes the plan silently.
Worked example
A program has 24 features in progress and completes 6 per week, so average lead time is about 4 weeks by Little's Law. Leaders demand faster delivery and propose more parallel work. Instead, the team limits WIP to 12 and holds throughput at 6 per week. Average lead time falls toward 2 weeks, and cycle-time data shows the 85th percentile is 3 weeks. Reasoning: adding WIP would lengthen queues, while limiting it improves predictability. The forecast is expressed as a range, not a fixed date.
Traps that cost marks
- Treating 100% utilization as efficiency; it removes slack and increases waiting time.
- Comparing story points or velocity across teams as productivity measures.
- Producing a detailed Gantt plan for uncertain, dependency-heavy work and calling it commitment.
- Planning only feature work and ignoring support, debt, and unplanned demand.
- Confusing output (items completed) with outcome (customer or business result).