agile_esimation

View Github Repository Open presentation in a new window

jwalton

See all presentation from jwalton

agile_esimation

0 0

agile_esimation

Presentation about Agile Estimation Techniques

On Github jwalton / agile_esimation

Agile Software Estimation

Estimates

  • $$$
  • Time, Staff
- Money and time are what we're really after. - These are impractical units of measurement for a lot of reasons.

How Big is Your Project?

  • KLOC
  • Function Points
  • Hours, person-month
  • T-Shirt Sizes
  • Story Points
- KLOC is thousand-lines-of-code. COCOMO is based on KLOC. - Function points are a measure of "business functionality". - SLIM based on historical data and a giant database - "Built Up" estimation where you break a project down into components, you assign hour estimates to components, multiply by a factor for verification, fixing, reverification. - Story points - what this presentation is about. - Historical data.

Cone of Uncertainty

From Estimating by Mitch Lacey

  • Project estimates can be out by a factor of four.
  • When estimating, no point in arguing over minor details - accuracy over precision.

Estimates are for "Done"

                * Design Docs
  • Code
  • Unit tests
  • Integration test cases
  • Verification, repair, reverifcation
  • Release notes
- Estimate is an informed guess at what's involved to complete something. Ephasis on the "complete". - Engineers never tell you "This is how much it will cost to build a bridge if you don't mind it falling down."

Who should Estimate?

From The Classic Story of the Pig and Chicken

  • Pig is someone who actually does work. Chicken is someone who profits from the work, but isn't directly involved.
  • When a pig makes an estimate, it's their bacon on the line.

Story Points

  • Team Specific
  • Relative
  • Dimensionless units
  • Often use a Fibbonaci(ish) scale
    • 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 30, 50, 100, ?
  • Accurate rather than precise
- Story points are nice because they are numerical, so you can add them together and divide them - hard to do with t-shirt sizes. - Story point is a relative scale, no units. Story points are a measure of the size of a feature relative to other features, not an estimate of how long a feature will take. - Fibbonaci scale is used to prevent you from nitpicking - no point in arguing about whether something is a 10 or an 11.

Story Points

From Story Points vs. Development Hours by Thom Roach

  • Story points are relative - if task A is twice as big as task B, then it should have a score that's about twice as big.
  • Dimensionless because they are relative. "3" isn't 3 days or 3 kloc of code, it's just 3. All a 3 tells you is it's half the size of a 6 and twice the size of a 1.5.
  • Fibbonaci scale is used to prevent you from nitpicking - no point in arguing about whether something is a 10 or an 11.
  • Since they are relative, how do you bootstrap?

Bootstrapping Story Points

  • Ideal days
  • Binning
  • Wall Estimation

Wall Estimation

From Estimating by Mitch Lacey

Wall Estimation

From Estimating by Mitch Lacey

Planning Poker

From Let's Play Planning Poker by Jeff Atwood

We discuss a task. We all privately decide how many points it should be and pick a card. We all show our cards at the same time - if there's consensus, we move on to the next task. If not, high and low estimators discuss why their estimates are different. Use an egg timer to prevent discussions from going on too long. Goal is to estimate, not decide how everything should be implemented in the meeting.

When everyone agrees, planning poker goes quickly. When people wildly disagree, it's a good indication that someone doesn't understand something about what's being asked.

Now we have story points. Now what?

Velocity

Story Points / Time (/ Person)

- You "claim" story points when you finish a task. No partial points for a half-finished task. - If a team of 4 people consistently completes about 20 points of work every 2 weeks, then we can make predictions about what features will be in the product two months from now. We can say "Yes, you can have this feature, but this is the other features it's going to cost you."

Micro Estimation

Story points vs Hours

- Story points answer "What can we get done in two weeks?" and "How long until I can have this feature?" - Breaking a "story" down into "tasks" with estimates in hours answers "How are we doing?"

Burn Down Chart

From Wikipedia

Note that to produce this chart you need to keep track of how many hours are left on each task. Not a bad idea to keep track of how many hours you actually worked on each task, too, as this will tell you how accurate your estimates are. Time worked is also historical data that it very helpful in generating future estimates.

Keeps track of how we're doing, and also keeps us accountable to ourselves.