5/6/2015

AgileRequirementsChangeManagement

AgileRequirementsChangeManagement
Home

StartHere

BestPractices

Disciplines

#AgileModeling

Artifacts

Resources

ContactUs

Search

Agilesoftwaredevelopmentteamsembracechange,acceptingtheideathatrequirements
willevolvethroughoutaproject.Agilistsunderstandthatbecauserequirementsevolve
overtimethatanyearlyinvestmentindetaileddocumentationwillonlybewasted.Instead
agilistswilldojustenoughinitialrequirementsenvisioningtoidentifytheirprojectscope
anddevelopahighlevelscheduleandestimatethat'sallyoureallyneedearlyina
project,sothat'sallyoushoulddo.Duringdevelopmenttheywillmodelstorminajustin
timemannertoexploreeachrequirementinthenecessarydetail.

Thisarticleaddressesthefollowingissues:

1. Theagilechangemanagementprocess
Freezingrequirementsduringaniteration?
Modelingahead?
2. Whyrequirementschange
3. Prioritizingrequirements
4. Estimatingrequirements
5. Whythisisdesirable
6. Potentialchallengeswiththisapproach

1.TheAgileChangeManagementProcess
Becauserequirementschangefrequentlyyouneedastreamlined,flexibleapproachto
requirementschangemanagement.Agilistswanttodevelopsoftwarewhichisbothhigh
qualityandhighvalue,andtheeasiestwaytodevelophighvaluesoftwareistoimplement
thehighestpriorityrequirementsfirst.ThisenablesthemtomaximizestakeholderROI.In
short,agilistsstrivetotrulymanagechange,nottopreventit.
Figure1overviewsthedisciplinedagileapproachtomanagingtheworkitemspotentially
neededtobeaccomplishedbytheteam(youmaynotactuallyhavesufficienttimeor
AdsbyGoogle
resourcestoaccomplishallitems).ThisapproachreflectstheDisciplinedAgileDelivery
(DAD)'sapproachtoworkmanagementwhichisanextensiontotheScrummethodology's ScrumAgile
approachtorequirementsmanagement(readaboutotheragilerequirementsprioritization
HowtoScrum
strategies).WhereScrumtreatsrequirementslikeaprioritizedstackcalledaproduct
backlog,DADtakesitonestepfurthertorecognizethatnotonlydoyouimplement
ScrumMaster
requirementsaspartofyourdailyjobbutyoualsodononrequirementrelatedworksuch
astaketraining,goonvacation,reviewproductsofotherteams,addressdefects(I
believethatdefectsaresimplyanothertypeofrequirement)andsoon.Withthisapproach
yoursoftwaredevelopmentteamhasastackofprioritizedandestimatedworkitems,
includingrequirements,whichneedtobeaddressedExtremeProgrammers(XPers)will
literallyhaveastackofuserstorieswrittenonindexcardswhereasDADmightusea
defecttrackersuchasClearQuesttomanagethestack.Stakeholdersareresponsiblefor
prioritizingtherequirementswhereasdevelopersareresponsibleforestimating.The
prioritiesofnonrequirementworkitemsareeithernegotiatedbytheteamwith
stakeholdersorareaddressedaspartofslacktimewithintheschedule.
Figure1.Disciplinedagilerequirementschangemanagementprocess.
http://agilemodeling.com/essays/changeManagement.htm

1/6

5/6/2015

AgileRequirementsChangeManagement

The"lifecycle"ofatypicaldevelopmentiteration:
1. Start.Atthestartofaniterationtheteamtakesthehighestpriorityrequirements
fromthetopofthestackwhichtheybelievetheycanimplementwithinthat
iteration.Ifyouhavenotbeenmodelingahead,moreonthisbelow,youwillneedto
discusseachoftherequirementsthatyoupulledoffthestacksothatyoutheteam
canplanhowitwillproceedduringtheiteration.Inshort,youwillbedoingsome
modelingatthebeginningofeachiterationaspartofyouroveralliterationplanning
effort,oftenusingusinginclusivemodelingtoolssuchaspaperorwhiteboards.
2. Middle.Theteamthendevelopsworkingsoftwarewhichmeetstheintentofthe
requirements,workingcloselywithstakeholdersthroughouttheiterationtoensure
thattheybuildsoftwarewhichmeetstheiractualneeds.Thiswilllikelyinclude
somemodelstormingtoexploretherequirementsingreaterdetail.
3. End.Theteamwilloptionallydemotheworkingsoftwaretoawideraudienceto
showthattheyactuallydidwhattheypromisedtodo.AlthoughademoisoptionalI
highlyrecommenddoingit:becauseworkingsoftwareistheprimarymeasureof
progressonasoftwaredevelopmentproject,youwanttocommunicateyourteam's
currentstatusbyregularlydemoingyourwork.

1.1ShouldYouFreezeTheRequirementsDuringanIteration?
Scrumsuggeststhatyoufreezetherequirementsforthecurrentiterationtoprovidea
levelofstabilityforthedevelopers.Ifyoudothisthenanychangetoarequirementyou're
currentlyimplementingshouldbetreatedasjustanothernewrequirement.XPandDAD
supportchangingrequirementsduringtheiterationifyouwishtoworkthatway,although
doingsomayforceyoutosometimesmovesomerequirementstothenextiterationto
makeroomfornewrequirementsintroducedduringthecurrentiteration.Bothapproaches
areperfectlyfine,youjustneedtochoosetheapproachwhichmakesthemostsensefor
yoursituation.

1.2HowMuch"ModelingAhead"ShouldYouDo?
http://agilemodeling.com/essays/changeManagement.htm

2/6

5/6/2015

AgileRequirementsChangeManagement

Figure1indicatesthattheitemstowardsthetopofthestackare
describedingreaterdetailthanthosetowardsthebottom.There'sa
fewimportantthingstounderstand:
1. It'sasignificantrisktododetailedmodelingupfront.The
article"ExaminingtheBigRequirementsUpFront(BRUF)
Approach"addressesthisproblemindetail.
2. Therequirementsinthecurrentiterationmustbe
understoodindetail.Youcan'timplementthemproperlyifyou
don'tunderstandthem.Thisdoesn'timply,however,thatyou
needmoundsofcomprehensivedocumentation.Youcanmodel
stormthedetailsonajustintime(JIT)basis.
3. Youmaydecidemodelabitahead.Forcomplex
requirementswhichareapproachingthetopofthestack,you
maychoosetomodelthemafewdaysorweeksinadvanceof
implementingthemsoastoincreasethespeedofdevelopment.
Notethatanydetailedmodelinginadvanceofactuallyneeding
theinformationshouldbeviewedasariskbecausethepriorities
couldchangeandyoumayneverneedthatinformation.
4. Youjustneedenoughdetailtoestimatethelater
requirements.It'sreasonabletoassociateanorderof
magnitudeestimatewithrequirementsfurtherdownonthe
stack,soyou'llneedjustenoughinformationaboutthe
requirementtodoexactlythat.

2.WhyRequirementsChange
Peoplechangetheirmindsformanyreasons,anddosoonaregularbasis.Thishappens
because:
1. Theymissedarequirement.Astakeholderwillbeworkingwithanexistingsystem
andrealizethatit'smissingafeature.
2. Theyidentifiedadefect.Abug,ormoreimportantlytheneedtoaddressthebug,
shouldalsobeconsideredarequirement.
3. Theyrealizetheydidn'tunderstandtheiractualneed.It'scommontoshowa
stakeholderyourworkingsystemtodateonlytohavethemrealizethatwhatthey
askedforreallyisn'twhattheywantafterall.Thisisonereasonwhyactive
stakeholderparticipationandshortiterationsareimportanttoyoursuccess.
4. Politics.Thepoliticallandscapewithinyourorganizationislikelydynamic(yes,I'm
beingpolite).Whenthebalanceofpoliticalpowershiftsamongstyourstakeholders,
anditalwaysdoes,sodotheirpriorities.Thesechangingpoliticalprioritieswill
oftenmotivatechangestorequirements.
5. Themarketplacechanges.Perhapsacompetitorwillreleaseanewproductwhich
implementsfeaturesthatyourproductdoesn't.
6. Legislationchanges.Perhapsnewlegislationrequiresnewfeatures,orchanges
toexistingfeatures,inyoursoftware.
Thebottomlineisthatifyoutryto"freeze"therequirementsearlyinthelifecycleyou
prettymuchguaranteethatyouwon'tbuildwhatpeopleactuallyneed,insteadyou'llbuild
whattheyinitiallythoughttheywanted.That'snotagreatstrategyforsuccess.
"Youdon't
haveto
change,
survivalis
not
compulsory."
Edward
Demming
http://agilemodeling.com/essays/changeManagement.htm

3/6

5/6/2015

AgileRequirementsChangeManagement

3.PrioritizingRequirements
Newrequirements,includingdefectsidentifiedaspartofyourusertestingactivities,are
prioritizedbyyourprojectstakeholdersandaddedtothestackintheappropriateplace.
Yourprojectstakeholdershavetherighttodefinenewrequirements,changetheirminds
aboutexistingrequirements,andevenreprioritizerequirementsastheyseefit.However,
stakeholdersmustalsoberesponsibleformakingdecisionsandprovidinginformationina
timelymanner.
Fundamentallyasinglepersonneedstobethefinalauthoritywhenitcomesto
requirementprioritization.InScrumthispersoniscalledtheproductowner.Althoughthere
isoftenmanyprojectstakeholdersendusers,managers,architects,operationsstaff,and
soontheproductownerisresponsibleforrepresentingthemall.Onsomeprojectsa
businessanalystmaytakeonthisresponsibility.Whoeverisinthisrolewillneedtowork
togetherwiththeotherstakeholderstoensureeveryoneisrepresentedfairly,oftena
difficulttask.

4.EstimatingRequirements
Developersareresponsibleforestimatingtheeffortrequiredtoimplementthe
requirementswhichtheywillworkon.Althoughyoumayfearthatdevelopersdon'thave
therequisiteestimatingskills,andthisisoftentrueatfirst,thefactisthatitdoesn'ttake
longforpeopletogetprettygoodatestimatingwhentheyknowthatthey'regoingtohave
toliveuptothoseestimates.
Smallerrequirementsareeasiertoestimate.Shallstatements,suchasthesystemshall
convertfeettometers,areanexampleofverysmallrequirements.Userstoriesarealittle
largerbutstillrelativelyeasytoestimate.Usecases,astapleoftheRationalUnified
Process(RUP)andtheAgileUnifiedProcess(AUP),canbecometoolargetoestimate
effectivelyalthoughyoucanreorganizethemintosmallerandmoremanageableartifacts
ifyou'reflexible.Agoodruleofthumbisthatarequirementmustbeimplementablewithin
asingleiteration.ScrumteamsusuallyhavemonthlongiterationswhereasXPteams
oftenchooseoneortwoweeksasaniterationlength.Shortiterationsreducethefeedback
cyclemakingiteasiertostayontrack.Successfulteamswilldeployaworkingcopyof
theirsystemattheendofeachiterationintoademoenvironmentwheretheirpotential
stakeholdershaveaccesstoit.Thisprovidesanotheropportunityforfeedback,often
generatingneworimprovedrequirements,andshowsstakeholdersthattheteamis
makingprogressandthustheirmoneyisbeinginvestedwisely.

5.WhyThisisDesirable
ThisapproachisdesirabletoITprofessionalsbecauseitenablesustoalwaysbeworking
onthehighestvaluefunctionality,asdefinedbyourstakeholders,atallpointsintime.
Thisisnotonlyagoodbusinessdecision,itisalsoverysatisfyingfordevelopersbecause
theyknowthattheirworkisactuallyhavingapositiveimpactontheorganization.
Thereareseveralreasonswhythisisincrediblyattractiveforstakeholders:
1. Theygetconcretefeedbackonaregularbasis.Bydevelopingworkingsoftware
onaregularbasisstakeholderscanactuallyseewhatthey'regettingfortheirIT
investment.
2. Theyhavecontroloverthescope.Thestakeholderscanaddnewrequirements,
changepriorities,orreworkexistingrequirementswhenevertheywant.Todoso,
theymerelymodifywhatiscurrentlyinthestack.Iftheteamhasn'tgottentothe
requirementyet,thenitreallydoesn'tmatterthattherequirementhaschanged.
3. Theyhavecontrolovertheschedule.Thestakeholderscanfundtheprojectfor
http://agilemodeling.com/essays/changeManagement.htm

4/6

5/6/2015

AgileRequirementsChangeManagement

aslongastheyneedto.Thedevelopmentteamisalwaysworkingonthehighest
priorityrequirementswhicharecurrentlyidentified,andtheyproduceworking
softwareeachiteration.Theimplicationisthatatvariouspointsintheprojectthat
thestakeholdersshouldbeabletosay"OK,thisisgoodenoughfornow,let's
deploythisintoproduction",givingthemcontrolovertheschedule.Yes,theywill
stillneedtogothroughareleaseiterationtoactuallygetthesysteminproduction.
4. Theyhavecontroloverthebudget.Atthebeginningofeachiterationthe
stakeholderscandecidetofundtheteamforasmuch,oraslittle,astheyseefit.If
theteamhasbeendoingagoodjobthenthestakeholdersarelikelytocontinuethe
sameleveloffunding.Iftheyteamisdoingagreatjobthentheymaydecideto
increasethefunding,andsimilarlyiftheteamisdoingapoorjobthentheyshould
decreaseorevencutfunding.Theimplicationisthatnotonlydostakeholdershave
controloverthebudget,theycanalsotreattheirITinvestmentasatrueinvestment
portfolioandputtheirmoneyintotheprojectteamswhichprovidethegreatestROI.
Inshort,withthissortofapproachstakeholdersarenowinapositionwheretheycan
governtheirITportfolioeffectively.

6.PotentialChallengesWithThisApproach
Traditionalistsoftenstrugglewiththefollowingissues:
1. Itisn'tclearhowmuchthesystemwillcostupfront.Astherequirements
changethecostmustalsochange.Sowhat?Thestakeholdershavecontrolover
thebudget,scope,andscheduleandgetconcretefeedbackonaregularbasis.In
thissituationstakeholdersdon'tneedanestimateupfrontbecauseofthe
increasedlevelofcontrolwhichtheyhave.Wouldyouratherhaveadetailed,and
verylikelywrong,estimateupfrontorwouldyouratherbeincontrolandspend
yourmoneywisely?TheapproachI'mdescribingenablesthelatter,andaccording
tothe2007ProjectSuccesssurvey,that'swhatthevastmajorityofpeopledesire.
Furthermore,withabitofinitialrequirementsenvisioningyoucaneasilygather
sufficientinformationabouttheprojectscopetogiveareasonable,rangedestimate
earlyintheproject.
2. Stakeholdersmustberesponsibleforbothmakingdecisionsandproviding
informationinatimelymanner.Withouteffectivestakeholderinvolvementany
softwaredevelopmentisatrisk,butagileteamsareparticularlyatriskbecause
theyrelyheavilyonactivestakeholderparticipation.Someoneneedstobethefinal
authoritywhenitcomestorequirementprioritization.InScrumthispersoniscalled
theproductowner.Althoughthereareoftenmanyprojectstakeholdersendusers,
managers,architects,operationsstaff,andsoontheproductownerisresponsible
forrepresentingthemall.Onsomeprojectsabusinessanalystmaytakeonthis
responsibility.Whoeverisinthisrolewillneedtoworktogetherwiththeother
stakeholderstoensureeveryoneisrepresentedfairly,oftenadifficulttask.
3. Yourstakeholdersmightprioritizetherequirementsinsuchawayastopush
anarchitecturallysignificant(readdevastating)requirementseveralmonths
out.Forexample,theneedtosupportseveraltechnicalplatformsorseveral
cultureswilloftencausesignificanthavoctoprojectsteamswhichareunprepared
forthesechanges.Myexperienceisthattheorderofrequirementsreallydoesn't
matteraslongasyoudotwothings:First,keepyourdesignmodularandofthe
highestqualitypossibleviacoderefactoringanddatabaserefactoring.Second,just
asyoudosomeinitialrequirementsmodelingupfrontyoushouldalsodosome
initialarchitecturalmodelingupfront.Thismodeleffortshouldstillbeagile,it's
surprisinghowquicklyyoucansketchafewwhiteboarddiagramswhichcapturesa
viablearchitecturalstrategyforyourteam.
4. Youstillneedtodosomeinitialrequirementsmodeling.Therequirements
stackjustdoesn'tappearoutofnowhere,you'restillgoingtohavetodosomehigh
levelinitialrequirementsmodelingupfront.Thisisalotlessthanwhat
traditionalistswilltellyouwhatyouneedtodo,butit'sabitmorethanwhatsomeof
theextremistsmightliketoclaim.Youneedtodojustbarelyenoughforyour
situation.
http://agilemodeling.com/essays/changeManagement.htm

5/6

5/6/2015

AgileRequirementsChangeManagement

Sharewithfriends:

Tweet

LinkedIn

Facebook

StumbleUpon

Digg

Baidu

Google+

LetUsHelp
Weactivelyworkwithclientsaroundtheworldtoimprovetheirinformationtechnology(IT)practices,typicallyinthe
roleofmentor/coach,teamlead,ortrainer.Afulldescriptionofwhatwedo,andhowtocontactus,canbefoundat
ScottAmbler+Associates.

RecommendedReading
Thisbook,DisciplinedAgileDelivery:APractitioner'sGuidetoAgileSoftwareDeliveryinthe
EnterprisedescribestheDisciplinedAgileDelivery(DAD)processdecisionframework.TheDAD
frameworkisapeoplefirst,learningorientedhybridagileapproachtoITsolutiondelivery.Ithasa
riskvaluedeliverylifecycle,isgoaldriven,isenterpriseaware,andprovidesthefoundationfor
scalingagile.Thisbookisparticularlyimportantforanyonewhowantstounderstandhowagile
worksfromendtoendwithinanenterprisesetting.Dataprofessionalswillfinditinteresting
becauseitshowshowagilemodelingandagiledatabasetechniquesfitintotheoverallsolution
deliveryprocess.Enterpriseprofessionalswillfinditinterestingbeauseitexplicitlypromotesthe
ideathatdisciplinedagileteamsshouldbeenterpriseawareandthereforeworkcloselywith
enterpriseteams.Existingagiledeveloperswillfinditinterestingbecauseitshowshowtoextend
ScrumbasedandKanbanbasedstrategiestoprovideacoherent,endtoendstreamlined
deliveryprocess.

TheObjectPrimer3rdEdition:AgileModelDrivenDevelopmentwithUML2isanimportant
referencebookforagilemodelers,describinghowtodevelop35typesofagilemodelsincluding
all13UML2diagrams.Furthermore,thisbookdescribesthefundamentalprogrammingand
testingtechniquesforsuccessfulagilesolutiondelivery.Thebookalsoshowshowtomovefrom
youragilemodelstosourcecode,howtosucceedatimplementationtechniquessuchas
refactoringandtestdrivendevelopment(TDD).TheObjectPrimeralsoincludesachapter
overviewingthecriticaldatabasedevelopmenttechniques(databaserefactoring,object/relational
mapping,legacyanalysis,anddatabaseaccesscoding)frommyawardwinningAgileDatabase
Techniquesbook.

Copyright20052014ScottW.Ambler

http://agilemodeling.com/essays/changeManagement.htm

ThissiteownedbyAmbysoftInc.

6/6