Agile Estimating and Planning October, 2013 Technion , Israel

1

Agile Estimating and Planning

October, 2013 Technion, Israel

Prof. Fabio KonUniversity of Sao Paulo, Brazil

[email protected]

2

Non-Agile World

No

PlansExcess of

Plans---------

3

How much to plan

Plan too much is waste

Plan too little = lack of organization/focus

4

Some data from Chaos report(2004)

18%

29%53%

Success

failuresChallenged

5

Chaos report

1994 2004Projects not completed------------ 31%

Projects succedded----- 16%

Avg. budget consumed-----------------------> 280%

Avg. time needed-----------------------> 264%

Projectos not concluded------- 18%

Projects succedded----------- 29%

Avg. budget consumed---------------> 156%

Avg. time needed-------------> 84%

Disclaimer

The Chaos report is not very scientific

Use with caution

Which software to develop?

Never or Rarely

Used64%

TovMeod

36%

Source: Jim Johnson, 2000

Features:

8

Attention!

In real life, you can be sure of only one thing:

things will change and not follow the plan

Be prepared for that!

9

Agile Approach

Individuals and interactions

Working Software

Customer collaboration

Adaptation to change is more important than following the initial plan

- - - x - - -

Plans are nothing; planning is everything

Eisenhower

10

Scope of Agile Planning

Planning Onion

11

Release planning

What to do

• List stories that will be developed

• Select the stories that will be included in the release

• Estimate stories

What not to do

• Assign responsibilities

• Define a sequence

• Create tasks for each story

High-level planning

12

Iteration planning

• Customers, programmers, analysts, designers, etc.

• Identify needed tasks for each story

• Manage tasks using online tool or paper cards

• Estimate each task

• Do not allocate tasks to people (yet)

13

Uncertainty cone

14

Benefit of (good) Estimates

Reduce risk

Reduce uncertainty

Help in decision making

Establishes trust

Transmit information/knoweledge

15

Why plans fail?

Planning is done task by task and added up Activities are not independent

Delays add up

Activities are never completed before the deadline Parkinson law (1993)

Many tasks in parallel decrease productivity Features are not developed in order of priority Uncertainty is normally ignored Estimates become commitments

16

Preparing to estimate

Avoid false precision

Define a scale, e.g.: 1, 2, 3, 5 and 8 0, 1, 2, 4 and 8 10, 20, 30, 50, and 100

Identify Stories, Themes, and Epics

17

Let’s estimate!

Size is different from Duration

1

1

2

22

2

4

4

4

4

8 16

16

2 Total = 58

18

Estimating

• with Points

– Relative estimates

– Abstract

– Measures size of effort (must be converted to time)

• with Ideal Work Days

– Easier to explain

– Concrete

– My favorite when doable

19

Why ideal ≠ real

Meetings Bug fixing Special projects Support Demonstration Training Revisions

Interviews Task switching Phone calls E-mails Personal issues Sicknesses Extraordinary boss

requests

1 real day = α ideal day, 0 < α < 1

20

How to estimate

Major techniques: Expert opinion analogy Divide and conquer

Major problems: Availability of expert Estimator is not developer Estimate by feature and not by task

Solution: Planning Poker

21

Planning Poker

22

Estimating Velocity

Based on history / previous experience

Carrying out 1 iteration

23

First Plan

The first iteration is likely to be very wrong.

Don’t worry, learn, and adapt, correct your estimates.

… at least, the 1st iteration is done only once ;-)

24

Protection against uncertainty

Always add a buffer!

Lag in schedule

Buffer in estimates

Buffer in features

25

Scheduling

Prioritize based on Business Value

Consider: Financial value of the functionality Cost of development and maintenance Development time Amount of learning and knowledge offered by the

new feature Amount of risk eliminated after developing the

functionality Technical dependencies

26

Value and Risk

High

High

Low

RISK

Value

Avoid

Do Last

Do First

Do Second

27

Prioritizing Customer Desires

Kano Model for Customer Satisfaction

Required features

Aggregating features

Surprising features

28

Project Monitoring

Estimates will be very wrong in the beginningWill get better as team become more experienced

It’s important to monitor progress to: Know where you are Learn and then estimate better

29

Release Burndown Chart

30

Release Burndown Bar Chart

31

12 Rules for Planning with Agility (I)

1. Involve the whole team

2. Plan in multiple levels

3. Keep size and time estimates separate (optional)

4. Consider uncertainty for features and dates

5. Replan frequently

6. Track and advertise progress

32

12 Rules for Planning with Agility (II)

1. Be aware of the importance of learning

2. Work with features of the right size

3. Prioritize features

4. Base your estimates and plans in facts

5. Not plan for 100% of the time (buffer, ideal work day)

6. Coordinate planning to avoid dependencies

33

Questions

Fabio Kon

[email protected]

University of São Paulo, Brazil

Bibliography:

Agile Estimating and Planning. Mike Cohn. Pearson Education. 2005.