Agile Planning and Estimation
What to Know
Agile planning is iterative and emergent, not a single upfront event. Know rolling-wave planning, release planning, Sprint Planning, and backlog refinement.
Estimation techniques: story points (relative size, abstract), planning poker (consensus), t-shirt sizing, affinity estimation, and ideal days. Relative estimation compares items to each other; velocity is the average points completed per Sprint and is a forecasting tool, not a performance metric.
User stories follow the "As a … I want … so that …" form and are refined with acceptance criteria and INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable).
Capacity vs. velocity: capacity is available effort (people × time minus absences); velocity is historical throughput. Use both to forecast, never to commit rigidly.
Traps
- Story points as absolute time. They are relative and team-specific; do not convert to hours across teams.
- Velocity as a productivity score. Using it to compare teams or pressure people is an anti-pattern.
- "Estimate everything upfront." Agile estimates at the last responsible moment, in detail only for near-term work.
- Planning poker as averaging. It is consensus-based; outliers spark discussion.
- Confusing capacity with velocity in forecasting.
- Big stories (epics) estimated as if ready - split before estimating.
Rule of Thumb
Estimate relative size with the team, forecast when using velocity × Sprints, and refine only what's near. If an item can't be estimated, it's too big or too unclear - split or clarify it.
Worked Example
A team's velocity is 20 points/Sprint. A release of 60 points needs ~3 Sprints. If two members are out next Sprint, reduce capacity and forecast conservatively - don't inflate velocity.