What you’ll learn in this presentaion
- How estimates are used on Agile projects.
- How to define estimates.
- The basics of planning poker to help estimate.
- Planning occurs throughout the development cycle and is spread across the entire team.
- “Work the plan, not work to the plan.”
- A user story is a short description of a function that an end user would want.
- Stories serve as a form of currency between the customers and the development team.
- Estimates are needed to support ongoing planning in Agile projects.
- Estimates help to answer the following questions:
- How many stories can we fit into the release?
- How many stories will be completed in the next iteration?
- What are the impacts of adding, removing and changing stories?
- An estimate is a measure of the relative size, interms of effort, of a story.
- Why focus on size?
- Estimate size to derive duration.
- Size can be estimated.
- Duration is hard to determine due to meetings,non-work appointments and other distractions that cannot be estimated.
• Not separating effort from duration is a common estimating error.
• In reality, developers (and people in general) are good at estimating the effort required to complete something but not the time needed.
• For software, development effort can be estimated but, to determine duration, additional time needs to be factored in to account for:
1. non-development project time (e.g. standup meetings), and
2. non-project work time (e.g. internal nonproject meetings, medical appointments).
• Baseball analogy: the effort to complete a game is 54 outs or 9 innings, but what’s the duration of these events – and those in between?
- Ideal Time = effort
- Time required to complete something with no interruptions.
- Represents effort.
- Can be estimated relatively accurately.
- Real Time = duration
- The actual time to complete something.
- Includes breaks, distractions, delays.
- Difficult to estimate – must be derived.
- Address the Law of Diminishing Returns
- Make the most efficient use of development time.
- Benefits from the input of several people
- Estimates are shared amongst the team.
- Supports ongoing planning
- Facilitate planning discussions at the right level.
- Easy to change
- Can be revised, split, etc.
- Estimates can be measured in terms of:
- Ideal days.
- Any other unit of measurement that makes sense to the team.
- Common estimating scales:
- Standard interval – 1, 2, 3, …
- Fibonacci series – 1, 2, 3, 5, 8, 13, 21, …
- Doubling interval – 1, 2, 4, 8, 16, …
- A measure of the rate of progress.
- Needed for iteration and release planning.
- Usually measured in terms of points or ideal days per iteration.
- Converts ideal time or estimates to duration.
- Corrects for variability and errors in estimation.
Three Primary Methods:
- Historical Values
- Use observed velocity from past iterations.
- Test Iterations
- Run a test iteration and measure actual velocity.
- Compare available staff hours with story task breakdown estimates.
- Recognized as one of the best ways for Agile teams to estimate because it:
- encourages the entire development team to participate;
- is easy, interactive, and fun; and
- facilitates quick consensus on estimates.
- Team meets around a table with cards.
- Moderator reads out a story.
- Moderator answers questions.
- Estimators privately select a size card.
- Estimators show their cards.
- Any discrepancies are discussed, additional questions are answered.
- Estimators re-estimate by selecting a new size card and revealing it.
- The moderator can be anyone…product owner, scrum master, analyst, etc.
- Keep to the left side of the effort/accuracy curve.
- Limit each round of discussion to no more than a few minutes – a timer can help.
- Convergence is usually reached on the 2nd round.
- Absolute agreement is not required.
- 5, 3, 5, 8, 5 – this would be sufficient to arrive at 5 as the estimate.
Mike Cohn’s site contains a good description of Planning Poker:
The Crisp site is also a good source of Planning Poker basics:
Intelliware’s Knowledge Centre contains several resources on the basics of Agile: