epic estimation - agile or high risk guesswork

Unrestricted © Siemens 2013 All rights reserved. siemens.co.uk

Epic Estimation – Agile or High Risk

Guesswork?

Ian Hawkins – Siemens Healthcare

October 2014

Unrestricted © Siemens 2014 All rights reserved.

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.


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

2 minutes2:001:301:000:30Time up!


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

Start2 minutes2:001:301:000:30Time up!


Difference between the two projects

Project 1 - Independent work

each adding value

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


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


Healthcare Energy

Infrastructure & CitiesIndustry

Siemens Sectors and Divisions

Imaging & Therapy

Clinical Products

Diagnostics

Divisions Divisions

Drive Technologies

Industry Automation

Industry Solutions

Divisions

Mobility

Building Technologies

Power Distribution

Divisions

Fossil Power Generation

Renewable Energy

Oil & Gas

Energy Service

Power Transmission & Distribution


Molecular Imaging

Use of tiny quantities of injected radioactive chemicals to observe live biological

processes.


Business Context - Architecture

...

Medical Imaging Applications

Oncology CardiologyNeurology

Siemens Medical

Imaging Platform


Software Development Context - Oncology

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

$$$

Schedule Fixed Resources Fixed

Scope – “Commitment Expected”

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


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….


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


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... ?


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


Lessons Learned – Project Uncertainty

- Agile influences the “cone of uncertainty” but does not remove it

Epic

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


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.


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.


Lessons Learned – Project Control

- Needed to handle project change - do your projects look like this?

- If you do not have flexibility in your backlog your are in Big Trouble and Agile

won’t be able to help.

Estimated 6 months Actual ~6 months

Requirements Added

Integration Issues

Feature Simplification

Tradeshow

support

Support for other

projectsStaffing 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

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

Suggest you take the above and customise based on your own teams

experiences.

Concern Recommendation

4 Changes that impact lots of

features

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


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

$$$$ $ $

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...

Line in the sand


Recommendations

2. Enable Project Control – Across All Epics

- Check composition of your backlog as well as its size.

“Agile works, when you have flexibility in scope”

- Actively discuss uncertainty with management during project planning

One Large Epic, Squeezed In, No Optional Stories

Epic 1 Epic 2 Epic 3 Epic 4 Epic 5 Epic 6


Recommendations

3) Ensure you have a viable pre-agreed fall-back option

4) Get superhero costume?

Perhaps Not…


Resources / Further Reading

http://code.google.com/p/gource/

Still very relevant…

Comments/ideas welcomed - [email protected]

Thanks – Any Questions?

Professor Magne Jørgensen

Interesting recent studies on

software estimation


Resources

http://code.google.com/p/gource/

Still very relevant…

Comments/ideas welcomed - [email protected]

Thanks – Any Questions?

Professor Magne Jørgensen

Interesting recent studies on

software estimation

epic estimation - agile or high risk guesswork

Software

ukunrestricted siemens

agile project

value project

project planning

estimation of epics

mini project gameorder

diode worlds

epic questions