Release Planning &Buffered MoSCoW Rules

Dr.EduardoMiranda
Institute for SoftwareResearch
ASSE2013 14thArgentineSymposiumonSoftwareEngineering/
42JAIIO(ArgentineConferenceonInformatics)
September16
th
,2013,Cordoba,Argentina
Gracias
Eduardo Miranda, 2013 2
Release 1 Release 2
Iterationsvs.releases
Iteration 1 Iteration 2 Iteration 3 Iteration 4
The customers plans
Iteration 5
Eduardo Miranda, 2013 3
Pacing
Activity planning
Feedback
Sense of accomplishment
Thereleaseplanningproblem
Releaseplanningistheprocessofdecidingwhenand
withwhatfeaturesaworkingversionofasoftware
productwillbemadeavailabletoitscustomers
Theprocessmusttakeintoconsiderationbusiness
objectives,technicalandfunctionaldependencies
andresourceconstrains
Eduardo Miranda, 2013 4
Releaseplanningandtheknapsackproblem
The knapsack problem
The release planning problem
Eduardo Miranda, 2013 5
Releaseplanningmethods(1)
MustHave,ShouldHave,CouldHave,Wonthave(MoSCoW)
Method;D.Clegg1994&DSDMConsortium
Unstatedcustomerpreference&deliverycertainty
Assumesthreereleaseswithinapredefinedtimebox
Manualmethod,qualitative
StatisticallyPlannedIncrementalDelivery(SPID);E.Miranda,2002
Unstatedcustomerpreference&deliverycertainty
Assumesadefinednumberofreleaseswithinapredefinedtimebox
Manual.Usessubjectiveprobabilitiesandstatisticalconceptstoguarantee
thedeliveryofthemostimportantfeaturesconsistentwiththebasic
assessments
Evolve,D.Greer&G.Ruhe,2003
Maximizesanobjectivefunctiondefinedintermsofbenefits&penalties
Inputs:Featuresvalue,criticalityandrequiredeffort;stakeholdersweight,
effortconstraintsforrelease
Undefinednumberofreleases.Geneticalgorithmmakesrecommendation
ofk bestsolutionsfortheimmediaterelease,customerchooseand
iterates
Eduardo Miranda, 2013 6
Releaseplanningmethods(2)
IncrementalFundingMethod(IFM);M.Denne &J.Cleland
Huang;2004
SoftwareisdividedintoMinimalMarketableFeatures(MMFs)and
ArchitecturalElements(AE)
MaximizestheWeightedSequenceAdjustedNetPresentValue,a
combinationofcashflowandNPV,ofMMFs.Indefinitenumberof
releaseperiods.Doesnotaddressresourceconstraints.Thebasic
methodassumesoneMMFperperiod.Userswantingtododevelop
morethanoneMMFperperiodmustaccommodatethemmanually
Canbeimplementedusingspreadsheets,theauthorsreferenceone
GAimplementation
BufferedMoSCoW rules;E.Miranda;2011
Unstatedcustomerpreference&deliverycertainty
Assumesthreereleases
AsimplerversionoftheSPIDmethodsuitableforagileteamsdonot
wantingtodealwithsubjectiveprobabilitiesandmorecomplicated
quantitativetechniques
Eduardo Miranda, 2013 7
Prioritizing
MoSCoW
Rules DSDM BufferedMoSCoW Rules
Must
have
Fundamentaltoproject
success.Withoutanyofthese
theprojectshouldbe
consideredafailure
Thosefeaturesthattheproject,
shortofacalamity,wouldbeable
todeliverwithinthedefinedtime
box
Should
have
Importantbutnotvital.May
bepainfultoleavethemout
butthesolutionstillviable
Thosefeaturesthathaveafair
chanceofbeingdeliveredwithin
thedefinedtimebox
Could
have
Nicetohave.Willenhancea
solutionbutwillnot
underminebasicfunctionality
Thosefeaturesthattheproject
coulddeliverwithinthedefined
timeboxifeverythingwentas
expected,i.e.iftherewereno
hiccupsinthedevelopmentof
featuresassignedhigherpriority
Wont
have
Thereisnotenoughbudgettodevelopthem
Eduardo Miranda, 2013 8
DSDMbufferingscheme
DSDM Atern Handbook, DSDM Consortium, Accessed 9/2/2013
Eduardo Miranda, 2013 9
BufferedMoSCoW Rules
time box
What it would take to do the whole project in the worst case
Must have
Re schedule at 50% Buffer
Should have
Buffer
Re - scheduled at 50 %
Could have
Eduardo Miranda, 2013 10
BufferedMoSCoW rulescanbeappliedtotheproject
ortoincrementswithintheproject
Minimum
deliverables
Minimum
deliverables 1
Minimum
deliverables 2
Minimum
deliverables 3
Eduardo Miranda, 2013 11
MH SH CH
MH SH CH
MH SH CH
MH SH CH
Numericalexample(1)
Features
50%
Estimate
90%
Estimate
Dependencies
A 20 40 B,C
B 7 9
C 20 30
D 5 7 E
E 5 6
F 20 40
G 10 20
H 15 30 J,K
I 12 15
J 8 10
K 6 7
L 10 18
Totalbudget(timebox)=
180hrs
Projectmanagement,
analysis&design=60hrs
Developmentbudget=
120hrs
Findthe:
MustHaveset
ShouldHaveset
CouldHaveset
WontHaveset
Feature
Nominal
Estimate
Worst
Case
Estimate
Dependencies
A 20 40 B,C
B 7 9
C 20 30
D 5 7 E
F 5 6
G 20 40
H 10 20 J,K
I 15 30
J 12 15
K 8 10
E 6 7
L 10 18
Eduardo Miranda, 2013 12
Numericalexample(2):Musthave
Feature
Nominal
Estimate
Worst
Case
Estimate
Dependencies
A 20 40 B,C
B 7 9
C 20 30
D 5 7 E
F 5 6
G 20 40
H 10 20 J,K
I 15 30
J 12 15
K 8 10
E 6 7
L 10 18
3)SelectA,B,C 79 21 100 =
2)SelectD,E 14 100 114 =
4)SelectG 40 19 21 =
1)SelectF 6 114 120 =
5)SelectK 10 11 21 =
1.Select,accordingtoitsbusinessvalue, asmany
featuresasyoucanfitintothedevelopment
budget(120hrs)usingtheWorstCaseEstimates.
Assumethatthepreferredorderis:F,D,A,G,K,E,
L,J,H,I,B,C
2.Schedule theMUSTHAVEincrementusingthe
NominalEstimates
F+D+E+A+B+C
+K=5+5+6+20+
7+20+8=71
71 49 120 =
Eduardo Miranda, 2013 13
Numericalexample(3):Shouldhaveandcouldhave
Feature
Nominal
Estimate
Worst
Case
Estimate
Dependencies
A 20 40 B,C
B 7 9
C 20 30
D 5 7 E
F 5 6
G 20 40
H 10 20 J,K
I 15 30
J 12 15
K 8 10
E 6 7
L 10 18
1)SelectG 40 9 49 =
G 20 29 49 =
2)SelectL 18 11 29 =
3.Selectasmuchasyoucanfitintheremaining
budgetusingtheworstcaseestimates.Assume
thatthepreferredorderis:F,D,A,G,K,E,L,J,H,
I,B,C
4.ScheduletheSHOULDHAVEincrementusingthe
nominalestimates
5.Selectasmuchasyoucanfitintheremaining
budgetusingtheworstcaseestimates
6.ScheduletheCOULDHAVEincrementusingthe
nominalestimates
L 10 19 29 =
Eduardo Miranda, 2013 14
Numericalexample(4):Wonthave
Feature
Nominal
Estimate
Worst
Case
Estimate
Dependencies
A 20 40 B,C
B 7 9
C 20 30
D 5 7 E
F 5 6
G 20 40
H 10 20 J,K
I 15 30
J 12 15
K 8 10
E 6 7
L 10 18
7.FeaturesH,IandJdonotfitintotheremaining
budgetandwillbescheduledaspartofanew
projectatalaterdate
8.Thefinalprioritiesare:
Musthave:F,D,E,A,B,C,K
Shouldhave:G
Couldhave:L
Wonthave:H,I,J
Eduardo Miranda, 2013 15
Anatomyoftheprojectplannedaccordingto
bufferedMoSCoW rules
Increment
Planning
System
Engineering
System
Architecting
MustHave:F,D,E,
A,B,C,K
ShouldHave:
G
Could
Have:L
Buffer=49hrs
Buffer=
29hrs
60hrs 120hrs
180hrs
Buffer=
19hrs
Eduardo Miranda, 2013 16
29 20=
9hrs
49 20=
29hrs
ImaginethatduringexecutionfeatureArequires
40hours,itsworstcase,insteadofthe20,itsmost
likelycase,thatwereallocatedtoit
Increment
Planning
System
Engineering
System
Architecting
MustHave:F,D,E,A,B,C,K
ShouldHave:
G
Could
Have:L
60hrs 120hrs
180hrs
Feature L
might or might
not be
implemented at
this time
Eduardo Miranda, 2013 17
FAQ
Whatitistheextentoftheguarantee?
Howdoyouhandleinfrastructurework,changesand
defects?
Contracts&Employeeincentives
Whywilldevelopersdosomethingmorethanthemust
have?
Whywillaclientacceptlessthaneverything?
Whatdoyouloosebyusingtheworstcasescenarios
tosimplifytheproblem?
Eduardo Miranda, 2013 18
Whatitistheextentoftheguarantee?
Resultsattheprojectlevelareconsistentwith
assertionsmadeatthelowerlevels
Iftheassertionsarewrong,theresultswillbe
consistentlywrong
Eduardo Miranda, 2013 19
Handlinginfrastructurework,defectsandchangesin
timeboxedprojects
Technicalwork(akainfrastructure,technicalstories,libraries,
commoncode)
Incorporatetheseastasksthatconsumeavailableresourcesbutare
notprioritized,i.e.theyspreadalongthedurationoftheprojector
theyaredoneupfront
Breakdownthetechnicalworkintothatstrictlynecessarytosupport
thefeaturesoneachofthereleasesandconsidereachofthepartsas
afeatureonwhichalltheothersdepend.Asonedependontheother
Changes
Acceptedattheexpenseofsomeotherfeature(s).Estimatemust
includeanyreworkneeded
Defects
Criticalandmajordefectswillbefixed
Minordefectswillbepostponedtotheendordeferredtoafollowon
project
Eduardo Miranda, 2013 20
Incentives&contracts
Associateemployeerewardswithrelease
completion,suppressovertimeandprovidelarger
bonusesaftersuccessfuldeployment
Contractsmustincludepriceincentives/penalties
contingentondeliveries
Suppliermusttakeinconsiderationtheprobabilities
ofsuccessfuldeliveriestopricethecontract
Eduardo Miranda, 2013 21
Contractingexample
Timebox=4,000hrs.;Hourlycost=100$,Projectcost=400,000$;Targetgrossmargin=30%;
Projectprice=520,000$;Musthave=2,000hrs.Shouldhave=1,000hrs.Couldhave=1,000
hrs.
Assumeprobabilityofdeliveringmusthave1bydefinition.Probabilityofdeliveringshould
have50%(prob.ofdeliveringeverythinginthemusthaveinnominaltime).Probabilityof
deliveringcouldhave25%(prob.ofdeliveringeverythingonthemusthaveandcould
havereleasesinnominaltime)
Eduardo Miranda, 2013 22
Project delivers Fixedprice (K$) Deliveryincentive(K$) Clientpays(K$) Grossmargin
Musthave
400
0 400 0
Shouldhave 100 500 25%
Couldhave 150 550 38%
Fixedpricewithincentives
Project delivers Fixedprice (K$) Deliverypenalty(K$) Clientpays(K$) Grossmargin
Musthave
550
150 400 0
Shouldhave 50 500 25%
Couldhave 0 550 38%
Fixedpricewithpenalties
Employeeincentives
Eduardo Miranda, 2013 23
Whatdoyouloosebyusingtheworstcasescenarios?
(1)
99.8% 0.2%
99.4% 0.6%
98.3% 1.7%
93.6% 6.4%
0.5000 0.8125
Normalized effort (1 = sum of worst case scenarios)
0.0
0.2
0.4
0.6
0.8
1.0
Prob. of not exceeding a certain amount of effort for the sumof (x) IID features with a Pert distribution
Sumof 20
Sumof 15
Sumof 10
Sumof 5
99.9% 0.1%
99.3% 0.7%
97.2% 2.8%
91.5% 8.5%
0.5000 0.8400
Normalized effort (1 =sumof worst case scenarios)
0.0
0.2
0.4
0.6
0.8
1.0
Prob. of not exceeding a certain amount of effort for the sumof (x) IID features with a Uniformdistribution
Sumof 20
Sumof 15
Sumof 10
Sumof 5
You could have accepted a couple of extra features in the must have or
in the should have releases
Eduardo Miranda, 2013 24
Whatdoyouloosebyusingtheworstcasescenarios?
(2)
Independenteffortdistribution
99.8% 0.2%
99.4% 0.6%
97.7% 2.3%
92.5% 7.5%
0.5000 0.8125
Normalized effort (1 = sum of worst case scenarios)
0.0
0.2
0.4
0.6
0.8
1.0
Prob. of not exceeding a certain amount of effort for the sum of (x) IID features with a Pert distribution
Sum of 20
Sum of 15
Sum of 10
Sum of 5
Correlatedeffortdistribution
99.9% 0.1%
99.8% 0.2%
99.6% 0.4%
99.7% 0.3%
0.5000 0.9275
Normalized effort (1 = sum of worst case scenarios)
0.0
0.2
0.4
0.6
0.8
1.0
Prob. of not exceeding a certain amount of effort for the sum of (x) correlated ID features with a Pert distribution
Sum of 20
Sum of 15
Sum of 10
Sum of 5
Eduardo Miranda, 2013 25
If there is an underlying common cause, e.g. we underestimated the
complexity of all features, or the environment is highly unstable, the effort
required by each feature will tend to shift in concert with the effort
required by the others (the variables are correlated) and the total will get
closer to the sum of the worst cases
Amoreflexibleapproach:TheSPIDProcess
) ( )
) ( ) ( )
) ( ) ( ) ( )
) ( ) ( ) ( )
( )
1
1 2
1 2 3
1 2 3
1
1 2
1 2 3
1 2 3
1
2
3
n
X
X X
X X X
X X X
X n
ReleaseCostDistribution f x
ReleaseCostDistribution f x f x
ReleaseCostDistribution f x f x f x
n ReleaseCostDistribution f x f x f x
f x
=
=
=
=

Fit?
1) Individual distributions
and correlations (Estimator
analysis)
2.x) Stepwise aggregation
for each release
Accept in
current release
(Must have,
should have,
etc.)
3.x) Decision making
Yes
4) Repeat with new
available budget for next
release
No
Eduardo Miranda, 2013 26
Closedformsolution

E. Miranda 2011, CMU 27
Correlation matrix
Cost
distributions
1
n
Release i
i

=
=

1
2
, j
1 1 1
2
n n n
Release i i j i
i i j i
o o o o

= = = +
= +

*OnesidedChebyshev inequality,TheEconomicAnalysisofIndustrialProjects,L.Bussey,PrenticeHallseriesin
IndustrialandSystemEngineering,1978
*
3
Release Release
AvailableBudget o + s
CalculatingthetotalcostdistributionusingMonteCarlo
simulation
M
o
n
t
e

C
a
r
l
o

s
i
m
u
l
a
t
i
o
n
ComputetheCDFfor
eachentity
Generatearandom
number[0,1]
Computethecostof
entityfortherun
Allentities
completed
?
0
1
e
Addcomputedcosts
foralltheentities
All
iterations
completed
?
Computecost
distribution
Storecomputedcost
No
No
0 %
100 %
Cumulative Cost
Distribution
P
r
o
b
a
b
i
l
i
t
y
I
n
p
u
t
s
O
u
t
p
u
t
s
Eduardo Miranda, 2013 28
Summary
Wehavepresentedasimpleprioritizationprocedurethatcanbeapplied
totherankingofrequirementsatthereleaseaswellastheprojectlevel.
Theproceduredoesnotonlycapturescustomerpreferences,butby
constrainingthenumberoffeaturesinthemusthavesetasafunction
oftheuncertaintyoftheunderlyingestimates,isabletoofferproject
sponsorsahighdegreeofreassuranceinregardstothedeliveredofan
agreedlevelofsoftwarefunctionalitybytheendofthetimebox
Tobeworkableforthesupplierandtheemployer,thecontractbetween
thepartsmustincorporatethenotionthatanagreedpartialdeliveryisan
acceptable,althoughnotpreferred,outcome
Similarly,employeesmustbeengagedintotheprocesstopreventfree
rides
Themethodsimplicityisnotfree.Itcomesattheexpenseoftheclaims
wecanmakeaboutthelikelihoodofdeliveringagivenfunctionalityanda
conservativebuffer.Usersseekingtomakemoredefinitiveprobabilistic
statementsoroptimizethebuffersizeshouldconsidertheuseofamore
sophisticatedapproachsuchasSPID(describedinPlanningandExecuting
TimeBoundProjects,E.Miranda,2002)
Eduardo Miranda, 2013 29
Questions?
Eduardo Miranda, 2013 30