3.4.1. Agile Estimation Techniques

💡 First Principle: Agile estimation focuses on collaborative, relative sizing to enable near-term planning and forecasting, embracing uncertainty rather than striving for false precision in long-range predictions.

Scenario: An agile team needs to plan its next sprint but is unsure how much work it can take on. The project manager facilitates a 'Planning Poker' session where the team collaboratively assigns story points to backlog items. Based on the team's historical 'Velocity', they can confidently pull the right amount of work into the sprint.

Effective estimation in agile environments focuses on relative sizing for near-term planning and forecasting.

• Purpose: Understand relative size for near-term planning and high-level forecasting, not predict exact dates far out.
• Units: Story Points or Ideal Days (relative units). Accuracy vs Precision matters. Provide ranges initially; use probabilistic estimates for high uncertainty.
• Techniques Compared: Planning Poker (builds consensus), T-Shirt Sizes (quick, high-level), Affinity Estimating (fast grouping), Analogous Estimating (uses similar past items), Wideband Delphi (iterative expert consensus). Done by the team doing the work.
• Velocity Calculation: Average points completed over last 3-5 iterations. Use: Forecast iterations needed (Total Points / Velocity ≈ Iterations); Plan capacity for next iteration.
• Pitfalls: Treating as target, comparing teams, assuming constant. Estimate includes all work for DoD. Flow uses Cycle Time x Throughput.

⚠️ Common Pitfall: Using velocity as a performance metric to compare different teams. Velocity is a capacity planning tool for a specific team with its unique context and point scale; it is not a measure of productivity.

Key Trade-Offs:

• Consensus Building (Planning Poker) vs. Speed (Affinity Estimating): Planning Poker fosters deep discussion and shared understanding but is slower. Affinity estimating is very fast for large backlogs but provides less detailed discussion per item.

Reflection Question: Why is it a fundamental agile principle that the team doing the work should be the one to estimate it?