Agile 2006: Agile Estimation Techniques

Agile Estimation Techniques
Owen Rogers
Wednesday morning, first half

Distilling experiences of estimation on agile projects. Specifically estimating stories.

  • Mike’s session was “fabulous” yesterday.
  • Mike has a book, “Agile Estimating and Planning”

Disclaimers:

  • This session contains statistical jargon, charts with curvy lines, and gross generalizations.
  • Worked for me. YMMV.
  • If this stuff contradicts what you’ve heard from other people at ThoughtWorks, don’t hold it against them.

Accuracy: How close to target
Precision: How big the target is
Decrease precision = increase accuracy. Inverse.
So, one way to increase accuracy is to go less graunlar.

Anatomy of an estimate

  • What you know
  • What you think you know, but don’t
    • E.g., Integration, customer’s intentions
  • What you know you don’t know.
    • E.g., sick time, new technology, changes in requirements.
  • What you don’t know you don’t know
  • Estimate what you know, derive what you don’t. The first 3 are what you know.
  • Pick an “average” story, call it a 3.
  • Everyone holds up some number of fingers. 2 = slightly easier than average. 5 = there’s sufficient uncertainty that I really can’t estimate; we need to split the story.
  • Relative, not necessarily linear. If you split a 5 into smaller stories, they won’t necessarily be a 3 and a 2.
  • Interdependencies? Up to team to decide. If there are interdependencies, make sure they’re communicated to the customer.
    • Possibility: estimate as if they’re not interdependent.
    • Possibility: Contingent estimates. If this, then that.
  • Estimate size. This includes both time and complexity.
  • We’re talking about how much work, not how long it would take a particular person to do it.

Handout: Suggested way to do a planning game.

  • Primary goal: produce estimates for a set of work.
  • Secondary goal: understand what that work entails.
  • Factor out things that don’t contribute to those goals, e.g. technical discussions.
  • Customer introduces a story.
  • Estimators ask business-related questions
  • When ready to estimate, hold out fist on top of other flat palm. (Don’t bias others with your estimate)
  • If everyone picks same number, the estimate stands. Move on to next story.
  • If there’s disagreement, have a 2-minute time-boxed discussion.
  • If we still don’t agree, pessimist wins.
  • If a story can’t be estimated in 10 minutes, drop it from the iteration, and add a spike card focused on splitting the story.
  • MeSoLonely: on-line dating service
    • As a suitor, I want to register for a new account (username, password, and email address). Estimate: 3.
    • As a suitor, I want to change physical details (height, weight, hair color, build, tastes). Our estimate: 3.
    • As a suitor, I want to search for a match by physical details. Our estimate: 4.
    • As a pharmceutical agent, I want to spam users with ads. Our estimate: 1?
    • As a suitor, I want to upload my photo
    • As a suitor, I want the system to send an e-mail message to my match

Easy to get people comfortable producing estimates, even if they don’t know much about the system. With only five possibilities, you can’t be too far off. You also build coordination skills.

Can’t necessarily compare estimates made far in advance with those made just before you do the work. Different amounts of uncertainty within the project.

What are story points?

  • Uncertainty -> probability distribution. Actually a lognormal distribution (like a normal distribution, but with a long tail).
    • Mike’s book has an explanation for why it’s lognormal.
    • Paper by Todd Little: confirmed that it’s lognormal. Don’t know the paper’s title, but it was in last month’s IEEE Software.
  • Mode (highest point) and mean are different.
  • Story points inherently encompass this distribution. Each point value is its own probability distribution; the larger ones have a wider variance, with the mode and mean farther apart.
  • 4 + 4 != 8 — Beware of the scaling fallacy. A 4 isn’t necessarily 30% larger than a 3. That’s why we limit the upper bound to 5 — so the estimates don’t get too large.

Could drop precision, and say that all stories are the same size. If stories are all about the same order of magnitude, this actually works fairly well.

  • The most important estimate is the 5. The others don’t matter as much.
  • But, wouldn’t recommend doing this right off the bat.
  • When splitting, do it collaboratively with the customer. That way, they’ll learn how to do it.

Minimizing what you think you know, but don’t

  • System = overlap between Business Domain and Technical Domain.
  • The more we understand about both, the less likely we are to have misunderstandings
  • Become a generalizing specialist. Don’t just be a DBA.
  • Leverage the Wisdom of Crowds. Let the testers estimate. Let the customer estimate.
    • When the customer estimates, that communicates what they expect the size to be. Can lead to interesting discussions. If the customer thinks it’s a 4 and the customer thinks it’s a 2, the customer goes away happy. If it’s the reverse, maybe the developers don’t understand the whole story.

Who estimates? The more people with different perspectives you can involve, the better your information will be. So by all means, include QA, documentation, support.

Histograms

  • Mostly 3s (i.e., mostly a normal distribution of estimates): Stories fairly well-understood. Lower risk.
  • Want to be able to assume the mean, because the mean is what provides you with safety.

Create a histogram of your release plan. Split stories until you end up with an approximately normal distribution, so you get more safety. Can do this over the course of the release.

  • Consistency is more important than accuracy.
  • Another argument for splitting: More stories = more consistent velocity.

Leave a Reply

Your email address will not be published. Required fields are marked *