Presentation Nesma Autumn Conference 2018

1. Esteban Sanchez
Galorath Incorporated

2. About The Speaker
 Born and raised in the tropical
Costa Rica
 Senior Cost Estimation Consultant
at Galorath Inc.
 Works with customers around the
world to estimate Software,
Hardware and IT Projects

3. Outline
 Background
 Agile Estimates – Are they necessary?
 Types of Estimates
 Size Metric for Agile Project
 Story Points or Function Points?
 How about both?
 Variables (Team Size, Sprint Duration, Velocity)
 More on Velocity – Industry Standard Velocity
 Sprint 0
 Back-End Integration and UAT
 The Complete Agile Estimate

4. In the Beginning…
The Cone of Uncertainty Gave Visibility to Cost Risk!

5. Jump into the Time Machine… 2001
The Agile Manifesto was
conceived as collection of
loose, iterative, customer
centric development
methods…
- Agile -
… and the difficulty of estimating Agile began!

6. Agile Estimation Shouldn’t be More Difficult
It’s Just Another Methodology
ROM Detailed Estimate
Maximum
Uncertainty
Evolving
Complexity

7. Agile Estimates – Are they necessary?
 #NoEstimates
 Estimates are difficult to produce
 Provide little to no value
 Estimation is overhead and should be minimized
 #Estimates
 Organizations need to do budget planning
 Estimates are needed to make informed decisions
 CXOs need estimates for accountability to
shareholders
Social Networks have created discord around Agile
Estimates…

8. Parametric Modeling sustains the
#Estimates argument
 Extensive Research on Agile
Estimation
 Field Experiences Working
with Customers
 Best Practices Proven to be
Meaningful and Beneficial
 Sizing Methods
 Processes
 Training
 Tools (SEER-SEM Agile
Planner)

9. Agile Estimates have Differing Fidelity
 Backlog Estimate
 ROM
 One Estimate for the
Entire Project
 Useful for High Level
Analysis and Budget
Planning
 Can be built early with
limited information
 Sprint Estimate
 Detailed
 Estimates are generated
at the Sprint Level
 Useful for Team Planning
and Tracking
 Considers all information
(Velocity, Team Size,
Sprint Duration )

10. Backlog Estimate = Big PictureFeatures
Project
Characteristics
Team
Dynamics

11. Sprint Estimate = Delivery DetailFeatures
Project
Characteristics
Team
Dynamics

12. Size Continues to be the
Main Driver
Pick a Metric and
Be Consistent!
Function Points
Use Cases
T-Shirt Sizes

13. Project Characteristics
 What is it running on?
(Cloud, PC, Mobile, etc.)
 What will it do? (CRM,
Database, Embedded)
 What Agile Method?
(SCRUM is the most widely
used)
 How will you build it? (New,
Modification, Rehost)
 How much Governance?
(IEEE, ISO 9001, etc.)
@Galorath we call these
Knowledge Bases

14. Team Dynamics
Development
Team Size
• Optimal Size can
be calculated
• Everyone
available on day
1?
Backlog Size
• What is the team
tasked to
complete?
SPRINT Duration
• Timebox duration for an iteration
• 4 and 2 weeks are the most common
Team Velocity
• What is “doable”
in a SPRINT
• If not known, it
can be computed
(discussed in
slide 20)

15. What About Story Points?
 Advantages
 Easy to Use
 No Training Required
 Promotes cross-functional behavior (teams can compare similar
things)
 Current Trends
 People questioning their usefulness
 Challenges
 Not Standard/Team Specific
 Difficult to Explain
 Difficult (maybe impossible) to Benchmark
 They are started to be abandoned
 Story Points Inflation

16. Quest for Productivity Measurement
Induces Inflation
250
225
200
175
150
125
100
75
50
25
0
StoryPoints
Sprints
Project Monitoring Begins
This is what happens when you don’t have a standard
sizing metric, like Function Points 

17. Story Points Must be Tempered by a
Standard Metric – Galorath Approach
 Function Points (or SLOC) used as the Underpinning
Metric
 Team Variance in Story Points must be accommodated
 A FP Counter must understand the Agile Team
“Standards” to normalize the count
 Final Estimate will reflect the Team Specific Productivity

18. How it Works

19. Same Point Counts - Different Results
Same Story Point Counts
Different Teams
Different Estimates
715 FPs310 FPs
Team A Team B

20. Agile is all about Velocity
Sprint X
Staff = 5 People Duration = 4 Weeks
Effort = 800 Hours Cost = $120K
So, what is the Product Owner getting?

21. Given a Velocity… what can we deliver
for any given project type?
 Velocity = Commitments for the Sprint
 Velocity is a metric of Software Size/Sprint
 It is not magic, it can be predicted
 Industry Data provides a predictive model for productivity
20
FPs/Sprin
t
87
FPs/Sprin
t
We call this “Industry Standard Velocity”
Productivity

22. Computing the Number of Sprints
 The number of Sprints drives the estimated Cost and
Duration
Backlog Size = 540 SPs
Velocity = 90 FPs/Sprint
Voila, We have an Estimate!!!

24. Industry calls this “Sprint 0”
 The work before the Project
can start
 For example: Planning and
Setup
 We believe Sprint 0 should be
estimated
 Duration/Effort may be
More/Less Than a Typical
Sprint
SPRINT 0
Env.
Setup
Team
Setup
Backlog
Plan

25. Back-End Work
 Typically, some work needs to be done after you are
done “Sprinting”
 Final System Level Integration
 User Acceptance Testing
 Final Check-out and Certification
 Warranty/Maintenance
 The Estimate would NOT be Complete if this is
Ignored
 Should be Estimated Based on the Overall Backlog
Size

26. The Complete Agile Estimate
 Full Estimate Including:
 Pre-Sprint Work (Backlog
Planning, team Setup, Env.
Setup)
 Sprint Iterations
(Design/Code/Test)
 Back-End Work (SIT, UAT, etc.)

27. Our Journey Continues…
 At Galorath we have performed extensive research
and worked collaboratively with an international
customer base to understand their estimation needs
in an Agile Environment
 All knowledge has been incorporated into the new
Agile Planner capability in SEER-SEM
 The journey is just starting… We will continue to
make and offer improvements based upon our on-
going research, staying abreast of industry trends
and listening to the voice of the customer

28. Gracias!
Thank You!
Bedankt!
Grazie!
Spacibo!
Merci!
Danke!
धन्यवाद!