1. Agile estimations and
Planning
Cornel FATULESCU
agile coach

2. Did It Ever Happen to You?
• Who the ... made this estimation?
• Sorry it will take me than … hours!
• I hope we’ll deliver tomorrow.
• I can’t tell you how much time it will take!
• We don’t have time for testing
• …
2

3. Usual solution
3

4. Classical IT services supplier scenario
4
Sales Start-up
Ongoing
project
Some
experts
Some members
of newly created
team
The team
Basic
knowledge
Some
knowledge
might be lost
Grooming
sessions
Release
Planning
Capitalize
RFP
Knowledge
DoR DoD
Estimations
Initial Release
Planning
Product Vision
Initial Backlog
Goals
Problem 1
How to
estimate
features?
Problem 2
How to
plan?

5. How to estimate features ?
• What does the team need for each feature in
order to increment it?
• How features become part of the increment?
• Estimate the features!
5
Definition
of Ready
Definition
of Done
Relative
Estimations

6. Feature metamorphosis flow!
6
Suggestion Assumed Estimated Ready In Progress
Pre-
Production
Production
Done

7. Feature metamorphosis flow!
7
Suggestion Assumed Estimated Ready In Progress
Pre-
Production
Production
Done
? ? ? ?
Release
Planning
End of Release
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
……
… …
…

8. Sample of Definition of Ready for a feature
8
Story clarified
Tasks identified
Story estimated
Acceptance criteria
Clear dependencies
Scrum Team accepts the story
Responsible for acceptance
User story complies INVEST rules
…

9. Sample of Definition of Done for a feature
9
Design complete
Development complete
Code commented
Static code quality analysis
Unit testing is done
Code Refactoring
Code checkin
Continuous build
Tests
Documentation Ready
Peer reviews
Jira is updated
Story is accepted

10. Why relative estimations?
• Product Owner: How long it will take to
deliver feature A?
• 1st team member : 3 Days
• 2nd team member: 6 Days
10
Both
estimations
might be
right!

11. Why relative estimations?
• Product Owner: How long it will take
Compared to feature B we’ve done the last
time?
• 1st team member : 3 times more
• 2nd team member: I agree, 3 times
more
11

12. Measure the size, calculate the time
12
Velocity =
𝛥𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒
𝛥𝑡𝑖𝑚𝑒
𝛥𝑡𝑖𝑚𝑒 =
𝛥𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒
𝑣𝑒𝑙𝑜𝑐𝑖𝑡𝑦

13. Measure the size, calculate the time
13
Velocity =
𝛥𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒
𝛥𝑡𝑖𝑚𝑒
𝛥𝑡𝑖𝑚𝑒 =
𝛥𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒
𝑣𝑒𝑙𝑜𝑐𝑖𝑡𝑦
http://www.mountaingoatsoftware.com/blog/its-effort-not-complexity

14. It’s effort, not complexity
14
“In a class a few years back, I was given a wonderful
example of this. Suppose a team consists of a little
kid and a brain surgeon. Their product backlog
includes two items: lick 1,000 stamps and perform a
simple brain surgery–snip and done. These items
are chosen to presumably take the same amount of
time. If you disagree, simply adjust the number of
stamps in the example. Despite their vastly different
complexities, the two items should be given the
same number of story points–each is expected to
take the same amount of time.”
-Mike Cohn
http://www.mountaingoatsoftware.com/blog/its-effort-not-complexity

15. Visualize the estimations
15
To
estimate
Feature 2
Feature 5
Feature 6
Feature 7
Feature 8
Feature 9
Feature 11
1 SP
Feature 1
Feature 43
Feature 32
Feature 21
Feature 23
2 SPs
Feature 3
Feature 4
Feature 18
3 SPs
Feature 10
Feature 88
5 SPs
Feature 13
Feature 15
8 SPs
Feature 22
5 SPs 6 SPs 6 SPs 10 SPs 8 SPs35 SPs

16. How to plan?
16
Our
concern?
Release
Planning
Process
Sprint
DoR, DoD
Release
DoR, DoD

17. What is release planning?
17
• It is a process not an event!
Release Planning
at project
start-up
Sprint 1 Sprint 2 Sprint 3
Through
Grooming
Sessions
In Scrum no
more than
10% of the
Sprint
Usually more
effort needed
than in a sprint

18. Sample of Definition of Ready for a sprint
18
Sprint goal
The Sprint Backlog is prioritized
No hidden work
Calculated capacity
Team accepted the Sprint Backlog
All stories meet definition of ready
List of stories for regression testing

19. Sample of Definition of Done for a sprint
19
Release Build
Functional testing done
Regression testing done
Acceptance testing done by the Product Owner
Closure

20. Sprint Context
20
Team size
Focus factor
Sprint size
Calendar days
Velocity
6 People
70%
2 weeks
10 Days
16 SPs

21. Estimate 1 SP
21
• Estimate in hours several features
– Ex: Feature 1
• Estimated initially at 3 SPs
• Estimated in man days at 6 days
• =>1 SP = 2 days
• Ask the team directly how they evaluate 1SP?
• Experience and measure

22. Calculate Sprints Velocity
22
Sprint 1 Sprint 2 Sprint 3
Person days in sprint = calendar days *
team size
60 60 60
Ideal person days in sprint = person days
in sprint * focus factor
42 42 42
Sprint ideal man days
1st sprint = (1-40%) * ideal person days
2nd sprint = (1-20%) * ideal person days
3rd sprint = ideal person days
25 33 42
Velocity = Sprint ideal man days/1 SP 16 22 28
Team size Focus Factor Sprint Size Calendar
Days
1 SP?
6 70% 2 weeks 10 Days 1.5 Man Days

23. Simulate sprints
23
Backlog
5 SPs
3 SPs
8 SPs
13 SPs
1 SP
2 SP
1 SP
Sprint 1
3 SPs
1 SP
1 SP
5 SPs
2 SPs
2 SPs
1 SPs
Sprint 2
5 SPs
3 SPs
5 SPs
2 SPs
5 SPs
2 SPs
Sprint 3
3 SPs
5 SPs
3 SPs
5 SPs
1 SP
5 SPs
2 SPs
5 SPs
…
1st Sprint
Velocity 16
SPs
2nd Sprint
Velocity 22
SPs
2nd Sprint
Velocity 28
SPs

24. Measure and re-estimate 1 SP?
24
• Ex: 1st sprint estimated at 16 SPs velocity
– After execution we deliver 12 SPs
– Do reverse calculations from the previous slides
Sprint 1 Sprint 2 Sprint 3 1 SP?
Before starting 1st Sprint 16 22 28 1.5
After 1st Sprint 12 16 21 2
After 2nd Sprint 12 16 21 2

25. Criteria for ordering the backlog
25
• 1st The risk which the story should diminish
• 2nd The uncertainty on client needs which the
story should reduce
• 3rd The contribution to the product quality
• 4th The dependencies between stories
• 5th The utility of a story

26. Dealing with uncertainty
26
Demo inspired from
http://blog.bobcravens.com/2011/05/4-
principles-to-estimation-applied-to-software-
development/

27. Estimate how long will the walking take?

28. Walking from Iasi to Bucharest
28
• Distance Iasi – Bucharest = 417 km
• Average walking velocity = 5.0 (km/h)
– http://en.wikipedia.org/wiki/Walking
• We estimate walking 8 hours per day
• ~ 10.5 days of walking from Iasi to Bucharest

29. Walking from Iasi to Bucharest
29
• Initial uncertainty is probably in hours or days

30. We walk from Iasi to Roman

31. Walking from Iasi to Bucharest
31
• Distance Iasi – Roman = ~86 km
• Real walking velocity = 4.0 (km/h)
• We’ve walked 6 hours per day
• ~ 3.6 days of walking from Iasi to Roman

32. Estimate from Roman to Bucharest?

33. Walking from Roman to Bucharest
33
• Distance Roman – Bucharest = ~331 km
• Estimated walking velocity = 4.0 (km/h)
• Estimated walking hours per day = 6
• ~ 14.8 days of walking from Roman to
Bucharest
• Initial cycle time = 10.5 days of walking
• Total cycle time = 18.4 days of walking

34. Burn-down chart Iasi-Bucharest
34

35. What about agile planning poker?
35
• The most common estimation method known
in the agile community
• The interest is in the discussions

36. What about agile planning poker?
36
• The most common estimation method known
in the agile community
• The interest is in the discussions

37. Estimation issues hide higher problems!
37
-10
0
10
20
30
40
50
60
D1 D2 D3 D4 D5 D6 D7 D8 D9 D10
RAF
Ideal RAF

38. Sprint Backlog
38
1st Story 13
2nd Story 13
3rd Story 8
4th Story 8
5th Story 13

39. Observed issues
39
• Just technical stories/no user stories
• Stories didn’t correspond to INVEST criteria
• Waterfall approach in iterations
• Lack of Definition of Ready
• Definition of Done was not respected
• …

40. Start from the need of information
40
• Clients want to know when it will be ready,
the budget…
– Ex: Continuous pulling systems like Kanban
=>use average Cycle Time instead
• TODO in another knowledge sharing session!

41. Cornel FATULESCU
agile coach
Planning is Everything. Plans are Nothing.
- Helmuth von Moltke