PMI Sites
Register
Disciplined Agile
Search

    Practice: Estimation

    The goal of estimation is to create, in a sustainable and repeatable fashion, a system of effort estimates that is useful for iteration planning.

    In particular, when following an iterative life cycle, user story estimation is central to supporting iteration planning and understanding the team’s velocity.

    Why to Do This Practice

    A primary benefit of estimation is the conversation that happens between involved parties about the work to be done. Understanding is more important than accuracy: It validates that everyone understands what is required. Accuracy will come with experience; looking back at previous estimates helps guide estimation of new work.

    Teams face a number of challenges to estimation including going into too much detail, making assumptions, doing design while estimating, and being reluctant to commit to estimates. The team lead must help the team get through these challenges.

    Estimation follows a Plan-Do-Study-Act process: Estimate the work, do the work, check to see what was done and how much effort it took, and incorporate what was learned for the next iteration.

    Estimates reflect the team’s best guess at the moment. Early on, estimates may be +/- 100%. As the team becomes more experienced with the estimation process and have accrued more historic data, estimates become more accurate.

    Agile teams usually estimate the amount of work required to complete a particular user story in terms of story points (or points). A point is not a unit of time. It reflects an arbitrary judgment by the team about how “big” an item of work is.

    Different point schemes can be used. The most common is a modified Fibonacci series: 1, 2, 3, 5, 8, 13, 20, 40, 100, with 1 being very small to 100 being impossibly large. The idea is that the larger the story is, the more uncertainty there is around it and the less accurate the estimate will be. Using the Fibonacci sequence helps teams to recognize this uncertainty, deliberately creating a lack of precision instead of wasting time producing estimates that carry a false degree of confidence.

    Other measures can be used for estimation and the team decides on the approach they are most comfortable with.

    Who Does This Practice 

    Here are the roles involved in this practice:

    What to Do

    Inputs

    Inputs to this practice include:

    • Fully described user story including acceptance criteria
    • Past estimates as reference

    Approach 

    1. Review the user story to ensure understanding.
    2. Discuss any questions that arise. This is critical since it helps unveil non-obvious aspects of the user story.
    3. Estimate the user story collectively; agree on a consensus estimate.

    Tools and Techniques

    There are a number of tools and techniques that can help with estimation. These include:

    • Team Estimation Game (created by Steve Bockman) helps teams size stories based on relative complexity
    • T-shirt size (S, M, L, XL…)
    • Analogy to previous work

    The Plan the Release process goal includes options for choosing an estimating strategy and for choosing an estimation unit.

    Question: What if those doing the estimation only know some of the story?

    It is not uncommon to have a team estimate a story where no single member knows all its aspects; some team members understand how to write the code, others how to test it, and maybe there’s architectural implications as well. Each individual involved in the estimation process has their own view of the effort on hand. Discussing their different views will help the team to build a common understanding of the work and arrive at a consensus estimate.

    Question: What about “no estimates”?

    A common misunderstanding is that the “#noestimates” movement advocates for just skipping the estimation process altogether. This is far from the truth.

    Advanced teams that continuously improve their ways of working may arrive at a process where they routinely split their user stories to be small and similarly sized.

    When planning their iterations, instead of estimating individual stories to understand how many user stories they can take on in an iteration, they just accept a certain number of user stories into their iteration backlog instead. This is a much faster process.

    Question: What if the story will not be done soon?

    Estimates are not really needed for user stories that won’t be worked on for a while.

    When to Do This Practice

    User stories should be estimated prior to or during iteration planning.

    Outcomes

    Some estimate of effort is needed in order to select user stories to be included in an iteration. The length of an iteration enforces “schedule as independent variable” scheduling, where the iteration becomes the independent or stable part of the cost-schedule-scope triangle. To accomplish this, an estimation of effort is used to establish the scope of work that can be accomplished within the iteration.

    May 2023

    Developer Overview