Agile estimates are forecasts
Estimates help a team make decisions. They are not guarantees of exact future performance. Good estimation makes uncertainty visible and improves planning conversations.
Relative estimation
Teams may compare items using story points or other relative scales. The point is to compare size or complexity, not to create a fake unit of time.
Capacity matters
Past throughput can help forecast what a team may complete, but capacity changes with holidays, incidents, support work, onboarding and other realities.
| Question | Practical answer |
|---|---|
| High value / low effort | Usually strong candidate |
| High value / high effort | Explore slicing or sequencing |
| Low value / low effort | May still be useful if it removes friction |
| Low value / high effort | Challenge the need |
Spikes and discovery work
When uncertainty is technical or product-related, a small investigation can be more responsible than committing to a large estimate based on guesswork.
Estimate uncertainty, do not hide it
Relative estimation is useful because the team can compare items without pretending that an uncertain story can be predicted to the nearest hour. Large estimates often signal complexity or missing information, which is itself valuable information.
Capacity is more than working hours
A four-person team may have fewer than the theoretical available hours because of support requests, meetings, leave, production issues and review work. If the plan repeatedly assumes 100% feature capacity, the team may look “slow” when the plan is the real problem.
Prioritization and estimation belong together. A high-value item with large uncertainty may deserve an early technical spike or discovery task rather than a blind commitment.
Estimate eight eCommerce stories using relative sizes. Choose one large story to split and one uncertain story to investigate before estimating further.