Agile Planning and Estimation Practices
Domain focus
This domain tests how Agile teams estimate, forecast, and plan under uncertainty. Expect questions on relative estimation, story points, velocity, capacity, backlog refinement, release forecasting, and the difference between a forecast and a commitment.
Relative estimation and story points
People estimate relative size more reliably than absolute duration. Story points express size, complexity, effort, and uncertainty; they are team-specific and are not converted to hours. Common techniques are planning poker, affinity estimating, and t-shirt sizing, often anchored to reference stories. Ideal days are an alternative but invite false precision. Estimates should be revisited as understanding grows; refinement is ongoing, not a one-off event. A user story is a placeholder for a conversation, and INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) is a useful quality checklist, not a Scrum rule.
Velocity, capacity, and forecasting
Velocity is the average number of story points completed per Sprint while meeting the Definition of Done, usually taken over the last three to six Sprints. It is a planning input, not a productivity target, and should not be compared across teams. Capacity planning considers available person-days and absences for the coming Sprint. Release forecasts are probabilistic ranges, not fixed dates; the Cone of Uncertainty narrows as work progresses. Burn-down and burn-up charts make progress transparent but are diagnostic tools, not management mandates.
Worked example
A team completed 28, 32, 30, and 34 points, averaging 31. Two Developers will be on leave next Sprint, reducing capacity by about 20%, so a reasonable forecast is 24–26 points. A stakeholder asks for a date for 120 points. At 31 points per Sprint, that is about four Sprints, but because the estimate is uncertain and scope may change, the team communicates a range of four to five Sprints and re-forecasts each Review. The reasoning: velocity informs a forecast; capacity adjusts it; the commitment is to the Sprint Goal, not to a point total.
Traps that cost marks
Do not convert story points to hours or use them to compare teams. Do not treat velocity as a target that managers can demand. Do not estimate every backlog item in detail; refine just enough for near-term planning. Do not present a release date as certain when scope is fixed and estimates are uncertain. Do not confuse the Definition of Done with acceptance criteria. Do not call backlog refinement a formal Scrum event; it is a useful practice, not one of the five events.