Provide a summary of this practice.
All stories are estimated during Release and Iteration Planning, to quantify the effort needed to complete them.
What is the overall goal or intention of this practice?
Estimating is the practice through which Agile teams check that:
Estimates also allow the pace of work to be tracked and the likelihood of completing on time to be judged.
Estimates should be performed for all stories during both release and iteration planning.
What are the schedule, cost, quality, frequency, performance or other expectations for completing this practice?
Estimating occurs only as part of planning. See the appropriate planning page for details.
What must have happened or been delivered for this practice to be considered complete?
Estimating is complete when the team is confident that the item being estimated can be realistically completed in the estimated time.
In either case, the goal is reasonableness, not absolute precision.
What pre-conditions must be met before this practice is used?
Estimating cannot begin until the stories are adequately understood:
This view shows a simplified version of this process. For full details, explanation and advice, click on the ‘Detailed process’ tab. For background such as entry and exit conditions, click on the ‘Context’ tab.
|1||Play planning poker.|
|1||Play planning poker.||Product Owner.|
Issues & risks
What are the key concerns in making a success of this practice?
- For general advice on estimating, see here.
- A range of estimation techniques are described here.
- Estimate sizes are often expressed in terms of story points. These are explained here. However, there are other approaches – see here for examples.
- The single most important factor in the quality of estimates is the team’s insight into exactly what the story really means.
- A high level of insight depends on a carefully written story –
- – but also on close, productive and ideally direct relationships, both within the team and between the team, the Product Owner and the users.
- It’s crucial that the group estimating stories must not be pressured into agreeing to an estimate on any other basis than real agreement about what the story means, what the issues are with implementing it, and so on. This will simply lead to a very bad estimate – and undermine the team’s confidence and cohesion too.
- Other likely contributors in the iteration or release effort (e.g., independent testers) should usually be invited to participate in the estimating session.
- Retrospectives should evaluate how effective estimates were, identifying what caused any mistakes and recalibrating how future estimates are done.
- The whole isn’t always equal to the sum of its parts.
- Once an epic is decomposed into stories, the sum of story estimates don’t always add up to the previous total for the epic.
- Likewise, the sum of tasks in a story doesn’t necessarily equal the original story.