EduardoMiranda2011

TIMEBOXINGPLANNING:BUFFERED
MOSCOWRULES
EDUARDOMIRANDA,INSTITUTEFORSOFTWARERESEARCH,CARNEGIEMELLON
UNIVERSITY,SEPTEMBER2011
Keywords:Timeboxingplanning,prioritizationrules,releaseplanning,agile,incrementaldelivery,
requirementsprioritization,designtoschedule
ABSTRACT
Timeboxingisamanagementtechniquewhichprioritizesscheduleoverdeliverablesbuttimeboxes
whicharemerelyaself,oranoutside,imposedtargetwithoutagreedpartialoutcomesandjustified
certaintyareatbest,anexpressionofgoodwillonthepartoftheteam.Thisessayproposestheuseofa
modifiedsetofMoscowruleswhichaccomplishtheobjectivesofprioritizingdeliverablesandproviding
adegreeofassuranceasafunctionoftheuncertaintyoftheunderlyingestimates.
INTRODUCTION
Timeboxingisamanagementtechniquewhichprioritizesscheduleoverdeliverables.Thismeansthatif
duringtheexecutionofthetaskitisanticipatedthatallrequesteddeliverableswillnotbereadybyaset
completiondate,thescopeoftheworkwillbereducedsothatasmaller,yetstilluseful,outputis
producedbysuchdate.Thetwodimensionsofthetimeboxarethelengthoftimeitisgivenandthe
resourcesavailableduringthattime.Thetimeboxconceptcanbeappliedtoindividualtasksandsingle
iterationsbutthefocusofthisproposalisinlargeraggregates,suchasareleaseoraproject,
culminatinginthedeliveryofanagreedfunctionalitytoacustomer.
EduardoMiranda2011

Tobeeffective,timeboxingrequiresthat(Miranda,2002):
1. Thefeaturesoruserrequirements
1
thatmakeupthetotaldeliveryaregroupedintofunctionally
completesubsets;
2. Thesubsetsareprioritizedsoitisclearwhichrequirementsshouldbeimplementedfirstand
whichonescouldbeeliminatedifthereisnotenoughtimetocompleteallofthem;and
3. Reasonableassuranceisprovidedtothecustomeraboutthefeasibilityofagivensubsetwithin
theimposedframe
Timeboxeswhicharemerelyaself,oranoutside,imposedtargetwithoutagreedpartialoutcomesand
justifiedcertaintyareatbest,anexpressionofgoodwillonthepartoftheteam.
Prioritizationistraditionallymadebyaskingthecustomertorankhisorherpreferencesintoaseriesof
categoriessuchasMusthave,Shouldhave,CouldhaveorWonthavewheretheMusthave
categorycontainsallrequirementsthatmustbesatisfiedinthefinaldeliveryforthesolutiontobe
consideredasuccess.TheShouldhaverepresentshighpriorityitemsthatshouldbeincludedinthe
solutionifpossible.TheCouldhavecorrespondstothoserequirementwhichareconsidereddesirable
butnotnecessary.Theywillbeincludedifthereisanytimeleftafterdevelopingtheprevioustwo.
Wonthaveareusedtodesignaterequirementsthatwillnotbeimplementedinagiventimebox,but
maybeconsideredforthefuture.ThesecategoriesarecommonlyknownbytheacronymMoscow
(Stapleton,2003).Lessusedtechniquesincludethepairwisecomparisons,cumulativevoting,topten
requirementsandEVOLVE(Berander&Andrews,2005).
WiththeexceptionofEVOLVE(Greer&Ruhe,2004)whichusesacomplexsearchprocedureto
maximizevaluewithintheconstraintsimposedbytheavailableresources;allthetechniquesabove
sufferfromthesameproblem:theyareeitherunconstrainedorarbitrarilyconstrained.Forexamplein
thetoptentechniquethemusthavewouldbelimitedtothe10moreimportantrequirements.Why
10?Whynotelevenortwelveornine?Thislackofconstraintsmeansthatingeneral,aslongasthe
aggregatedeffortiswithintheprojectbudgetthereisnolimittothenumberofrequirementsthatare
assignedtothemusthavecategorywithwhichtheprioritizationprocessendsupnotprioritizing
anythingatall.
Inthisarticlewedescribeasimplerequirementprioritizationmethodthat:1)RedefinestheMOSCOW
categoriesintermsoftheteamsabilitytocompletetherequirementsassignedtothem;and2)
Constrainsthenumberofrequirementsthatthecustomercanallocatetoeachcategoryasafunctionof
theuncertaintyoftheestimateswhichmakesitpossibletogivethesponsorcertainreassuranceswith
regardstotheirachievabilityornot.TheMOSCOWcategoriesareredefinedasfollows:
1. MustHave:Thosefeaturesthattheproject,shortofacalamity,wouldbeabletodeliverwithin
thedefinedtimebox

1
Thesetwotermswillbeusedlooselyandalternativelytorefertoadiscretecapabilityrequestedbythesponsor
ofthework
EduardoMiranda2011

2. ShouldHave:Thosefeaturesthathaveafairchanceofbeingdeliveredwithinthedefinedtime
box
3. CouldHave:Thosefeaturesthattheprojectcoulddeliverwithinthedefinedtimeboxif
everythingwentextraordinarilywell,i.e.iftherewerenohiccupsinthedevelopmentof
requirementsassignedtohigherprioritycategories
4. Wonthavefeatures,thoseforwhichthereisnotenoughbudgettodevelopthem
Therefore,thefittingofrequirementsintothesecategoriesisnotanaprioridecisionbutrathera
consequenceofwhatthedevelopmentteambelievescanbeaccomplishedunderthespecificproject
contextandbudget.
InthepastIhaveassociatedadeliveryprobabilityof90,45and20%witheachofthecategories,but
thisquantificationitisonlypossibleifoneiswillingtomakeassumptionsabouttheindependenceor
covarianceoftheactualefforts,thenumberofrequirementsincludedineachcategoryandthetypeof
distributionsunderlyingeachestimate;ortouseamethodsuchasMonteCarlosimulationtoexpose
thedistributionofthetotaleffortforeachcategory.Ifwearenotwillingtomakethis,quotingspecific
numbersisjustananalogy,allwecanjustifiablesayisthatthelikelihoodofdeliveringallrequirements
inthemusthavecategorywouldroughlydoublethelikelihoodofthoseintheshouldhavecategory
andquadruplethatofthoseinthecouldhaveone.
THE IDEA
Theprocessrequiresthateachfeatureorrequirementtobedevelopedhasatwopointsestimate
2
:a
normalcompletioneffort
3
andasafecompletionone.Thenormalcompletioneffortisthat,whichinthe
knowledgeoftheestimatorhasafairchanceofbeingenoughtodeveloptheestimatedfeaturewhile
thesafeestimateisthatwhichwillbesufficienttodotheworkmostofthetimebutinafewreallybad
cases.
Ifwewantedtobereassuredofbeingabletodeliverallfeaturesundermostcircumstanceswewould
needtoplanfortheworstcase,whichmeansschedulingalldeliverablesusingtheirsafeestimate.This,
morelikelythannot,willexceedtheboundariesofthetimebox
4
.SeeFigure1.a.
Itisclearthatbyschedulingfeaturesatthesafelevel,themostworkwecanaccommodatewithinthe
timeboxboundariesisthatdepictedbythepatternedareainFigure1.b.Soforthemusthave
categorythecustomermustselect,fromamongallrequirements,thosewhicharemoreimportantfor
himuntilexhaustingthenumberofdevelopmenthoursavailablewhileschedulingthematthesafe

2
MoresophisticatedapproachessuchasStatisticallyPlannedIncrementalDeliveriesSPID(Miranda,2002)will
requirethreepointsestimatesandthespecificationofanunderlyingdistribution
3
AsIdidintheredefiningoftheMOSCOWcategoriesinthisarticleIamavoidingthetemptationofcallingthese
estimatesthe50%andthe90%probabilityestimatestopreventgivingafalsesenseofmathematicalexactness,
thatwillrequirethemakingofadditionalassumptionsorananalysisthatmightnotbejustifiedbythepractical
impactoftheaddedaccuracyandprecision.
4
Ifasingleprojecthadtoensureagainstallpossiblerisksanduncertainty,itspricewouldbeprohibitive
(Kitchenham&Linkman,1997)
EduardoMiranda2011

effortlevel.Thisistheconstraintmissinginotherprioritizationmethodsandthekeytoprovideahigh
levelofconfidence,inspiteoftheuncertaintyoftheestimatesandthespeedofexecution,inthe
deliveryoffeaturesinthiscategory.
Oncethemusthaverequirementshavebeenselected,wewillreschedulethemusingtheirnormal
estimates,seefigure1.c,andreservethedifferencebetweenthetwoeffortlevelsasabuffertoprotect
theirdelivery.Wewillrepeattheprocessfortheshouldhaveandcouldhaverequirementsusing
thesizeofthebufferprotectingthepreviouscategoryastheinitialbudgetforthecurrentone,see
figure1.d.Therequirementsthatcouldnotbeaccommodatedinanycategoryattheirsafelevel
becomethewonthaves.

Figure1Howthemethodworks
Wecanseenowwhywesaidatthebeginningofthisessaythatthemusthavecategorywillhave
doublethelikelihoodofbeingcompletedoftheshouldhaveandquadruplethatofthecouldhave.
Wearealmostcertainthatalltherequirementsinthemusthavecategorycanbecompletedwithin
thetimeboxbecausearequirementwasonlyincludedinitiftherewasenoughroomtodevelopit
underaworstcaseassumption.Theshouldhavecategoryalsohavetheirrequirementsscheduledat
thesafelevel,butwithrespecttotheoveralltimeboxthislevelofconfidenceiscontingentonthesum
Timebox
Developmentactivitiesscheduledattheirsafelevel
Musthavereleaseatsafelevel Lowerprioritydeliverables
Musthaveusingthenormal
estimate
Shouldhaveat
normal
Couldhave
atsafe
Wont
have
Startupactivities Othersupportandmanagementactivities
Startupactivities Othersupportandmanagementactivities
Startupactivities Othersupportandmanagementactivities
Buffer
Musthaveusingthenormal
estimate
Startupactivities Othersupportandmanagementactivities
Buffer
Buffer
a.
b.
c.
d.
Musthaveusingthenormal
estimate
Shouldhaveatsafelevel
Lowerpriority
deliverables
Startupactivities Othersupportandmanagementactivities
Buffer
e.
EduardoMiranda2011

oftheactualeffortsspentonalltherequirementsinthemusthavesubsetbeingequalorlessthanthe
sumoftheirnormaldevelopmenttimes.Thisroughlyhalvesthelikelihoodofcompletingallshould
haverequirementswithinthetimebox.Similarlythelikelihoodofcompletingallthecouldhave
wouldbehalfofthatofdeliveringalltheshouldhaveoraquarterofthemusthave.
A NUMERICAL EXAMPLE
Table1showsthebacklogforanimaginaryprojectwithatotalbudget(timebox)of180hrs.Assuming
thatthestartup,andthesupportandmanagementactivitiesrequire60hrs.leaveuswithadevelopment
budgetof120hrs.Thetableliststhenameofthefeatures,thenormalandthesafeestimatesandthe
nameofotherrequirementsorfeaturesinwhichthecurrentonedependson.ForexamplefeatureH
willhaveanormalestimateof10hours,asafeestimateof20hoursanddependsonJandK,
meaningthatthesetwofeaturesmustbepresentforHtoprovideanybusinessvalue.
Table1Productbacklog
Letsassumethatfromapurebusiness
perspectivethepreferencesoftheproject
sponsorare:F,D,A,G,K,E,L,J,H,I,B,C.In
arealprojectthischoiceswillbemade
duringtheprioritizationmeeting.
Inourexample,thefirstrequirementtobe
selectedforthemusthavecategory
wouldberequirementF,applyingthe
processdescribedbelowwehave:

A:oiloblcBuJgct
+1
= A:oiloblcBuJgct

- SocEstimotc

= 12ubrs -6brs = 114brs

Successiverequirementsareselectedaspertable2.NoticethatfeatureGcannotbeincludedinthe
musthavesubsetatthesafelevelbecauseitdoesnotfitintotheavailablebudget.Atthispointthe
customermustdecidewhethertoresignGtoanothercategory,ifpossible,orrearrangetheprevious
selection.ForthesakeoftheexampleletsassumerequirementGispassedon,andthecustomer
choosesKwhichfollowsinhisrankofpreferencesandisschedulableintheavailablebudget.
Features NormalEstimate SafeEstimate Dependencies
A 20 40 B,C
B 7 9
C 20 30
D 5 7 E
E 6 7
F 5 6
G 20 40
H 10 20 J,K
I 15 30
J 12 15
K 8 10
L 10 18
EduardoMiranda2011

Table2Assigningrequirementstothemusthavecategory
Features Reasonforselection Aua||ah|eBudget
|
SaeFxt|mate
|
Aua||ah|eBudget
|+1
F
Customerpreference 120 6 114
D,E Customerpreference,
Dependency
114 14 100
A,B,C Customerpreference,
Dependency
100 79 21
G
Customerpreference 21 40 19
K
Customerpreference 21 10 11
AfterincludingKthereisnootherrequirementthatcanbeincludedinthemusthavecategory,so
requirementsF,D,E,A,B,C,andKarerescheduleattheirnormallevel:
HustEo:cBuJgct = NormolEstimotc

{P,,L,A,B,C,K]
= S + S + 6 + 2u + 7 + 2u + 8
= 71brs
HustEo:cBucr = A:oiloblcBuJgct - HustEo:cBuJgct = 12u - 71 = 49brs
TheprocessisnowrepeatedusingtheHustEo:cBucrastheavailablebudgetfortheshouldhave
CATEGORY,seetable3,andtheSboulJEo:cBucrforthecouldhave.Seetable4.
Table3Assigningrequirementstotheshouldhavecategory
Features Reasonforselection Aua||ah|eBudget
|
SaeFxt|mate
|
Aua||ah|eBudget
|+1
G
Customerpreference 49 40 9

Table4Assigningrequirementstothecouldhavecategory
Features Reasonforselection Aua||ah|eBudget
|
SaeFxt|mate
|
Aua||ah|eBudget
|+1
L
Customerpreference 29 18 11
AfterincludingLnothingmorecouldbeincludedintheavailableeffortatthesafeestimateleveland
inconsequenceH,IandJaredeclaredwonthave.
EduardoMiranda2011

Thefinalsubsetsare:
Musthave:F,D,E,A,B,C,K
Shouldhave:G
Couldhave:L
Wonthave:H,I,J
EXECUTION
Figure2showstheinitialplanresultingfromtheprioritizationprocess.Nowimaginethatduringthe
executionoftheprojectfeatureAtakes40hrs,itsworstcase,insteadofthe20allocatedtoitinthe
plan.ThiswillpushthedevelopmentoffeaturesGandLtotheright.Thiswouldleaveuswith29hrs
todevelopG,9morethanthe20hrsestimatedat50%,soonecansaytherestillisafairchancethe
customerwillgetit.IfGtakes20hoursthebudgetremainingintheboxwillbe9hours,onelessthan
the10estimatedat50%,sointhiscasethechanceofthecustomergettingLwouldbeslim.SeeFigure
3.

Figure2Originalplan.Timebox=180hrs,Startupandothersupportandmanagementactivities60hrs,developmentbudget120hrs

Figure3MusthavereleaseisdelayedbecauseAtakeslongerthanthescheduledbudget

Timebox
G
L H,I,J
F,D,E,A,B,C,K
Startupactivities Othersupportandmanagementactivities
49hrs
29hrs
29hrs G
Timebox
L
F,D,E,A,B,C,K
Startupactivities Othersupportandmanagementactivities
49hrs
DelayduetoA
EduardoMiranda2011

DEALING WITHCHANGES AND DEFECTS

Changesarenatural.Whenachangeoccursitshouldberankedagainstcurrentprioritiesandifaccepted
itwillbeattheexpenseofanalreadyplannedrequirementorbychangingthetimeboxitself.
Withrespecttodefectsasensiblestrategyistofixallcriticalandmajordefectswithinthetimeallocated
atthesubsetinwhichtheyarediscovered,postponingminordefectstotheendoftheprojectand
givingthecustomerthechoicebetweenfixingtheproblemsanddevelopingadditionalfunctionality.
BUSINESS IMPLICATIONS
Itisobviousthatacknowledgingfromtheverystartoftheprojectthatthecustomermightnotreceive
everythingrequestedrequiresaverydifferentcommunication,andperhapsmarketing,strategyfrom
thatofaprojectthatpromisestodoit,evenwhennobodybelievesitwilldoit.
Thepremise,inwhichthemethodisbased,isthatbusinessesarebetteroffwhentheyknowwhatcould
realisticallybeexpectedthanwhentheyarepromisedthemoon,butnoassurancesaregivenwith
respectastowhentheycouldgetit.
Tobeworkableforbothparties,thedeveloperandthesponsor,acontractmustincorporatethenotion
thatanagreedpartialdeliveryisanacceptable,althoughnotpreferred,outcome.Acontractthat
offloadsallriskinoneofthepartieswouldeitherbeprohibitiveorunacceptabletotheother.The
conceptofagreedpartialdeliveriescouldadoptmanyforms.Forexamplethecontractcouldestablisha
basicpriceforthemusthavesetwithincreasinglyhigherpremiumsfortheshouldhaveandcould
havereleases.Converselythecontractcouldproposeapriceforalldeliverablesandincludepenalties
ordiscountsifthelowerpriorityreleasesarenotdelivered.Theadvantagefortheprojectsponsoris
that,whateverhappens,hecanrestassuredthathewillgetaworkingproductwithanagreedsubsetof
thetotalfunctionalitybytheendoftheprojectonwhichhecanbasehisownplans.
Asimilarideacouldbeappliedtoanyrewardforthepeopleworkingintheproject.Norewardwillbe
associatedwithdeliveringthemusthavereleasesincetheteammembersaresimplydoingtheirjobs.
Subsequentreleaseswillresultinincreasedrecognitionoftheextraeffortputintothetask.Therelative
deliverylikelihoodassociatedwitheachreleasecouldbeusedtocalculatetherewardsexpectedvalue.
SUMMARY
Wehavepresentedasimpleprioritizationprocedurethatcanbeappliedtotherankingofrequirements
atthereleaseaswellastheprojectlevel.
Theproceduredoesnotonlycapturescustomerpreferences,butbyconstrainingthenumberof
featuresinthemusthavesetasafunctionoftheuncertaintyoftheunderlyingestimates,isableto
offerprojectsponsorsahighdegreeofreassuranceinregardstothedeliveredofanagreedlevelof
softwarefunctionalitybytheendofthetimebox.
EduardoMiranda2011

Thissimplicityisnotfree.Itcomesattheexpenseoftheclaimswecanmakeaboutthelikelihoodof
deliveringagivenfunctionalityandaconservativebuffer.Usersseekingtomakemoredefinitive
statementsthanshortofacalamityoroptimizethebuffersizeshouldconsidertheuseofamore
sophisticatedapproachsuchliketheonedescribedinPlanningandExecutingTimeBoundProjects
(Miranda,2002)whichrequiresconsiderablymoreinformationandanunderstandingoftheproblems
associatedwiththeelicitationofprobabilities.
BIBLIOGRAPHY
Berander,P.,&Andrews,A.(2005).Requirementsprioritization.InC.W.A.Aurum,Engineeringand
ManagingSoftwareRequirements.Berlin:SpringerVerlag.
Greer,D.,&Ruhe,G.(2004).Softwarereleaseplanning:anevolutionaryanditerativeapproach.
InformationandSoftwareTechnology,46(4).
Kitchenham,B.,&Linkman,S.(1997,May).Estimates,UncertaintyandRisk.IEEESoftware.
Miranda,E.(2002,March).PlanningandExecutingTimeBoundProjects.IEEEComputer.
Stapleton,J.(2003).DSDMBusinessFocusedDevelopment,2nded.London:AddisonWesley.