Post on 23-Dec-2015
1
Agile Estimating and Planning
October, 2013 Technion, Israel
Prof. Fabio KonUniversity of Sao Paulo, Brazil
kon@ime.usp.br
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
kon@ime.usp.br
University of São Paulo, Brazil
Bibliography:
Agile Estimating and Planning. Mike Cohn. Pearson Education. 2005.