Transcription
THE MEASURABLE NEWS2014.01EARNED SCHEDULE FOR AGILE PROJECTSBy Robert Van De Velde, PhD, PMPABSTRACTEarned Schedule for Agile projects (AgileES) combines the speed andresponsiveness of Agile with the accuracy and control of Earned Schedule.AgileES adds value to common Agile tools that are used for assessingschedule performance. It also removes an Agile concern with Earned Value’sschedule performance metrics. Using Earned Schedule on Agile projects isnot without controversy, but there is strong, objective proof that it is validfor Agile projects. In short, AgileES deserves a place in the Agile tool kit.Since its introduction a decade ago, Earned Schedule (Lipke, 2003) has improved theability of projects to measure and track schedule performance. Traditional Earned ValueManagement (EVM) measures schedule performance in units of currency. Earned Schedulemeasures it in units of time—a richer and more intuitive metric.1 While the use of EarnedSchedule on plan-driven projects is growing, its adoption by Agile projects is stalled. Thereare several reasons for the gap.Today, Agile projects use EVM (AgileEVM) to manage cost performance. Their use of EVM forschedule management is limited—there is doubt that it adds value beyond what is providedby common Agile tools. Consider this observation concerning the use of EVM on two Agiletest projects:The Product Owners for both projects felt that the AgileEVM metrics did not provideany more schedule insight than the burndown chart provided. We agree that withoutthe need to manage cost performance, AgileEVM does not add significant value abovetraditional burndown methods. (Sulaiman, T., Barton, B., & Blackburn, T., 2006)There is also a concern with EVM’s traditional schedule performance metrics. As a projectapproaches completion, EVM’s metrics invariably show schedule performance improving. Atthe end of a project, the performance appears to be perfect, even if the project is deliveredlate. That is counter-intuitive, if not simply misleading.Finally, there are concerns within the Agile community about using EVM in any form. Basedon negative experience, some claim that EVM is merely bureaucratic overhead. Others, whohave had positive experience with EVM, dispute the claim. The debate persists.AgileES applies Earned Schedule to Agile projects and addresses all of these concerns.AgileES practice demonstrates value-add for traditional burndown methods and improvedaccuracy versus traditional EVM schedule performance metrics. AgileES theory objectivelyproves the validity of AgileES for Agile projects.AgileES PracticeAgileES quantifies schedule performance efficiency. Earned Schedule measures the amount oftime earned on a project. The Schedule Performance Index for time (SPIt) compares the amountof time earned to the actual time, thus indicating how well or poorly time is being used on theproject. The SPIt yields a profile of schedule performance that goes beyond burn charts andgives Agile teams additional information to use in identifying and correcting deviations.A recent project that used AgileES illustrates the point. The project, call it AgileEStest, wasa classic Agile project: it was a software development initiative done by a team with severalyears of Agile experience. The team prepared a product backlog, a relative sizing, and arelease plan.The planned staffing level on the project was ten team members, all of whom were colocated. The sprints were two weeks long, and the original end date was four months afterthe start. The budget was a half-million dollars.The Quarterly Magazine of the College of Performance Management mycpm.org29
Each week, the team gathered EVM data for a spreadsheet that was used to do Agile and AgileEScalculations. No additional data collection was required for AgileES. Metrics generated from theEachweek, werethe teamgathereddata teamfor ameetings.spreadsheetthat wasto dospreadsheetused inregularly EVMscheduledGroomingof theusedreleaseplanAgilewas ionwasrequiredforAgileES.Metricsat the end of each sprint.generated from the spreadsheet were used in regularly scheduled team meetings. Groomingofthe releaseplan takenwas doneat theend theof eachConsidera snapshotpart waythroughprojectsprint.(Figure 1). The snapshot includes Burndownand AgileES metrics that will be explained presently.Consider a snapshot taken part way through the project (Figure 1). The snapshot includesBurndown and AgileES metrics that will be explained presently.The project had a bad start. Actual staffing levels were significantly lower than planned. As a result,scheduleperformanceefficiencywas low.At the endof Sprintthe staffing levelwasbroughtto theAs aTheprojecthad a badstart. Actualstaffinglevelswere 3,significantlylowerthanplanned.full complementten, but due to efficiencythe delay alreadyincurredandendthe ofadditiona largenumber levelof newwasresult,scheduleofperformancewas low.At theSprintof3,the staffingrelease points,a fullmajorplan revision ofwasrequired.Thetonumberof sprintsand incurredbudget werebroughtto thecomplementten,but duethe delayalreadyandincreased,the additiontheatargetwas delayed,the contentsthe sprintsre-organized.With theThenewnumberbaseline,ofoflargedatenumberof new andreleasepoints, ofa majorplanwererevisionwas required.sprintsandbudgetwererestarted.increased, the target date was delayed, and the contents of thethe projectwasessentiallysprints were re-organized. With the new baseline, the project was essentially restarted.AgileEStestBurndown, SPIt , and Ideal Planned 0.001234567Burndown89SPIt10111213IdealBurnFigure 1: Project AgileEStest Burndown, SPIt, and Ideal BurndownThe chart focuses on the restarted project. It depicts the burndown (the blue squares)The chart focuses on the restarted project. It depicts the burndown (the blue squares) beginning withbeginning with the number of release points actually completed at the end of Sprint 4 andthe number of release points actually completed at the end of Sprint 4 and running as far as Sprint 9.running as far as Sprint 9. For those unfamiliar with burndown charts, they are commonlyFor thoseunfamiliarwith burndowncharts,schedulethey are commonlyused onprojectsforhowassessingusedon Agileprojectsfor assessingperformance.TheAgilechartsshowmuch workhas been completed and, by inference, how much remains on the project.Robert Van De Velde 20132The chart in Figure 1 also contains an Ideal Burndown line (the yellow dotted line). It runsfrom the first sprint of the re-baseline to the last planned sprint. It starts with the number ofrelease points that should have been completed at the end of Sprint 4 and finishes at Sprint11 with no remaining release points. If the actual Burndown runs below the line, the project isahead of schedule, and if it runs above the line, the project is behind schedule.After the re-baseline, the Burndown line shows a steady decline in the number of remainingrelease points. Through Sprint 8, the results appear to run on or slightly above the IdealBurndown line, indicating that the project is on or slightly behind schedule. At Sprint 9, theresults jump above the Ideal Burndown line, indicating that the project is definitely behindschedule.AgileES clarifies what is happening. As shown by the SPIt line (the red triangles), scheduleperformance efficiency improves over the first four sprints of the new baseline, but afterthe fourth, Sprint 7, performance steadily declines. While the Burndown line highlights thedeviation at Sprint 9, the shortfall began at Sprint 7. Root cause analysis of the delay shouldstart there, rather than with the later sprint.Burndown charts show the outcome of schedule performance efficiency: greater efficiencymeans more release points are consumed, less efficiency means fewer release points areconsumed. The outcome is that the project is either on, ahead of, or behind schedule. Bycontrast, AgileES assesses schedule performance efficiency itself and not just the outcomeof that performance efficiency. It shows explicitly how time is being used and thereby addsinsight to what is provided by common Agile tools such as burn charts.30The Measurable News2014.01 mycpm.org
The discussion thus far has been framed exclusively in terms of SPIt , intentionally omittingEVM’s Schedule Performance Index (SPI). As alluded to earlier, SPI is a problematic metric.The SPI is the ratio between the Earned Value and the Planned Value. At the end of a project,the Earned Value equals the Planned Value, by definition. As a project approaches its finish,the SPI begins to rise, regardless of the actual performance. Even late projects end with aperfect SPI.Unlike the SPI, Earned Schedule’s SPIt accurately reflects time performance throughout aproject’s life cycle. Again, the test project illustrates the point.By the time it completed, AgileES test had exceeded its planned finish by two sprints.Nonetheless, the SPI rose steadily from Sprint 10 onwards and ended at 1.00. In contrast, theSPIAgileESt trended downwards from Sprint 11, ultimately finishing at .80. Given the project’s finishdate, the SPIt presents a more accurate picture of time performance than does the SPI.AgileEStestSPIt vs. SPIIndexValue1.000.800.60Re-Baseline0.40Planned e 2: Project AgileEStest SPIt vs. SPIInsummary,theretherepracticalreasonsfor applyingEarned Scheduleto AgileIn summary,arearepracticalreasonsfor applyingEarned Scheduleto Agile projects.As projects.shown by Asshownby the AgileEStest project,offersnewcharts,insightintois moreaccuratethe test project,offers AgileESnew insightinto burnandit VM’sSPI. TheAgileESis it,a butgoodreason doesto usebut validity.practicality does notThe utilityof AgileESis utilitya good ofreasonto usepracticalitynotit,proveprove validity.AgileES ValidityAGILEES VALIDITYMathematicaldeduction proves validity. But, why is it necessary to prove validity? Why is theMathematicaldeductionprovesvalidity.But, towhyis it necessaryto proveWhy is the utility ofutilityof AgileESpracticenotenoughjustifyits use onAgile validity?projects?AgileES practice not enough to justify its use on Agile projects?Practice is a matter of experience, and within the Agile community, there is experience thatrunscounterto AgileESpractice.the followingPracticeis a matterof experience,and Considerwithin the Agilecommunity,statement:there is experience that runsArtificialmeasuressuchas EVMprove to be overhead at best, whose only value iscounterto AgileESpractice.Considerthetypicallyfollowing statement:tocater measuresto the dysfunctionalinfestingmany organizations.Artificialsuch as EVMbureaucratstypically proveto be overheadat best, whose (S.onlyAmbler, 2011)value is to cater to the dysfunctional bureaucrats infesting many organizations. (S.On theother2011)hand, there is experience consistent with AgileES practice. Consider theAmbler,following response to the last statement:Ignore the arguments against EV from those [who have] not deployed it successfully. YouOn the other hand, there is experience consistent with AgileES practice. Consider the followingwouldn’t take agile advice from someone who has not successfully deployed agile in a domainresponse to the last statement:and context similar to yours. Don’t do the same for anything else. (G. B. Alleman, 2011)Ignore the arguments against EV from those [who have] not deployed itsuccessfully. Youwouldn'ttakeconclusiveagile advicefromRathersomeonehas not one subjectiveExperience, althoughvaluable,is einadomainandcontextsimilartoyours.Don'tclaim with another, we need an objective approach. To prove the validitydoof theAgileES for Agilesametherefore,for anythingEarnedelse. (G.ScheduleB. Alleman,2011) were deduced from Agile metrics. Test projectsprojects,metricsthen provided empirical verification of the math.Experience, although valuable, is not conclusive proof. Rather than countering one subjective claimwith proofanother,we need an objectiveapproach.To andprovespecificthe validityof AgileESfor Agileprojects,Theincorporatesboth theapproachtheoremsfrompreviouswork ics.full prooflengthy,onlyan outline istherefore, EarnedSchedulemetricswere edhere, describingkey steps. A link to the full proof is included in the References (Vanempirical verificationof the math.De Velde, 2013).The proof incorporates both the approach and specific theorems from previous work on AgileEVM(Sulaiman, Barton, Blackburn, 2006). As the full proof is lengthy, only an outline is included here,describing key steps. A link to the full proof is included in the References (Van De Velde, 2013).The Measurable News2014.01 mycpm.orgRobert Van De Velde 2013431
ctoratmeanvelocityv (RDtheStartDate(SD)plusActualoffset.The Completemean velocityis then averagev) equalsisthecurrentsprintnumberby 1 umberAgileEVM’sreleasedate(Sulaiman,T., etal., 2006).The efactor.Theperformancefactorn). (1)𝑅𝑅𝑅𝑅𝑣𝑣 𝑆𝑆𝑆𝑆 𝐿𝐿 𝑛𝑛 .Themeanvelocityistheaveragev) equals the Start Date (SD) plus𝑛𝑛istheproofcurrentsprint(n) multipliedby 1 equationover the ActualPercentCompleteat Sprintn (APCDaten).ThestartswithnumberAgileEVM’srelease date(Sulaiman,T., etal., 2006).The Release1work per sprint. The offsetis thestartssprintLengthtimesa performancefactor.(Sulaiman,The performanceThe proofAgileEVM’sreleasedate equationT., et al.,factor2006).𝑅𝑅𝑅𝑅 with𝑆𝑆𝑆𝑆Date 𝐿𝐿 (L) 𝑛𝑛 offset.(1)The1𝑣𝑣 Startat mean velocity v v𝑅𝑅𝑅𝑅𝑆𝑆𝑆𝑆the velocity𝐿𝐿1 𝑛𝑛 the v 𝐴𝐴𝐴𝐴𝐴𝐴(1)𝑛𝑛) CompleteInAgileEVMT., nReleaseDateat mean(RDequalstheStartDate(SD)plusanoffset.Theis thecurrent(Sulaiman,sprint 𝑛work per sprint. The Theperformancefactormean velocityis theworkThe offset is the sprint Length (L) (1)times athe total number of ReleasePointsat d𝑆𝑆𝑆𝑆 average 𝐿𝐿 nper sprint.n) and the total number of Planned𝐴𝐴𝐴𝐴𝐴𝐴is thecurrent(Sulaiman,sprint number(n)al.,multipliedbyover theActualPercentat theSprintn (APC𝑛𝑛 factorperformancefactor.theThe1performanceis thecurrentnumber(n)n).multiplied by ed sprintasratiobetweenReleasePoints at Sprintn (PRP1 Completen). That lPercentCompleteatSprintn(APC).𝑅𝑅𝑅𝑅 𝑆𝑆𝑆𝑆 𝐿𝐿 𝑛𝑛 (1)the total number of Release Points 𝑣𝑣Completed at Sprintn (RPCn) and then total number of Planned𝐴𝐴𝐴𝐴𝐴𝐴𝑛𝑛 eratiobetweenn𝑅𝑅𝑅𝑅𝑅𝑅𝑛𝑛 1Release Points at Sprint n (PRPn). That is,𝑅𝑅𝑅𝑅 𝑆𝑆𝑆𝑆 𝐿𝐿𝑛𝑛 n (RPC (1)𝐴𝐴𝐴𝐴𝐴𝐴 ReleasePoints atofSprintn (PRPThatis,the total numberReleasePointsCompletedat 𝑛𝑛Sprintn). 𝑣𝑣n) and the total number of �𝐴𝐴𝐴𝑛𝑛 Complete is defined as the ratio between cent𝑅𝑅𝑅𝑅𝑅𝑅𝑛𝑛Release Points at Sprint n (PRPn). That is,In ��𝑛2006),theActual Percent Complete is defined as the ratio𝐴𝐴𝐴𝐴𝐴𝐴𝑛𝑛T., the totalnumberof n) and the total number of Planned(2) totalThatratioisequivalenttotheratiobetweentheata �𝐴𝐴𝐴𝐴Actual𝑛𝑛In AgileEVM (Sulaiman,T., et al.,thePercentCompleteis definedasthe ratiobetweenbetweenthe2006),total numberPointsCompletedat velocitySprintnv(RPCand the𝑛𝑛 of Releasen(2)ReleasePointsat Sprintn �𝑃𝑛𝑛 steps establish the equivalence.n). ngnumberPointsof PlannedReleasePoints nat(RPCSprintn (PRPThatis,v 𝐴𝐴𝐴𝐴𝐴𝐴the total number of ReleaseCompletedat Sprintthen).totalnumberof Plannedn) and𝑛𝑛 𝑃𝑃𝑃𝑃𝑃𝑃𝑛𝑛 Duration at a particular velocity v (PDv) and (2)That ratio is equivalent to the ratio between the PlannedReleaseat Sprinttonthe(PRPThat is, the Planned𝑅𝑅𝑅𝑅𝑅𝑅𝑛𝑛 Duration at a particular velocity v (PDv) andn). EarnedPlannedDurationvelocityv (PDisThetheLengthofstepstime (L)that thetheoverallproject is expected ���followingestablishequivalence.𝑛𝑛 urationataparticularvelocityv (PDv) and (2)v𝑛𝑛take in order to complete all planned release pointsat𝑛𝑛the planned velocity (PVn). The �𝐴 lprojectatis aexpectedto velocityThatratiois vequivalenttothe ratiothe ityis isthenumberatofeachsprint.ThePDv sets a baseline𝑃𝑃𝑃𝑃𝑃𝑃𝑛𝑛 eenthePlannedDurationat a theparticularvelocityvis(PDThe PlannedDurationvelocityvthe(PDLengthtime(L) thatoverallprojectexpectedto(2) thev) andv) is thev expectation Durationon the totaldurationof a(EDproject.Infollowingformal terms,theatTheestablishtheequivalence.takein ordertocompleteallvelocityplannedreleasepointsat theplannedvelocity(PVThea atvelocityv tis expected tov)velocityis nv).velocitysetsbaselineThat ratiotoreleasethe ratiopointsbetweenthePlanned inDurationat a particularv (PDv) andvelocityis thetonumberof releasepointsto be pointscompletedinplannedeach sprint.The(PVPDnv).setsa eatthevelocityTheexpectationonthe rationatvelocityThefollowingsteps) �𝑛𝑛 vofv).ThePlannedatInvelocity(PDistheof time(L) thatthe DisbetheLengththatLengththeoverallprojectis expectedto project isv)vexpectationonthe totaldurationofa project.Informalterms,velocityis t.ThePDv setsa baseline𝑃𝑃𝑃𝑃 𝐿𝐿 edreleasepointsattheplannedvelocity (PVn).𝑃𝑃𝑃𝑃take in order to complete all planned release points atplanned velocity (PVn). The planned𝑛𝑛 theexpectationthe totala freleasepointstobecompletedineachsprint.The PDv𝑃𝑃𝑃𝑃𝑃𝑃v𝑛𝑛velocity is the number of release pointsto be𝐿𝐿 completedin each sprint. The PDv sets a baseline𝑃𝑃𝑃𝑃 ��𝑛𝑛take in order to complete all planned releaseatthe planned velocity (PVn). The planned𝑃𝑃𝑃𝑃𝐿𝐿points 𝑃𝑃𝑃𝑃𝑛𝑛 is actually spent completingTheEarned onDurationat durationvelocity vof(EDis thetimethatthe release points(3)expectationthe totala project.Informalv) 𝑣𝑣𝑃𝑃𝑃𝑃𝑛𝑛𝑛𝑛 terms,𝑃𝑃𝑃𝑃𝑃𝑃velocity is the number of release points to be completedin each sprint. The PDv sets a baseline 𝐿𝐿 that are done up to that point in time, rms,(3)𝑣𝑣𝑃𝑃𝑃𝑃expectationthe totala project.In formal𝑛𝑛 terms,TheEarned onDurationat durationvelocity sv) is the time𝑃𝑃𝑃𝑃𝑃𝑃𝑛𝑛 is actually spent completing the release pointsThe Earned Duration at velocity v (ED𝑃𝑃𝑃𝑃thetimethatv) is 𝐿𝐿velocity 𝑅𝑅𝑅𝑅𝑅𝑅(3) thethat are done up to thatin time,giventheplannedvelocity.In formalterms,𝑣𝑣 atThepointEarnedDurationv (ED) is thetime thatis actually spent completingv𝑃𝑃𝑃𝑃𝑛𝑛𝑛𝑛 isthat aredoneDurationup to thatin time,giventheplannedInspentformalterms,TheEarnedat pointvelocityv 𝐸𝐸𝐸𝐸 the𝐿𝐿done 𝑃𝑃𝑃𝑃𝑃𝑃 velocity.v) 𝑣𝑣releasepointsthatupthatpointintime,given thetheplannedvelocity.In formal𝑛𝑛to𝐿𝐿 planned 𝑃𝑃𝑃𝑃𝑛𝑛 velocity. In formal terms,(3)𝑣𝑣 thethat are done up to thatpoint in time, �𝑛𝑛𝑅𝑅𝑅𝑅𝑅𝑅The Earned Duration at velocity v (ED𝐸𝐸𝐸𝐸thetimethat is actually spent completing the release points(4)v) is 𝐿𝐿 ��𝐸𝐿𝐿 planned 𝑃𝑃𝑃𝑃𝑛𝑛 terms velocity.(4)Giventhedefinitionof APCEDcommoncancelwithterms,the following result:that aredoneup to thatpointin time,givenInoutformal𝑣𝑣 n, PDv, andv, �𝑛𝑛 is actually spent completing the release pointsThe Earned Duration at velocity v (EDv) is the time that𝐸𝐸𝐸𝐸𝑣𝑣 𝐿𝐿 (4)𝑃𝑃𝑃𝑃𝑛𝑛 termsthat aredoneup to thatpointin definitiontime,givenv, tionofGivenAPC, PDcommoncancelwiththefollowingresult:nthev, ��𝑅𝑅𝑅𝑃𝑃𝑃𝑃v𝑛𝑛v 𝑣𝑣Given the definition ofresult:APCn, PDv, and𝐸𝐸𝐸𝐸ED , commoncancelout with the following result:v (5)𝐿𝐿 terms (4)𝐴𝐴𝐴𝐴𝐴𝐴𝑣𝑣𝑛𝑛 𝑅𝑅𝑅𝑅𝑅𝑅𝑛𝑛 ven the definition of APCn, PDv, and1EDv, ���𝑛 𝑃𝑃𝑃𝑃𝑣𝑣𝐸𝐸𝐸𝐸 𝑛𝑛 𝑃𝑃𝑃𝑃 𝑣𝑣(4) 𝐿𝐿𝑃𝑃𝑃𝑃𝑃𝑃(5)1 𝑣𝑣 ��𝑅𝑅𝑅 𝑛𝑛𝐸𝐸𝐸𝐸(5)𝑛𝑛𝑛𝑛 (1),𝑣𝑣 have:Substitutingfor the performanceinEDequationweGiven the definitionof APCn, PDvterm, andtermscanceloutwiththefollowingresult:v, common1 𝑛𝑛 ��𝑛 ��𝐴𝐴𝐴 term in equation (1), we have:(5)Substituting for the �𝑅𝑅𝑛𝑛 (1),𝐸𝐸𝐸𝐸Giventhe definitionof APCn, PDvterm, andEDtermscancel out with the following result:𝑛𝑛𝑣𝑣 have:v, commonSubstitutingfor the performanceinequationwe𝑃𝑃𝑃𝑃1 equation𝑃𝑃𝑃𝑃𝑃𝑃𝑛𝑛 (1),𝑃𝑃𝑃𝑃𝑣𝑣 𝑣𝑣Substituting for the performance 𝑅𝑅𝑅𝑅termin (6) we have:(5)𝑣𝑣 𝑆𝑆𝑆𝑆 𝐿𝐿 𝑛𝑛𝑛 (1), we𝑣𝑣 have:Substituting for the performance term inequation1𝑃𝑃𝑃𝑃𝑃𝑃𝑛𝑛 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑣𝑣 𝑣𝑣 𝑃𝑃𝑃𝑃𝑣𝑣 (5)𝑅𝑅𝑅𝑅Schedule 𝑆𝑆𝑆𝑆 𝑅𝑅𝑅𝑅𝑅𝑅𝐿𝐿 𝑛𝑛𝑣𝑣𝐴𝐴𝐴𝐴𝐴𝐴Next, Earnedtermsreplacethe duration velocity terms (PDv and EDv).(6)The𝐸𝐸𝐸𝐸𝑛𝑛 duration𝑣𝑣 𝑣𝑣 terms (PD and ED ). The equivalence𝐸𝐸𝐸𝐸𝑅𝑅𝑅𝑅 in𝑆𝑆𝑆𝑆 𝐿𝐿 𝑛𝑛 𝑛𝑛 we(6)Next, ngthe nce between the en the dthePlannedDurationfor EarnedSchedule) duration𝑆𝑆𝑆𝑆 (PD )𝐿𝐿isv) easy 𝑛𝑛 ES(6)Scheduleto demonstrate.For bothPDv andPDES, the(PDplanned𝑣𝑣 (PDES𝐸𝐸𝐸𝐸have:Substitutingforthe performanceterm in(1),we𝑣𝑣 terms (PDv and EDv). The iondurationis thebetweenFinishand theDate. So, betweenPDv PDthe.is easyto demonstrate.FordifferencebothPDv andPDES,thethevelocityplanneddurationis Startthe t, Earned Schedule terms replacethedurationvelocityterms (PDv and EDv). The equivalence𝑅𝑅𝑅𝑅 𝑆𝑆𝑆𝑆 𝐿𝐿 𝑛𝑛 sh Date and the Start Date. So, PDv PDES.𝐸𝐸𝐸𝐸Planned𝑣𝑣 terms placethedurationvelocityandED).Theequivalencev) 𝑣v duration is the difference between theis easy to demonstrate. For both PDv and PDES, the planned𝑅𝑅𝑅𝑅𝑆𝑆𝑆𝑆PD 𝐿𝐿 ,) the 𝑛𝑛 planned duration(6) the𝑣𝑣v isduringeasyDatetowhichdemonstrate.ForbothPDandis) le.TheEarnedDurationforES (ED) tuallydone(RPCisgreaterthanScheduleor earnedequaltoFinishandtheStartDate.So,PD termsvelocity(PDv the hichthetotal termsnumberofvisreleasepointsdone(RPCAT) isv). The actuallyFinishDateandthe StartDate.iscumulativeeasyto fferencebetweentheterms,v ES,. rsttoplannedthe(CPRPformali). Inofdurationtermfor ty(PDES) equals)andthePlannedDurationforEarnedSchedulevES) from theFinishDate andthe StartDate.So,PD evelocityterms(PDvtoand). The ejustThereneedsbeEDanearnedvequivalentfirstto boththelast(CPRP).In, nneddurationisthedifferencebetweenthev ) was justESTheEarnedforvelocityneedsto beforanEarnedequivalentearnedvbetweenthe defined.and the edSchedule.TheEarnedDurationfor ES (EDthe lengthof time(PDES)ES) equalsFinishDateandStartDate.So,PD PD.vES(𝑅𝑅𝑅𝑅𝑅𝑅)RobertVanDeVelde 2013𝐸𝐸𝐸𝐸 𝐿𝐿 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 ES(ED)equalsthelengthoftimethe 5(7)𝐴𝐴𝐴𝐴 There𝑖𝑖TheEarnedDuration forForvelocity(ED) wasPDjustneedsto thebe anequivalentearnedESisis easyto demonstrate.both 𝐸𝐸𝐸𝐸PDvvand, defined.the planneddurationdifferencebetweenES𝑖𝑖 1durationtermfortheEarnedThev EarnedFinish DateandStart Schedule.Date. So, PDPDES. Duration for ES (EDES) equals the length of timeRobertDe Velde2013thatThere5 is exactlyTheVanEarnedDuration Forfor velocity(EDwejust heredefined.needsto beofanreleaseequivalentearnedsimplicity,assumethe totalnumberpointscompletedv) wasRobertForVansimplicity,De Velde we assume here that the total number 2013 of release points completed is exactly equal to 5equalto the durationterm for ofES)equalsthelengthoftimeESTheEarnedDurationfor velocity(EDendneedsbe an equivalentearnedthetotalnumberplannedas (Accountingof theof forajustsprint.is, thereisnotofractionalamount.(AccountingRobertVanDe Velde defined.2013ThatThere5 of the fullv) wasamount.fractionalamountsaddsconsiderablyto TheEarnedDurationforES(ED)equalsthelengthoftimefor fractional amounts adds considerably to the complexity of the fullES proof.)Robert Van De Velde 20135Now, we prove that EDv and EDES are equivalent. The equivalence rests on the fact that EDvweVeldeprove that andEDv EDand EDare equivalent.The equivalence rests on the fact that EDv andvelocityED5ES in theRobertNow,Van De 2013areESsimply differentways to count the number of units of plannedESare simply different releaseways topointscount thenumber of units of planned velocity in the release pointscompleted.completed.An example illustrates the point (Table 1). At the end of Sprint 5, 50 release points have beencompleted. At a planned velocity of 10 release points per sprint, 5 sprints have been earned.An example illustrates the point (Table 1). At the end of Sprint 5, 50 release points have beenSimilarly, if we compare the 50 points completed with the running total of planned points at32completed. At a planned velocity of 10 release points per sprint, 5 sprints have been earned. Similarly,if we compare the 50 points completed with the running total of planned points at the end of eachThe Measurable2014.01 mycpm.orgsprint, we see, again, that 5 sprints have been earned. Generalizing,we say thatNewsEDv EDES.
RPCn0An example illustrates1535(Table 1). At40505, 50 release points- have beenthe pointthe end of Sprintcompleted. At a planned velocity of 10 release points per sprint, 5 sprints have been earned.5Similarly,PVn1010running5total1010Sprint1 102 103 completed4 theif we comparethe 50 pointswithof planned6points at theEDend of eachthe endsprint,of Generalizing,we zing,wesaythatED EDES.v10 ED 1520RPCCPRPn that0 ED35 3040 4050 50- 60n.vES5 5PVnRPCAT 10 5010 5010 5010 5010 5010 Dv EDES 5030 Table 1: 4050105010101050TableEDvelocitySubstituting the EarnedScheduletermsfor1:theterms inCPRP102030ES40(6), we have:50v EDnRPCAT50506050505050𝑃𝑃𝑃𝑃1:TableED ED𝐸𝐸𝐸𝐸vES𝑅𝑅𝑅𝑅𝑣𝑣for 𝑆𝑆𝑆𝑆𝐿𝐿 𝑛𝑛terms Substituting the Earned Schedule termsthe velocityin (6), we (8)Substituting the Earned Schedule terms for the velocity terms in (6), we have:Substituting the Earned Schedule terms for the velocity terms in (6), we have:𝑃𝑃𝑃𝑃𝐸𝐸𝐸𝐸Then, we move from the Agile context to the EarnedSchedule domain. To do so, we show the𝑅𝑅𝑅𝑅𝑣𝑣 𝑆𝑆𝑆𝑆 𝐿𝐿 𝑛𝑛 (8)𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 of scheduleequivalence between EDES and the calculated amount𝑃𝑃𝑃𝑃𝐸𝐸𝐸𝐸 earned (ES). (For simplicity, the𝑅𝑅𝑅𝑅𝑣𝑣 𝑆𝑆𝑆𝑆 𝐿𝐿 𝑛𝑛 (8)𝐸𝐸𝐸𝐸outline variesherewefromthefromfull proof.)Then,movethe Agile context to the Earned 𝐸𝐸𝐸𝐸Schedule domain. To do so, we showThen, we move fromthe Agile contextto theScheduledomain.To ofdo scheduleso, we showthe (ES). (Forthe
The SPI is the ratio between the Earned Value and the Planned Value. At the end of a project, the Earned Value equals the Planned Value, by definition. As a project approaches its finish, the SPI begins to rise, regardless of the actual performance. Even late projects end with a perfect SPI. Unlike the SPI, Earned Schedule's SPI t
