Epic Estimation - Agile or High Risk Guesswork

October 2014
Epic Estimation – Agile or High Risk
Guesswork?
Ian Hawkins – Siemens Healthcare
Unrestricted © Siemens 2013 All rights reserved. siemens.co.uk

Epic questions....
 How many people here have been involved in estimation of “epics” as part of
project planning?
 If the work took longer than originally estimated put your hands down.
This talk explores when your Agile project can cope with this uncertainty in
estimation, and when it will kill it.
Unrestricted © Siemens 2014 All rights reserved.
Page 2

First of two simple “mini project” games
1) Pair numbers, by swapping tickets
2) As a group get as many pairs as possible in 2 minutes
3) When you have a pair stand up
2T mim012i:ne03 u0utpe!s
Page 3

Second “mini project” game
1) Order tickets in ascending order (gaps allowed, swapping allowed)
2) Connect everyone up in ascending order in 2 minutes
3) Pass wool along to monitor route
Start2Tmim012i:ne03 u0utpe!s
Page 4

Difference between the two projects
Project 1 - Independent work
each adding value
Page 5
Project 2 – Single large
requirement, all or nothing
 Backlog composition matters – we will return to this later

Structure of talk
 Business context
 Review of one of our projects over 3 successive
years
 Lessons learned and Recommendations
Page 6

Business Context - Siemens Globally
Founded in 1847
370,000 employees
• First electric railway
• First underground railway in continental Europe
• First ultrasound
• First cardiac pacemaker
• First positron emission tomography (PET) scan
• World’s brightest white light emitting diode
• World’s most efficient gas turbine
• World’s longest rotor blade
• etc
Page 7

Siemens Sectors and Divisions
Healthcare Energy
Divisions Divisions
 Imaging & Therapy
 Clinical Products
 Diagnostics
 Fossil Power Generation
 Renewable Energy
 Oil & Gas
 Energy Service
 Power Transmission & Distribution
Industry Infrastructure & Cities
Divisions
 Drive Technologies
 Industry Automation
 Industry Solutions
Page 8
Divisions
 Mobility
 Building Technologies
 Power Distribution

Molecular Imaging
Use of tiny quantities of injected radioactive chemicals to observe live biological
processes.
Page 9

Business Context - Architecture
Siemens Medical
Imaging Platform
Neurology Oncology Cardiology
Page 10
...
Medical Imaging Applications

Software Development Context - Oncology
Page 11
Scrum 1
Scrum 2
Scrum 3
Scrum 4
Planning
Formal QA
(Regulated
Environment)

Planning
- Decision Gates
 Key points where executives decide level of investment
 Commitment to key features required for these meetings
 Uncertainty is not typically discussed
- Fixed dates, as many applications are shipping on common platform
- Fixed resources
Scope – “Commitment Expected”
$$$
Schedule Fixed Resources Fixed
Page 12
Larger investments require greater
expectation of commitments

Planning
- Multiple constraints drive the need for “up front epic estimation”
- So how has this worked in practice...
- We will explore three releases of a project 2012, 2013, 2014 with a focus on the
2013 project
Page 13

Project 2012
- Initial work estimated by architects
- Teams estimated all work in story points (~2 weeks worth of estimation)
- Relatively low number of issues on new features during development
- Scope implemented achieved successfully
Yes – we are all estimation super heroes!
Hmmm – maybe….
Page 14

Project 2013
- Initial work estimated by architects
- More time spent on team estimates in story points (~6 weeks)
- High profile feature - one really large chunk of work including lots of restructuring
of codebase, divided into 3 requirements. Would not fit. Hmm.
- Moved work between teams, reduced scope. More re-estimation. Still
considered too big at 85% of team capacity.
- Previous project went well, same team. Yes we can do it.
Flagged with stakeholders as risk
Page 15

Project 2013 ctd
- Two iterations in. Velocity too low. Is that enough data to be significant?
- Another iteration. Still too low.
- Difficult meetings with stakeholders
 Is there value in delivering two of the three requirements? No, all or nothing.
 Can we back out the 3 months work ok and deliver in 2014 instead?
Fortunately yes.
 Feature extracted out for completion in 2014 project
So what did we learn... ?
Page 16

Lessons learned - change
- There is significant increase in knowledge through a project
- Changes in our project backlog included
- 15% new requirements, 7% removed requirements after initial planning
- Increase in number of backlog items by factor 5 due to elaboration, which
reflects further grooming and understanding
- 5000 updates to backlog item specifications
Page 17

Lessons Learned – Project Uncertainty
- Agile influences the “cone of uncertainty” but does not remove it
Epic
Page 18
Alternate uncertainty curve

Lessons Learned – Making Major Adjustments
- Agile provided fast feedback on progress 
- Ability to back out feature increased options for business
- Allowed sensible re-planning rather than attempting the impossible 
- Painful for business. Handling schedule uncertainty as “risk” is insufficient 
Page 19

Lessons Learned – Backlog Composition
- Not all epics of size say 50 SP carry the same schedule risk
“Delighters” “Essentials”
De-scoping by removing delighters increases schedule risk.
Architectural changes can often be the equivalent of 100% essential features.
Prioritisation is also important, defer higher fidelity until later in project.
Page 20



Lessons Learned – Backlog Dependencies
- Dependency impacts schedule risk
“Independent” “Mutually dependent”
- In “Project 2013” we completed 2 of the 3 features but still could not release.
Page 21



Lessons Learned – Project Control
- Needed to handle project change - do your projects look like this?
Requirements Added
Feature Simplification
Support for other
projects
Estimated 6 months Actual ~6 months
- If you do not have flexibility in your backlog your are in Big Trouble and Agile
won’t be able to help.
Page 22
Integration Issues
Tradeshow
support
Staffing Changes
Tooling
changes

What is hard to estimate? – Six Thoughts
- Why are some epics estimated less well than others?
- Feedback from retrospective and input from 7 other scrum teams
Concern Recommendation
1 Epics with minimal break down
and many story points
Page 23
Increase the amount of slicing
2 Work in areas unfamiliar to team Invite an expert, explore code
and tests
3 Development in areas of lower
quality code
Allow for refactoring and TDD
support

What is hard to estimate? – Six Thoughts
Concern Recommendation
4 Changes that impact lots of
features
Suggest you take the above and customise based on your own teams
experiences.
Page 24
Allow more time for collaboration
and issue fixing
5 Features that are against the
grain of the product
Do a spike, talk to experts
6 Unstable requirements Identify all stakeholders. Initial
changes can be a sign of later
changes.

Project 2014
- So what happened with the epic deferred to 2014?
 Added further experienced staff early on to reduce risk
 Carried out tight project control
 Maintained quality (TDD, Stop the line etc)
 Reached “scope implemented” on schedule
Page 25

Recommendations – In Priority Order
1. Consider shorter release cycles (as advocated by “Lean”)
 Reduces cost of estimation
 Reduces risk for all stakeholders
 Gets value to customers faster
$$$
Page 26
$ $ $
Value
Delivered
Value
Delivered
Value
Delivered

Recommendations
2. Enable Project Control - Epic by Epic
- Compare each epic with historical data to get a base size estimate
- Decide on level of uncertainty/contingency considering
 Historical variation or industry standard variation for phase of project
 Number of matches on your “hard to estimate” list
 Options for varying fidelity
- Do not negotiate the uncertainty or assume you will be lucky...
Page 27
Line in the sand

Recommendations
2. Enable Project Control – Across All Epics
- Check composition of your backlog as well as its size.
One Large Epic, Squeezed In, No Optional Stories
Epic 1 Epic 2 Epic 3 Epic 4 Epic 5 Epic 6 
“Agile works, when you have flexibility in scope”
- Actively discuss uncertainty with management during project planning
Page 28


Recommendations
3) Ensure you have a viable pre-agreed fall-back option
4) Get superhero costume?
Perhaps Not…
Page 29

Resources / Further Reading
Interesting recent studies on
software estimation
Professor Magne Jørgensen
Thanks – Any Questions?
Page 30
http://code.google.com/p/gource/
Still very relevant…
Comments/ideas welcomed - ian.hawkins@siemens.com

Resources
Interesting recent studies on
software estimation
Professor Magne Jørgensen
Thanks – Any Questions?
Page 31
http://code.google.com/p/gource/
Still very relevant…
Comments/ideas welcomed - ian.hawkins@siemens.com

Epic Estimation - Agile or High Risk Guesswork

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Epic Estimation - Agile or High Risk Guesswork

Semelhante a Epic Estimation - Agile or High Risk Guesswork (20)

Último

Último (20)

Epic Estimation - Agile or High Risk Guesswork