Evm+agile (8.8).chapter 9

+

Integrating Agile Software Development (Agile) on Earned Value Management ProgramsStarting with an EIA–748–C compliant Earned Value Management System, integrating an Agile Software Development Lifecycle (Agile) is straight forward when there is a Bright Line between the Performance Measurement Baseline (PMB) and the Sprints and Tasks of the Agile Software Development Process.

AGILE AT SCALE

forFAR 34.2 / DFARS 234.2Acquisition Programs

V8.8

1

Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2016

+

Performance–Based Project Management®

is a registered trademark of Niwot Ridge, L.L.C.Performance–Based Project Management ® ISBN 978–0–8144–3331–7

is a publication of American Management Association, Copyright © 2014

CMMI® is a Registered Trademark of Carnegie Mellon University, Pittsburg, PA

All material in this document is Copyright © 2002 - 2016Glen B. Alleman, Niwot Ridge L.L.C.

This publication may not be reproduced, stored on a retrieval system, or transmitted in whole or in part, in any form or by any means, electronic,

mechanical, photocopying, recording, or otherwise, without prior written permission from Niwot Ridge L.L.C.

Send requests for reuse to [email protected]

2


+Table of Contents

§ Content Page1 Introduction 62 Opening Background 523 Start With The End in Mind 1334 Framing Assumptions 1465 Foundations of Earned Value and Agile 1876 Performance Planning and Measurement 2147 Connecting the Dots Between Agile and EVM 2538 The Requirements Elicitation Problem 2989 Planning, Estimating, and Budgeting 31410 Building the PMB for an Agile Project 34611 Dependency Management in Agile 37412 Risk Management on Agile Programs 38013 Change Control in Agile and EVM 41714 Physically Connecting the Dots 47415 The Dark Side and EVM and Agile 48416 Failure Modes of Agile + Earned Value Management 50217 Maturity Models for Agile and Earned Value Management 55418 Root Cause Analysis 51819 Agile Contracts 64520 Conclusion 64621 Resources 665

3


+

Earned Value provides EAC and ETC for large software intensive systems. Agile provides mechanisms for emergent software development

Why Agile + Earned Value Management?


4

Navigation

Communications

Fire Control

Engine Controls

Counter Measures

Visualization

Flight Controls

+9. Planning, Estimating and

Budgeting in AgileIn Agile, Story Points are used as measures of effort. In Earned Value there is no concept of Story Points, rather Dollars and Hours are the measures of effort and duration for the work.When using Agile on EVM projects, each unit of measure has value to the benefits produced through the integration, IF there is a proper segregation of these concepts.

Estimating is a Critical Success Factor for Increasing the Probability of Program Success

315Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2016

Estimating develops the confidence intervals for possible outcomes (cost, schedule, deliverables) of the work in the

presence of reducible and irreducible uncertainties.

Estimating provides informed assessments of uncertain events or statistical processes. All projects are impacted by these

Uncertainties

9. PB&E


+

Planning

n Product Road Map ‒ A product roadmap describes how the product grows to aligns with the stakeholders needs, and to acquire a budget for the product.

n Epic Plan ‒ Epics are feature-level work that encompasses many user stories. Epics are almost always delivered over a set of sprints.

n Release Plan ‒ is a plan for delivering an increment of product value. It is a collaborative effort involving scrum masters, product owners, delivery teams, and stakeholders.

n Sprint Planning ‒ is a plan to achieve a specified level of functionality and meet additional specific criteria with a particular Sprint of a system.

Planning is Strategy Making. Strategy Making is a hypothesis.Hypotheses require tests to confirm the project is moving in the desired direction.

Project planning is an important basis for cost estimating. An accurate plan will provide an accurate cost estimate. Proper planning will reveal tasks, durations, resources required and other factors that will be taken into account during the cost estimation process.

Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2016 317

9. PB&E

In Preparing for Battle I Have Always Found Plans are Useless, But Planning is

Indispensable


9. PB&E

318

+Product Roadmap


319

9. PB&E

+Epic Planning


320

9. PB&E

+Release Planning


321

9. PB&E

+Sprint Planning


322

9. PB&E

+

Sprint Plans

Release Plans

Release and Sprint Planning†

† Agile Estimating and Planning, Mike Cohn, Pearson Education, 2006

Conditions of Satisfaction

(Stories, Budget, Schedule)

Release Planning

Conditions of Satisfaction

(Stories, Budget, Schedule)

Sprint Planning DevelopmentStories

Completed

9. PB&E

323


+

Principles of Agile Estimation

n Reducible Uncertainty ‒ the event based (probability of occurrence) outcomes that have unfavorable impacts on the work

n Irreducibility Uncertainty – the naturally occurring variances in the work processes, technologies, and outcomes

n Estimating in the presence of uncertainty ‒ requires identifying both reducible and irreducible uncertainties and assessing the risks they create

For all projects, no matter if they are Agile or Traditional, estimates are critically important.

Estimates are needed to make decisions in the presence of the uncertainties encountered by the project participants and management


9. PB&E

+

Estimating about unraveling the interconnections between Cost, Schedule, Risk, and Technical Performance to produce a credible estimate of how long, how much, and what will be produced from the project. Then use these estimates in a Close Loop control system to increase the Probability of Success

Estimating is Not About Guessing


325

+Why Estimate on Agile Programs?

n All project work is random, even on fixed periods of performance, with fixed resources, and fixed scope.

n What are the irreducible uncertainties for each work activity that will unfavorably impact the probability of success when they come true?

n Estimates for Cost and Effort of each Release and Sprint n It is essential to know the cost and effort of the release before the project

committed to the Customer.

n Estimates of Demand and Capacity Management.n Demand management and capacity planning is a critical success factor for all

projects. Agile projects are no different.

n Estimating the Cost of the Minimal Marketable Features is needed before committing to their development.n Without knowing this cost to some level of confidence jeopardizes the

production of the needed value of the deliverable

9. PB&E

326


+ A Cardinal and Ordinal Interlude to Address the Estimating Problemn When we use a measure of something we

need to know if it is Cardinal or Ordinal.

n Ordinal measures tell us the relative difference between items. n Uncle Scrooge is relatively rich compared to

Huey, Dewey, and Louie is an Ordinalmeasure.

n Cardinal measures is a number that says how many of something there are, such as one, two, three, four, five.n Uncle Scrooge has $1,250,000,000 dollars of Gold

n In Earned Value Management we use Cardinal numbers, measured in Dollars and maybe Hours.

n Story Points are not a unit of measure used in Earned Value Management.

9. PB&E

327


+ Estimating is Required on all Programs in the presence of Uncertainty

n EVM estimatingn Basis of Estimate (BOE) at Proposal flowed to PMB then to Control

Accounts and Work Packages.n Hours and Dollars are Cardinal units of measure for all EVM activitiesn EVM Estimating connects Bottom Up and Top Down confirming the

proposal’s Basis of Estimate.

n Agile estimatingn Story Points for Backlog work flowed from Work Packages delivering

Features to Sprints and Tasks.n Story Points are Ordinal units of measure creating relative effort measures

mapped back to BCWS assigned to the Feature in the Work Package.n Agile Estimating is Bottom Up in the Story Point Assignment processes.

The Story Point is a relative measurement of how difficult a task is. This is because humans are actually better at relative estimates than precise measurements. But the Story Point is NOT Scope

9. PB&E

328


+ Two Very Different Meanings of the Word Estimation†

n Sprint level: Decide which stories to commit to defining in detail and developing in the next sprint (which is a fixed length). n Often referred to as “agile estimation” in the literature

n Project Release level: Estimate the time and cost of a project to develop software that meets chosen business goalsn Help decide what projects to do. n In some cases, estimating how much functionality can be developed to meet a fixed

deadline.

n Purpose of each Sprint is to get feedback to do course corrections and learnn Stories were broken down into “developer sized bites” that fit into the sprint. Not all of a

higher-level function must be completed

n Not all the functionality needed to consume and use the software is ready at each sprint. “Highest priority that fits” is not enough for production use

n Only over multiple Sprints will the functionality be enough to serve a business purpose for the users – You can’t arbitrarily decide on a time box for that!

† Agile Estimation: Beyond the Myths Part 2 Andy Berner Quantitative Software Management, Inc.

9. PB&E

329


+

Estimating work for the Sprint

n Capacity Base Planning – the team performing the work determines what their capacity for work is by examining the Stories assigned to the Sprint from the Product Backlog

n Velocity Based Planning – the team uses their past performance in Stories points to assess what Stories to pull from the Product Backlog for the next Sprint.

n This historical data is used to forecast future work performance

n In eXtreme Programming this is called Yesterday’s Weather

There are two primary ways to Estimate work at the Sprint Level

9. PB&E


+Story Points …

n Are measures of Relative work effort – not duration or actual cost.

n Story Points are NOT a measures of the cost of scope either.

n Story Points are Ordinal units of measure – relative measures

n Hours are measures of effort as well.

n Hours also are a measure of Scope:n From the SOW, each deliverable is assigned a budget BCWS starting at

the proposal BOE’s.n From the labor rate, that BCWS can be converted to Hours of effort as well

as material costs.

n BCWS are Cardinal units of measure – absolute measures, uniformly applicable across the program – Dead Presidents.

Agile + Engineering Practices: Experiences of Three Microsoft Teams, Laurie Williams North Carolina University, Gabe Brown, Adam Meltzer, Nachiappan Nagappan, Microsoft Corporation

9. PB&E

331


+Story Points …

n Are arbitrary measures used by Agile teams to determine the Relative (Ordinal) effort of the work.

n Tell the team how hard a Story is, from it’s perceive complexity, risk, unknowns – each related to effort.

Agile + Engineering Practices: Experiences of Three Microsoft Teams, Laurie Williams North Carolina University, Gabe Brown, Adam Meltzer, Nachiappan Nagappan, Microsoft Corporation,

n All these Relative (Ordinal) measures are the antithesis of Earned Value Management measures of work planning and accomplishments, which are in Hours for the direct labor needed to produce the outcome (assuming no material cost).

9. PB&E

332


+Story Points Don’t …

n Tell us the duration or cost of this relative effort.

n Tell us the absolute effort to performance the work

n Aren’t normalized across work efforts, across teams, or across the programn Story Points are developed through Planning Games or Planning Poker

for the work in hand

n Story Point effort estimates are not Calibrated across the program, but rather are developed for the work at hand

n The calibrated units of measure for Story Points – can and will change –change as the program progresses.

Agile + Engineering Practices: Experiences of Three Microsoft Teams, Laurie Williams North Carolina University, Gabe Brown, Adam Meltzer, Nachiappan Nagappan, Microsoft Corporation

n Hour and Dollar estimates will change as the program progresses as well, but the unit of measure representing this estimate does not.

9. PB&E

333


+The Killer Issue with Story Points

n What is a Story Point Worth in Dollars in the IPMR per DID–81861?

n What is a Story Point Worth in Hours of duration in the IMS?

n Can we Calibrate Story Points across the entire program? That is, are Story Points a constant representation of Effort across all planned Tasks, Work Packages, and Control Accounts?

n The Killer issue with Story Points is they are a relative measure of effort, not absolute measure of effort.

n Performing schedule analysis, Estimate to Complete, Estimate At Completion, variance analysis, margin erosion, and other time and cost assessment is not possible in Story Points

9. PB&E

334


+ How Ordinal Story Points at the Feature Level can be Turned into P%C

n Story Points are assigned to Stories contained in a Feature by a unified team of Agile Estimators.

n The assigned SP’s can then meet the BCWS flowed down from the Work Package for that Feature.

n This connection can then be used to status the feature as Physical Percent Complete, and convert that P%C into BCWP.

n But those Story Points can’t be extended across Features, UNLESS those developing the Story Point estimate use the same basis of estimate:n Story Points are relative measures of effort.

n If different teams assign Story Points, its like they will have a different calibration paradigm for that effort.

9. PB&E

335


+ Rolling Up Agile Story Points across the Program is Bad Idean Agile teams rarely produce comparable calibrated Story Points for dissimilar or

even similar work.

n This is a key difference between EVM and Agile. Most EVM shops have an external Basis of Estimate process to calibrate the cost and duration of planned work

n Agile teams working on different parts of the project, with different assessments of Effort, different Story point values, and different project costs result in dissimilar units of measure for a Story Point.

n When Agile teams have different approaches to applying Story Points, Earned Value can still be calculated for each team, and rolled up to the Total Story Point count for the project for an individual Feature Physical Percent Complete.

n The program level BCWS flowed down from the CBB to the Control Accounts and Work Packages can then be connected with the Total Story Point count built bottom up from the Agile Planning process.

n From there, all EVM calculations remain the same, with the caveat that the Actual Cost needs to be the actual cost across teams to calculate a total CPI across a program.

9. PB&E

336


+ Ordinal Story Point cannot be basis of BCWS higher than a Feature

Feature 1

Story

Story

Story

Story

Story

Story

Team 1’s Uncalibrated Ordinal SP estimates

Feature n

Story

Story

Story

Story

Story

Story

Team 2’s Uncalibrated Ordinal SP estimates

∑ F1(SP) ∑ Fn(SP)

Release 1 ∑ of SP’s

• • •

§ At the Story level, relative effort defines individual estimates.

§ At the Feature level, lower level SP’s don’t have the same unit of measure in the way Dollars do.

§ When Features summed to the Release, relative measures do not provide basis of Physical Percent Complete.

Not same units of measure between Features – Uncalibrated SP’s

9. PB&E

337


+When to Assign Story Points

n The PMB’s WBS defines the Program Level Control Accounts with BCWS, flowed to the Work Packages just like it shows in the NDIA Gold Card.

n Story Points are used to estimate the relative effort of the work at the Task level, rolled to the Story, and then to the Sprint.

n Dollars and Hours are used to estimate the effort and duration of the work at the Work Package level, rolled to the Control Account.

n Story Points need to be assigned early in the program planning, in the same way BCWS is.

n Putting Story Points on product Backlog during sprint planning is too late.

n The BCWS and Story Point estimates Meet at the Bright Line between the PMB and the Agile Backlog, Sprint, and Release plan

https://www.mountaingoatsoftware.com/blog/assigning–story–points–at–the–right–time–or–not–at–all

9. PB&E

338


Estimating ‒ in Story Points, Hours, or any units of measure ‒ is Not a process of chance. It is the process of determining the range of a value of interest with a desired precision and accuracy needed to make a credible decision out an outcome in the future associated with that value.


9. PB&E

+Capacity Based Sprint Planning (1)†

n The Product Owner brings the top-priority Product Backlog items into the meeting and describes them to the team, usually starting with an overview of the set of high-priority items.

n Team members select a first item to bring into the sprint ‒ which is almost always the Product Owner’s top-priority item, but it is possible that the Product Owner’s top priority has too many open issues.

n After selected a high-priority item, team members discuss the work involved, and identify the tasks necessary to deliver the Product Backlog item.

n Either concurrent with identifying the tasks or immediately after they finish doing so, team members roughly estimate the number of hours each task will take.

9. PB&E

340


+Capacity Based Sprint Planning (2)†

n After identifying the tasks and roughly estimated the hours for that one Product Backlog item, the team members ask, “Can we commit to this?”

n Repeat this process with more Stories from the Product Backlog, until the answer to the question “Can we commit to this?” is NO.

n There has been no role for Story Points or velocity in this commitment process. Either the Story can be committed to be done in this Sprint or it can’t ‒ the team decides.

It’s a Commitment, Not a Guarantee“If you want a guarantee, buy a

toaster.”‒ Clint Eastwood

9. PB&E

341


+Velocity Based Sprint Planning (1)†

n Velocity sprint planning is based on the premise that the amount of work a team will do in the coming sprint is roughly equal to what they’ve done in prior sprints.

n This does assume, of course, things such as a constant team size, the team is working on similar work from sprint to sprint, consistent sprint lengths.

9. PB&E

342


+Velocity Based Sprint Planning (2)†

n Steps in Velocity Based Sprint Planning1. Determine the team’s historical average velocity.

2. Select a number of Product Backlog items equal to that velocity.

Some teams stop there. Others include the additional step of:

3. Identify the tasks involved in the selected user stories and see if it feels like the right amount of work.

And some teams will go even further and:

4. Estimate the tasks and see if the sum of the work is in line with past sprints.

† Velocity-Driven Sprint Planning, Mountain Goat Software

9. PB&E

343


All Estimates Must Be Done As a Agile TeamNo Flow Down from the Top

9. PB&E


+

Budgeting

n Stable Agile teams

n Time Boxed Work Periods of Performance

n Fixed and Reliable sprint burn rates

n Blended Rates

n Using Specific Labor categories

n Peanut Butter Spreads for future work


9. PB&E

+ Budgeting Starts With The Business Casen Ongoing Funding

n Product Roadmap Funding


346

Evm+agile (8.8).chapter 9

Technology

Transcript of Evm+agile (8.8).chapter 9