Agile Estimating

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.

The Agile Planning Process

  • 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.

The Agile Planning Process

  • 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?

What is an Estimate?

  • 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.

Effort vs. Duration

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:

  • non-development project time (e.g. standup meetings), and
  • 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 vs. Real Time

  • 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.

The Value of Estimates

  • 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.

Estimate Values

  • Estimates can be measured in terms of:
    • Points.
    • 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, …

What is Velocity in Estimating?

  • 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.

What is Velocity in Estimating?

  • Three Primary Methods:
    1. Historical Values
      • Use observed velocity from past iterations.
    2. Test Iterations
      • Run a test iteration and measure actual velocity.
    3.  Forecast
      • Compare available staff hours with story task breakdown estimates.

Planning Poker

  • 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.

Planning Poker Procedure

  • 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.
  • Repeat.

Planning Poker – Key Things to Remember

  • 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.

For More Information