Reading Path for Product Manager
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 Master 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:
What to do
Inputs to this practice include:
Tools and techniques
There are a number tools and techniques that help with estimation. These include:
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.
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.