Estimate a story

Estimate a story2018-06-05T14:29:07+00:00

Estimate Story Workflow

Context

Summary

Provide a summary of this practice.

All stories are estimated during Release and Iteration Planning, to quantify the effort needed to complete them.

Purpose

What is the overall goal or intention of this practice?

Estimating is the practice through which Agile teams check that:

  • The work included in a release or iteration backlog can realistically be completed in the time available.
  • The work is worth doing (based on the ratio of the cost of a story to the value of its expected benefits).
  • The team is big enough to do all the work they commit to.

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.

SLA

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.

Exit conditions

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.

  • For release planning, estimating is finished when an indicative figure for the time required to complete the release as a whole has been agreed by the team.
  • For iteration planning, estimating is complete when the story points required for each individual story in the iteration have been agreed by the team.

In either case, the goal is reasonableness, not absolute precision.

Entry conditions

What pre-conditions must be met before this practice is used?

Estimating cannot begin until the stories are adequately understood:

  • The parent feature is identified.
  • The corresponding tasks are identified.

Outline process

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.

#StepInstructions
1Play planning poker.
  1. The team plays ‘Planning poker‘ for the highest priority backlog items.
2 Refine estimates.
  1. If team members’ estimates do not agree:
    • The authors of the highest and lowest estimate are asked to explain their figures.
    • Their explanations are listened to without interruption.
    • Their rationales are then discussed by the team.
  2. The game of planning poker is then repeated for that story.
  3. This process continues for each estimate until an agreed figure is reached or the team regards the variation between estimates as trivial.
3Finalise estimates.
  1. The stories are updated to show the agreed estimates.

Detailed process

#StepByOutputInstructionsNotes
1Play planning poker.Product Owner.

Iteration Lead.

Team.

Personal estimates.
  1. The team plays ‘Planning poker‘ for the highest priority backlog items.
  • The Product Owner leads the creation of release-level estimates.
  • The Iteration Lead leads the creation of iteration-level estimates.
2 Refine estimates.Team.

Iteration Lead.

Product Owner.

Team estimate.
  1. If team members’ estimates do not agree:
    • The authors of the highest and lowest estimate are asked to explain their figures.
    • Their explanations are listened to without interruption.
    • Their rationales are then discussed by the team.
  2. The game of planning poker is then repeated for that story.
  3. This process continues for each estimate until an agreed figure is reached or the team regards the variation between estimates as trivial.
3Finalise estimates.Team.

Iteration Lead.

Product Owner.

Updated stories.
  1. The stories are updated to show the agreed estimates.
  • The Product Owner leads the finalisation of release-level estimates.
  • The Iteration Lead leads the finalisation of iteration-level estimates.

Issues & risks

What are the key concerns in making a success of this practice?

  1. For general advice on estimating, see here.
  2. A range of estimation techniques are described here.
  3. Estimate sizes are often expressed in terms of story points. These are explained here. However, there are other approaches – see here for examples.
  4. 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.
  5. 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.
  6. Other likely contributors in the iteration or release effort (e.g., independent testers) should usually be invited to participate in the estimating session.
  7. Retrospectives should evaluate how effective estimates were, identifying what caused any mistakes and recalibrating how future estimates are done.
  8. 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.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?