2-3 Estimation Techniques PDF

## 2-3 Estimation Techniques ### Outline - Law of diminishing return - Techniques - As a team - One order of magnitude - Good sequences - Zero - Large stories - Methods for estimating - Expert opinion - Analogy - Disaggregation ### The law of diminishing return - A grap...

## 2-3 Estimation Techniques ### Outline - Law of diminishing return - Techniques - As a team - One order of magnitude - Good sequences - Zero - Large stories - Methods for estimating - Expert opinion - Analogy - Disaggregation ### The law of diminishing return - A graph showing "Accuracy" on the y-axis and "Effort" on the x-axis. - The curve increases rapidly before reaching an inflection point and then slowly decreases. - The caption reads: "Additional estimation effort yields very little value beyond a certain point." - Agile teams use less effort to get a similar accuracy, and rely on iterative updates to improve the accuracy. ### Comments about the graph - No matter how much effort is exerted, the estimate is never 100% accurate. - About 10% of the effort gets 50% of the accuracy. - It is possible to put too much effort into estimating, resulting in a less accurate estimate. ### Estimate collaboratively as a team - Traditionally, the person who will do the work makes the estimate on effort. - In agile plans, at the start, we don't know for sure who will be working on a certain story. - So we estimate as a team. The input of others helps result in more accurate estimates. ### Keep the estimation scale at one order of magnitude - Studies show we are best at estimating things that fall within one order of magnitude. - Can you distinguish a 1-point story from a 2? - How about estimate a 15 in scale 1,2,4,8,16? - A false level of precision. ### May introduce zero - The team use it when they don't want a trivial feature to count in your velocity calculation---this is wrong. - Everyone on the team (esp. product owner) needs to understand that 5 * 0 ≠ 0. - Alternative: group small, trivial stories and estimate them as a unit. ### Large user Story - Theme: set of related stories - Epic: a large user story - We may not implement (we are not sure we want) - That will be implemented far into the future - Add 10, 20, 40, and 100 to estimate these - NOT for stories to be implemented in the next few iterations. - True we reduced estimation effort, but estimates of themes/epics are less accurate than their smaller stories. ### Exception: Partially Completed Stories - When a team finishes an iteration and is calculating their achieved velocity, what should they do if a story is only partially completed? - If anything in the story is not done, they earn no points. - If the story is finished (coded, tested, and accepted by the product owner), team earns all the points. - Works well because velocity in one iteration will be slightly low and in the next will be slightly high, and in the end we care about a team's average velocity. ### Methods for deriving an estimate - Main methods: 1. Expert opinion 2. Analogy 3. Disaggregation 4. Planning Poker ### 1. Expert Opinion - An expert is asked to estimate the story, and based on their intuition and experience they give it a number. - Quick method. - In agile projects, it's hard to find an expert because each story is cross-functional (analysis, design, coding, testing). ### 2. Analogy - Estimators compare the story with other stories. - Studies show we're better at estimating relative size than absolute size. - Don't use just a single reference story. - Instead, use triangulation. - Compare the story with an assortment of stories that have already been estimated. ### 3. Disaggregation - Break a large story you find difficult to estimate into smaller stories you can estimate. - Disaggregating TOO FAR causes problems: - Forgotten tasks - Summing many small errors can result in a larger error. ### Planning poker - Best method to derive estimates. - Combines expert opinion, analogy, and disaggregation. - Quick, fun, and reliable. ### Who plays? - All team developers: analysts, programmers, testers, etc. - Select a moderator. - Each person (+ moderator) is given a deck of cards with all possible estimates largely written on them: 1,2,4,8,16. ### How do we start? - For each user story, the moderator reads its description. - Then, the team is allowed to ask clarifying questions from the product owner. - But remember the law of diminishing return. ### The first round - Each estimator privately chooses a card to represent her estimate. - All cards are simultaneously turned over. ### Usually estimates will differ significantly in this first round. ### Discussions and more rounds - So ask the highest and lowest estimators to explain their rationale. - Re-estimate until estimate converges. ### An example - A table showing: - Estimator - Round 1 - Round 2 - Susan | 3 | 5 - Vadim | 8 | 5 - Ann | 2 | 5 - Chris | 5 | 8 ### Advantages of Planning Poker - Combines multiple expert opinions from a cross-functional team, and everyone's opinion is heard. - Allows for discussions which help compensate for missing information. - Averages individual estimates which leads to better results. - Keeps the "we're all in this together" mode (no future blaming) while allowing those who will do the work to estimate it. - It's fun, efficient and reliable.