agile software estimation

57
Agile Software Estimation - Sunil Kumar

Upload: sunil-jakkaraju

Post on 08-May-2015

12.614 views

Category:

Technology


0 download

DESCRIPTION

This presentation discusses the following: What is an estimate?What are the factors influencing estimating?How are agile projects estimated?How Agile estimation solves common estimation problems?

TRANSCRIPT

Page 1: Agile Software Estimation

Agile Software Estimation

- Sunil Kumar

Page 2: Agile Software Estimation

Agenda

• What is an estimate?• Scenario• What are the factors influencing estimating?• How are agile projects estimated?• How Agile estimation solves common

estimation problems?

Page 3: Agile Software Estimation

How to estimate this task ?

Page 4: Agile Software Estimation

What is an estimate?

Unbiased, analytical process to predict the duration or cost of a project

Page 5: Agile Software Estimation

• Estimation is the calculated approximation of a result which is usable even if input data may be incomplete or uncertain.

Page 6: Agile Software Estimation

What does the definition mean?

Page 7: Agile Software Estimation

By definition estimate is not accurate

Page 8: Agile Software Estimation

Estimation is prediction not PLAN

Page 9: Agile Software Estimation

Typical first estimate is off by factor of 4

Page 10: Agile Software Estimation

We are not good in absolute measurement

Page 11: Agile Software Estimation

We are good in comparing things

Page 12: Agile Software Estimation

Estimates are not commitments

Page 13: Agile Software Estimation

Time is not persistent

Page 14: Agile Software Estimation

Scenario

• You are told to estimate a project to “build a space shuttle that will land on moon”

• You say “It will take 6 months to 2 years”

• Your superior hears “It will take 6 months”. why? – optimism bias, organization, political and competitive pressures.

Page 15: Agile Software Estimation

Scenario contd..

• 6 month estimate breakup– 1 month design– 4 months implementation– 1 month testing

Page 16: Agile Software Estimation

Scenario 1 contd..

• Design takes 5 weeks, late by 1 week

• How much did the project slip?– 1 week?– 25% ?

Page 17: Agile Software Estimation

Answer

• 25% slip in project– 25% of design = 1 week– 25% of implementation = 1 month (approx 4 weeks)

– 25% of testing = 1 week

• Total slip in project = 6 weeks

Page 18: Agile Software Estimation

Factors influencing estimating

Page 19: Agile Software Estimation

Assumptions (domain jargon)

Page 20: Agile Software Estimation

Anchoring (by customers)

Page 21: Agile Software Estimation

Same specification

•One page spec

•7 Pages spec 173 hours

117 hours

•Group A

•Group B

Page 22: Agile Software Estimation

Irrelevant information for same spec

•Group A

•added irrelevant details:• End user desktop apps• Usernames & passwords• Etc.

•Group B

39 hours

20 hours

Page 23: Agile Software Estimation

Extra requirements

•Requirements 1-4

•Group A

•Requirements 1-5

•Group B 4 hours

4 hours

•Requirements 1-5 but told to estimate 1-4 only

•Group C8 hours

Page 24: Agile Software Estimation

Given anchor

•Group A

•Customer thinks 500 • customer has no technical knowledge• Don’t let the customer influence you

•Group B

555 hours

456 hours

•Same as B customer thinks 50

•Group C99 hours

Page 25: Agile Software Estimation

Biased opinion

Page 26: Agile Software Estimation

Dominating opinion

Page 27: Agile Software Estimation

Re estimation is considered heretic by most organizations so we overestimate by buffering

Page 28: Agile Software Estimation

Overestimation downside: Goldratt’s student syndrome

Eliyahu M. Goldratt

Page 29: Agile Software Estimation

Competition, pressure from boss, peer-pressure, optimism bias, etc leads us to underestimate

Page 30: Agile Software Estimation

Underestimating leads to project plan destruction

Page 31: Agile Software Estimation

More bugs

Page 32: Agile Software Estimation

Bad team health

Page 33: Agile Software Estimation

More time in “status” meetings to discuss slippage

Page 34: Agile Software Estimation

Time-based estimates are not additive for a team of varied skill set

Page 35: Agile Software Estimation

What is the source of uncertainty in our projects?

Page 36: Agile Software Estimation

Cloud of uncertainity (if the project is not well controlled)

Page 37: Agile Software Estimation

Control the effects of overestimation and cloud of uncertainty using project planning and status visibility

Page 38: Agile Software Estimation

Other factors influencing estimates

• Unstable requirements• Forgetting to include the following while estimating– Version control overhead– Code review– Build, installing– More meetings– Sick leaves– etc

Page 39: Agile Software Estimation

• Always compare your estimates to your actuals or you’ll never be a better estimator

• Wisdom = Experience + reflection

- Aristotle

Page 40: Agile Software Estimation

Points to remember from Steve McConnell

• Narrow ranges != greater accuracy

• Don’t give off the cuff estimates

• Precision is not accuracy. The project will not take 233.725 hours

• Find something meaningful to count and keep a record of it.

• Use expert judgement only as a last resort

Page 41: Agile Software Estimation

Estimation techniques

• Expert opinion• Analogy• Educated guess• Disaggregating

• Planning poker – Agile estimation

Page 42: Agile Software Estimation

Planning poker• http://www.planningpoker.com/

• Consensus-based estimation technique for estimating

• First described by James Grenningand later popularized by Mike Cohn in the book Agile Estimating and Planning

Page 43: Agile Software Estimation

Planning Poker

• Estimated in story points for user stories* • It is most commonly used in agile software

development• First described by James Grenning in 2002 and

later popularized by Mike Cohn in the book “Agile Estimating and Planning”

• For Eg: the deck contains the following cards: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.

User stories are user requirements of form "As a <Some Role> I want <Some Need> so that <Some Benefit>”

Page 44: Agile Software Estimation

Planning Poker

1. Each person gets a deck of cards.2. The story to be estimated is read to all.3. Attendants ask clarifications for the item.4. Each person selects a card and puts it on the table facing

down.5. When everyone is done, cards are exposed.6. If the estimations do not match a short discussion is done. 7. Timer is started for discussion and discussion must cease

when it runs out -> Goto 4.8. Handle next item.

Page 45: Agile Software Estimation

Why planning poker works ?

• Those who do the work estimate it.• Emphasizes relative estimation• Estimates are within one order of

magnitude.• Reduces anchoring - Everyone's opinion is

heard.• Modeled for open discussion – forces

thinking.• It’s quick & fun !

Page 46: Agile Software Estimation

At the beginning of the project

Use story trawling to prioritize tasks.

Page 47: Agile Software Estimation

How to calculate time?

Time (in no of iterations) = ( No of Story points / Velocity of each

sprint/iteration)

Page 48: Agile Software Estimation

Velocity

• How many points can the team complete in one iteration.

• Easy to measure.• Fixes estimation errors.• Easily reflects the

project status.• Primary parameter in

planning.

Page 49: Agile Software Estimation

How Agile estimation solves common estimation problems?

Page 50: Agile Software Estimation

Assumptions reduced by constant communication

Page 51: Agile Software Estimation

Anchoring is eliminated by not estimating in time but relatively

Page 52: Agile Software Estimation

Cross-functional team while estimating shield from biased opinion

Page 53: Agile Software Estimation

Blind vote and consensus rules out dominating opinion

Page 54: Agile Software Estimation

Daily standup, self-organization and burndown charts reduce affect of overestimation

Page 55: Agile Software Estimation

Estimation is based on team velocity for a sprint, this reduces underestimation

Page 57: Agile Software Estimation

Questions?