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

Why to do this practice

A primary benefit of estimation is the conversation that happens between appropriate stakeholders 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.

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

Estimation follows the Plan-Do-Check-Act process from lean: Develop the estimate, do the work, check to see what was done and how much effort it took, and incorporate what was learned for the next iteration.

Estimation is done at every level of planning and involves everyone involved in that planning session. Estimates reflect the team’s best guess at the moment. Early on, estimates may be +/- 100%. As learning grows, estimates become more accurate.

Agile Teams usually estimate the amount of work required to complete a particular feature or 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. Team capacity describes how many points they can process. The point scheme used follows a sequence such as: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, 200, 400, 800+. Other measures can be used for estimation and either converted into points or completely replacing them throughout the life-cycle.

Who does this practice

Here are the roles involved in this practice:

• Product Owner
• Team Agility Coach
• Developers
• Tester

What to do

Inputs

Inputs to this practice include:

• Fully defined feature that, if developed and delivered, represents an amount of business value. That value may be provided directly by the feature or when combined with other features.
• An item that is sized at 1 story point to use as a reference

Approach

1. Review the Feature to ensure understanding
2. Review Product Documentation for the Feature
3. Discuss any questions that arise
4. Size the Feature using a relational technique

Tools and techniques

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

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

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 one member knows the size of all aspects of the story. In other words, some teams may have members that understand how to write the code, others how to test it. In these situations, the team must figure out the best way to do estimation.

A good approach is for those who are going to write the code to estimate that aspect of it and those who are going to test the code to estimate that aspect of it and then add the story points of each sub-estimate together to get a total story point for the story.

For example, developers may say it will take 8 story points to develop a story and the testers say it will take another 5 to test it. The story estimate is 13 story points.

Question: How do we know we are done with estimation?

Teams will quickly discover that estimates without getting this question answered will usually be lower than what they would have estimated with this question answered. This is a very important question to answer: not just to better understand the story but also to help create better estimates.

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

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

When to do this practice

Do this practice as needed prior to pulling for delivery.

Where to do this practice

Estimation is done in the area where the estimators work such as the team’s work space.

Outcomes

Some estimate of effort is needed in order to select the features and stories to be included in an increment. At the feature level, these are usually very rough estimates. As the feature is decomposed into stories and/or tasks, the estimation can be more accurate because it is easier to estimate smaller things. 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.