Agile Extension to the BABOK Guide - Agile Alliance · PDF fileBusiness Analysis in Scrum ......
Transcript of Agile Extension to the BABOK Guide - Agile Alliance · PDF fileBusiness Analysis in Scrum ......
ComplimentaryMemberCopy.NotforRedistributionorResale
Agile Extension to the
BABOK®GuideVersion 1.0
www.iiba.org
InternationalInstituteofBusinessAnalysis,Toronto,Ontario,Canada
© InternationalInstituteofBusinessAnalysis.Allrightsreserved.
Thisdocumentisprovidedtothebusinessanalysiscommunityforeducationalpurposes.IIBA®warrantsthatitissuitableforanyotherpurposeandmakesnoexpressedorimpliedwarrantyofanykindandassumesnoresponsibilityforerrorsoromissions.Noliabilityisassumedforincidentalorconsequentialdamagesinconnectionwithorarisingoutoftheuseoftheinformationcontainedherein.
IIBA®,theIIBA®logo,BABOK®andBusinessAnalysisBodyofKnowledge®areregisteredtrademarksownedbyInternationalInstituteofBusinessAnalysis.CBAP®andCCBA®areregisteredcertificationmarksownedbyInternationalInstituteofBusinessAnalysis.CertifiedBusinessAnalysisProfessional,CertificationofCompetencyinBusinessAnalysis,EndorsedEducationProvider,EEPandtheEEPlogoaretrademarksownedbyInternationalInstituteofBusinessAnalysis.”
TheAgileAlliance®andtheAgileAlliancelogoarearegisteredtrademarksownedbyTheAgileAlliance.
NochallengetothestatusorownershipoftheseoranyothertrademarkedtermscontainedhereinisintendedbytheInternationalInstituteofBusinessAnalysis.
Table of Contents
Agile Extension to the BABOK® Guide i
ComplimentaryMemberCopy.NotforRedistributionorResale.
Chapter 1: Introduction to the Agile Extension 1
What is the Agile Extension to the BABOK® Guide?...................................................... 1 What is Agile? ..................................................................................................................... 2 What does Agile Mean for Business Analysis? ............................................................... 4 What does Agile Mean for Business Analysts? ............................................................... 6 What makes a BA Successful on an Agile Team?............................................................ 8
Chapter 2: Business Analysis in Agile Approaches 9
Scrum ................................................................................................................................ 10Backlogs ......................................................................................................................................................... 10Sprint Planning and Execution.................................................................................................................... 11Roles and Responsibilities............................................................................................................................ 12Business Analysis in Scrum.......................................................................................................................... 12Techniques ..................................................................................................................................................... 13
Extreme Programming (XP) ............................................................................................ 13User Stories.................................................................................................................................................... 14Release Planning and Execution ................................................................................................................. 14Roles and Responsibilities............................................................................................................................ 16Business Analysis in XP................................................................................................................................. 16Techniques ..................................................................................................................................................... 16
Kanban .............................................................................................................................. 17Queues ........................................................................................................................................................... 17Roles and Responsibilities............................................................................................................................ 18Business Analysis in Kanban ....................................................................................................................... 18
Levels of Planning in Agile Approaches ........................................................................ 19Strategy Planning.......................................................................................................................................... 20Release Planning........................................................................................................................................... 21Iteration Planning ......................................................................................................................................... 21Daily Work Planning ..................................................................................................................................... 23Continuous Activity Planning....................................................................................................................... 23
ii Agile Extension to the BABOK® Guide
ComplimentaryMemberCopy.NotforRedistributionorResale.
Chapter 3: Mapping Agile Techniques to the BABOK® Guide 25
Business Analysis Planning and Monitoring ................................................................ 25Plan Business Analysis Approach (2.1)....................................................................................................... 25
Agile Techniques....................................................................................................................................... 26Conduct Stakeholder Analysis (2.2) ............................................................................................................ 27
Agile Techniques....................................................................................................................................... 27Plan Business Analysis Activities (2.3)......................................................................................................... 27
Agile Techniques....................................................................................................................................... 27Plan Business Analysis Communication (2.4)............................................................................................ 28
Agile Techniques....................................................................................................................................... 28Plan Requirements Management Process (2.5)......................................................................................... 28
Agile Techniques....................................................................................................................................... 28Manage Business Analysis Performance (2.6) ........................................................................................... 29
Agile Techniques....................................................................................................................................... 29 Elicitation.......................................................................................................................... 29
Prepare for Elicitation (3.1) ......................................................................................................................... 30Agile Techniques....................................................................................................................................... 30
Conduct Elicitation Activity (3.2) ................................................................................................................. 31Agile Techniques....................................................................................................................................... 31
Document Elicitation Results (3.3) .............................................................................................................. 31Agile Techniques....................................................................................................................................... 32
Confirm Elicitation Results (3.4) .................................................................................................................. 32Agile Techniques....................................................................................................................................... 32
Requirements Management and Communication ...................................................... 32Manage Solution Scope and Requirements (4.1)...................................................................................... 33
Agile Techniques....................................................................................................................................... 33Manage Requirements Traceability (4.2).................................................................................................... 33
Agile Techniques....................................................................................................................................... 33Maintain Requirements for Reuse (4.3)...................................................................................................... 34
Agile Techniques....................................................................................................................................... 34Prepare Requirements Package (4.4) ......................................................................................................... 34
Agile Techniques....................................................................................................................................... 34Communicate Requirements (4.5) .............................................................................................................. 35
Agile Techniques....................................................................................................................................... 35 Enterprise Analysis.......................................................................................................... 35
Define Business Need (5.1) .......................................................................................................................... 35Agile Techniques....................................................................................................................................... 36
Assess Capability Gaps (5.2) ........................................................................................................................ 36Agile Techniques....................................................................................................................................... 36
Determine Solution Approach (5.3) ............................................................................................................ 36Agile Techniques....................................................................................................................................... 36
Define Solution Scope (5.4).......................................................................................................................... 36Agile Techniques....................................................................................................................................... 37
Define Business Case (5.5) ........................................................................................................................... 37Agile Techniques....................................................................................................................................... 37
Requirements Analysis ................................................................................................... 38Prioritize Requirements (6.1)....................................................................................................................... 38
Agile Extension to the BABOK® Guide
ComplimentaryMemberCopy.NotforRedistributionorResale.
Agile Techniques....................................................................................................................................... 38Organize Requirements (6.2) ....................................................................................................................... 39
Agile Techniques....................................................................................................................................... 39Specify and Model Requirements (6.3)....................................................................................................... 39
Agile Techniques....................................................................................................................................... 40Define Assumptions and Constraints (6.4)................................................................................................. 40
Agile Techniques....................................................................................................................................... 40Verify Requirements (6.5)............................................................................................................................. 41
Agile Techniques....................................................................................................................................... 41Validate Requirements (6.6) ........................................................................................................................ 41
Agile Techniques....................................................................................................................................... 42 Solution Assessment and Validation............................................................................. 42
Assess Proposed Solution (7.1).................................................................................................................... 42Agile Techniques....................................................................................................................................... 42
Allocate Requirements (7.2)......................................................................................................................... 43Agile Techniques....................................................................................................................................... 43
Assess Organizational Readiness (7.3) ....................................................................................................... 43Define Transition Requirements (7.4) ......................................................................................................... 43
Techniques................................................................................................................................................ 44Validate Solution (7.5).................................................................................................................................. 44
Agile Techniques....................................................................................................................................... 44Evaluate Solution Performance (7.6).......................................................................................................... 44
Agile Techniques....................................................................................................................................... 45
Chapter 4: Agile Techniques 47
A Context for Agile Business Analysis ........................................................................... 47 A Note on Agile Extension Techniques.......................................................................... 49 BA Techniques Mapped to Agile Guidelines ................................................................. 49 Guidelines for Agile Business Analysis.......................................................................... 53 The Discovery Framework .............................................................................................. 54
See The Whole ............................................................................................................................................... 54Business Capability Analysis................................................................................................................... 55Personas ................................................................................................................................................... 59Value Stream Mapping............................................................................................................................ 60
Think as a Customer..................................................................................................................................... 64Story Decomposition ............................................................................................................................... 65Story Elaboration ..................................................................................................................................... 68Story Mapping.......................................................................................................................................... 70User Story ................................................................................................................................................. 72Storyboarding .......................................................................................................................................... 75
Analyze to Determine What is Valuable ..................................................................................................... 77Backlog Management.............................................................................................................................. 78Business Value Definition........................................................................................................................ 80Kano Analysis ........................................................................................................................................... 81MoSCoW Prioritization ............................................................................................................................ 84Purpose Alignment Model....................................................................................................................... 86
The Delivery Framework................................................................................................. 89Get Real Using Examples.............................................................................................................................. 89
iv Agile Extension to the BABOK® Guide
ComplimentaryMemberCopy.NotforRedistributionorResale.
Behaviour Driven Development (BDD) .................................................................................................. 90Understand What is Doable ........................................................................................................................ 93
Relative Estimation .................................................................................................................................. 93Planning Workshop ................................................................................................................................. 96Real Options ............................................................................................................................................. 98
Stimulate Collaboration and Continuous Improvement ....................................................................... 102Collaborative Games ............................................................................................................................. 103Retrospectives ........................................................................................................................................ 105
Avoid Waste ................................................................................................................................................. 106Lightweight Documentation ................................................................................................................. 108
Glossary ..........................................................................................111
Index ...............................................................................................117
Bibliography ....................................................................................121
Contributors ...................................................................................125
Agile Extension to the BABOK® Guide 1
ComplimentaryMemberCopy.NotforRedistributionorResale.
ONEChapterIntroduction to the Agile Extension
1.1 What is the Agile Extension to the BABOK® Guide?TheAgileExtensiontotheBABOK®Guidedescribesbusinessanalysisareasofknowledge,theirassociatedactivitiesandtasks,andtheskillsnecessarytobeeffectiveintheirexecutionwithintheframeworkofagilesoftwaredevelopment.
ThepurposeoftheAgileExtensiontotheBABOK®Guideistoactasabusinessanalysisprimerforagilesoftwaredevelopmentapproachesandprovidebusinessanalysispractitionerswith:
• anintroductiontoagilepracticesforbusinessanalysis,• anoverviewofbusinessanalysistechniquesforagilepractitioners,• asetofdefinitionsoftypicalworkingpracticesusedbybusinessanalystsworkingonagileprojects,and
• anoverviewofthenewandchangedroles,skills,andcompetenciesforbusinessanalysts.
TheAgileExtensionisofvaluetobusinessanalystsnewtoagile,aswellasthoseexperiencedinagileapproaches.Bothgroups,andallthoseinbetween,willfindhelpfulinformationsuchasanintroductiontothepracticeofbusinessanalysisinanagilecontext,themappingofexistingbusinessanalysistechniquestoagilepractices,andinclusionoftechniquesthatarespecifictothepracticeofbusinessanalysisintheagileworld.
AstheAgileExtensionhighlights,anymemberofanagileteammayengageintheprocessofbusinessanalysis.Tothatend,eachpersononanagileteamwillbenefitfromhavingasetofpracticesandtoolsfromwhichtheycanselectwhileworkinginanyoneofthedifferentflavorsofagile.IntheAgileExtension,wehavecalledparticularattentiontothemind‐setabusinessanalysispractitionermusthaveinordertoeffectivelycontributetodelivery
2 Agile Extension to the BABOK® Guide
What is Agile? Introduction to the Agile Extension
ComplimentaryMemberCopy.NotforRedistributionorResale.
ofongoingvaluetostakeholders.WehavealsodescribedanumberoftechniquesnotfoundintheBABOK®Guide,andexpandedonothersthatneededtobedescribedingreaterdetail.Manyoftheconceptsdescribedhere,andthemind‐setwedescribe,willprovevaluabletobusinessanalysisinanycontextorenvironment.Businessanalystsshouldalwaysworktoensurethatrequirementsarealignedwithorganizationalgoalsandobjectivesandthatallstakeholdershaveasharedunderstandingofthosegoals,objectives,andrequirements.Theymustalsoworktomanagerisksandvalidatethattherequirements,ifdelivered,willcreaterealvalueforstakeholders.Agileapproachescanhelpusfindnewwaystodothesethingsthatsupportcontinuousdeliveryofworkingsoftware,buttheresponsibilitytodothesethingsisinherenttotheprofessionofbusinessanalysis.
1.2 What is Agile?Agileisatermusedtodescribeanumberofiterativedevelopmentapproachesthathavedevelopedovertime.Agileoriginatedwithintheworldofsoftwaredevelopment.However,withitssuccessandabilitytoadapttoindividualcontextsandenvironments,agilehasevolvedintobeingutilizedbynon‐softwarerelatedprojects.
Thetermagilecanhavemanydifferentinterpretations.ItistheAgileManifesto(www.agilemanifesto.org)thatclearlydefineswhatagilemeans,andtheprinciplesthatsupportit.
Manifesto for Agile Software DevelopmentWeareuncoveringbetterwaysofdevelopingsoftwarebydoingitandhelpingothersdoit.Throughthisworkwehavecometovalue:
Individualsandinteractionsoverprocessesandtools
Workingsoftwareovercomprehensivedocumentation
Customercollaborationovercontractnegotiation
Respondingtochangeoverfollowingaplan
Thatis,whilethereisvalueintheitemsontheright,wevaluetheitemsontheleftmore.
Agile Extension to the BABOK® Guide 3
Introduction to the Agile Extension What is Agile?
ComplimentaryMemberCopy.NotforRedistributionorResale.
Principles Behind the Agile Manifesto
Wefollowtheseprinciples:
1. Ourhighestpriorityistosatisfythecustomerthroughearlyandcontinuousdeliveryofvaluablesoftware.
2. Welcomechangingrequirements,evenlateindevelopment.Agileprocessesharnesschangeforthecustomer'scompetitiveadvantage.
3. Deliverworkingsoftwarefrequently,fromacoupleofweekstoacoupleofmonths,withapreferencetotheshortertimescale.
4. Businesspeopleanddevelopersmustworktogetherdailythroughouttheproject.
5. Buildprojectsaroundmotivatedindividuals.Givethemtheenvironmentandsupporttheyneed,andtrustthemtogetthejobdone.
6. Themostefficientandeffectivemethodofconveyinginformationtoandwithinadevelopmentteamisface‐to‐faceconversation.
7. Workingsoftwareistheprimarymeasureofprogress.
8. Agileprocessespromotesustainabledevelopment.Thesponsors,developers,andusersshouldbeabletomaintainaconstantpaceindefinitely.
9. Continuousattentiontotechnicalexcellenceandgooddesignenhancesagility.
10. Simplicity‐‐theartofmaximizingtheamountofworknotdone‐‐isessential.
11. Thebestarchitectures,requirements,anddesignsemergefromself‐organizingteams.
12. Atregularintervals,theteamreflectsonhowtobecomemoreeffective,thentunesandadjustsitsbehavioraccordingly.
ForthepurposesoftheAgileExtensiontotheBABOK®Guide,wecharacterizetheManifestoanditsPrinciplesasaphilosophyandanapproach.
TheAgileManifestousesthetermdeveloperstodescribetheteamwhoworksonbuildingtheproduct.Thisisacross‐functionalteamofskilledindividualswhobringavarietyofexpertisetobearontheprocessofbuildingasoftwareproduct.Theskillsthatdevelopersrequiretodothisincludebusinessanalysis,technicaldesign,programminginvariouslanguagesandtools,testing,UIdesign,
4 Agile Extension to the BABOK® Guide
What does Agile Mean for Business Analysis? Introduction to the Agile Extension
ComplimentaryMemberCopy.NotforRedistributionorResale.
technicalwriting,architecture,andwhateverelseisneededtoproduceworkingsoftware.Workingsoftwareisaproductwhichisintheproductionenvironmentdeliveringvalueforourcustomers.
1.3 What does Agile Mean for Business Analysis?Muchlikeotherapproaches,businessanalysisiscentraltothesuccessofagileprojects.Businessanalysisisnecessarytoenableadiversegroupofcustomerstospeakwithasinglevoice.Notallagileprojectshavethedefinedroleofbusinessanalyst,butallagileprojectsdopracticebusinessanalysis.Businessanalysismaybedonebyoneormoremembersofanagileteam.
Intheagileworld,softwarerequirementsaredevelopedthroughcontinualexplorationofthebusinessneed.Requirementsareelicitedandrefinedthroughaniterativeprocessofplanning,definingacceptancecriteria,prioritizing,developing,andreviewingtheresults.Throughouttheiterativeplanningandanalysisofrequirements,businessanalysispractitionersmustconstantlyensurethatthefeaturesrequestedbytheusersalignwiththeproduct'sbusinessgoals,especiallyasthebusinessgoalsevolveandchangeovertime.Thisistruefornewsoftwaredevelopment,maintenanceofexistingsoftware,migrationofsoftwareanddata,orimplementationofcommercialoff‐the‐shelf(COTS)software.Itappliestoverylargemission‐criticalsoftwareprojectsinheavilyregulatedindustries,aswellastodevelopmentofsmallorsimplesoftwarefunctionalityinunregulatedenvironments.Agilebusinessanalysisisprimarilyaboutincreasingthedeliveryofbusinessvaluetothesponsorsandcustomersoftheproject/productbeingdeveloped.AgilebusinessanalysisalignswiththevaluesandprinciplesoftheAgileManifesto(www.agilemanifesto.org):
• Wevalueindividualsandinteractionsoverprocessesandtools.• Ourhighestpriorityistosatisfyourcustomerthroughearlyandcontinuousdeliveryofvaluablesoftware.
• Workingsoftwareistheprimarymeasureofprogress.
Agilebusinessanalysisisaboutensuringtherightinformationisavailabletothedevelopmentteamintherightlevelofdetail,attherighttime,sotheycanbuildtherightproduct.
Agile Extension to the BABOK® Guide 5
Introduction to the Agile Extension What does Agile Mean for Business Analysis?
ComplimentaryMemberCopy.NotforRedistributionorResale.
Thetechniquesofbusinessanalysisdonotchangedramaticallyintheagileenvironment.However,thetimingandhowtheyareuseddochange.Artifactssuchaspersonas,datamodels,usecases,storymaps,andbusinessrulescontinuetobeemployed,butarekeptaslight‐weightaspossible.Artifactsthataremorequicklydevelopedsuchasdiagrams,maps,andliststendtoprovidemorevaluetoanagileprojectthanhighlydetailedspecificationsthatslowdownthedevelopmentofworkingsoftware.Lower‐fidelityartifactsaredevelopedforthesolepurposeofbuildingthesoftwareforaspecificiterationandonlyneedtobeintelligibletotheteamduringthecourseoftheiteration.Long‐livedartifacts,ontheotherhand,areintendedtobeutilizedbeyondthescopeofdevelopment.Long‐livedartifactsmayincludethebusinesscase,charter,anddocumentationthatisusedtocommunicatewhatthesoftwaredoesandwhyitdoesit.
Agileofferstheopportunityforbusinessanalysistobenefitfromthefrequentfeedbackprovidedbythebusiness.Byreviewingtheresultsofsuccessiveiterationswiththebusinessstakeholders,analystshavetheopportunityto
• refinetheproduct'srequirementstoensuretheymaintaincohesionwiththebusinessneedsfortheproduct,
• identifyandmitigateriskearlyintheproject,and• ensurethattherightsolutionisdelivered.
Wheneverpossible,inagileprojects,highriskitemsareaddressedinearlyiterations.Thisallowstheteamtomitigateissuesandthepossiblereworkrequiredifriskitemsarenotaddresseduntillaterintheproject.Facilitatingriskdiscoveryandassistingtheteaminremainingfocusedoneffectiveriskmitigationiscentraltotheanalyst'sroleonanagileteam.
Iterativedevelopmentprocessesprovideopportunitiesforincreasedefficienciesinthepracticeofbusinessanalysis.Inplan‐drivenprojects,requirementsaredevelopedintheirentiretypriortothedevelopmentphase.Asriskelementsareuncoveredandbusinessneedsevolve,certainrequirementsmaychangeorbeeliminatedoutright;makingtheworkeffortputintothoserequirementswasted.Byprovidingjust‐in‐timerequirements,thereislessreworkofrequirementsbecauseonlytherequirementsrequiredforthecurrentreleasearedefinedindetailanddeveloped.
6 Agile Extension to the BABOK® Guide
What does Agile Mean for Business Analysts? Introduction to the Agile Extension
ComplimentaryMemberCopy.NotforRedistributionorResale.
1.4 What does Agile Mean for Business Analysts?Theearlystagesofagile'sevolutionfrequentlyreliedonasingleindividualbeingabletomakeallthedecisionsregardingthedevelopmentofthesoftware.Asagileprojectsgrowinsizeandbreadth,andbecomeadoptedbylargerandmorediverseorganizations,theroleofbusinessanalysthasbecomeavitalcontributor.Businessanalysisskillsareneededtoelicitandanalyzetheneedsandwishesofdiversestakeholdersandforarrivingatasingle,agreeduponproductvision.
Insomeprojectsadedicatedbusinessanalystroleisunnecessary.Thisisnottosaythatbusinessanalysisisnotconductedduringthecourseoftheproject,onlythatitmaybedonebyanymember,ormembers,oftheoveralldevelopmentteam.
Thereareavarietyofwaysabusinessanalystcanbeengagedonanagileproject:
• Theanalystmightbethefacilitatorinmorecomplexenvironments,bringingdivergentbusinessstakeholderstogetherandhelpingthemspeakwithasinglevoicesotheprojectteamisnotconfusedbycontradictoryandconflictingperspectives.
• Theanalystmightactastheproductowner/customerrepresentativewheretheyareempoweredbythebusinesstomakedecisionsonproductfeaturesandpriority.
• Theanalystcouldactasasurrogateproductowner,insituationswherethebusinessproductownerisnotavailable.
• Theanalystmightactasthesecondincommandtoabusinessproductownerwithlimitedavailability.
• Theanalystcouldtaketheroleofcoachinanenvironmentwherethebusinessproductowneriscompetentandcommitted,buthaslimitedITprojectexperienceandtherestofthedevelopmentteamarelackingindomainknowledge.
• Theanalystcanplayacentralroleindefiningandcommunicatingtheacceptancecriteriapriortodevelopmentworkcommencing.
• Theanalystcanbeinvolvedincreatingandexecutingacceptancetests.
• Theanalystcanensurethattheteamremainsfocusonthebusinessvalueoftheproject.
• Theanalystcanplayaroleinidentifyingimportantrequirementsthatmightnothavebeenactivelyrepresentedbystakeholders.
Agile Extension to the BABOK® Guide 7
Introduction to the Agile Extension What does Agile Mean for Business Analysts?
ComplimentaryMemberCopy.NotforRedistributionorResale.
Irrespectiveofjobtitles,businessanalysisisaboutensuringtheprojectisabletodeliverthemaximumvalueforcustomersandadaptingtotheevolvingbusinessneeds.
Thetechniquesutilizedinagileapproachesdonotrepresentamajorshiftforbusinessanalysts.TheycontinuetoutilizemanyofthetoolsandtechniquesdefinedinAGuidetotheBusinessAnalysisBodyofKnowledge®(BABOK®Guide).Whathaschangedisthetimingandtheusageofthesetechniques.Therigorsanddemandsofagileprojectsalsorequirebusinessanalyststoutilizeanddevelopskillsthattheymaynothavepreviouslyexercisedatahighlevel.Inanagileenvironment,thesuccessofthebusinessanalystreliesincreasinglyonsuchinterpersonalskillsascommunication,facilitation,coachingandnegotiation.Theseskillsarecertainlycentraltothesuccessofananalystinanyenvironment.However,duetotheinter‐connectednessofagileteams,iftheseskillsarenotbeingeffectivelyutilized,thenumberofrequeststhatcanbeadequatelyunderstoodandprioritizeddecreases.Thisresultsinfeweritemsmakingitintothesolutionimplementationforagivenrelease.
Analystsarerequiredtoapproachrequirementsfroma360degreeperspective.Theyarerequiredtoworkwiththebusinesssponsoronastrategiclevel,anddefinehowtheproposedproductorfeaturealignswiththeorganization'sportfolioandstrategy.Theymustthenworkwiththebusinessandprojectteamtobreakthisvisiondownintorequirementsthatsupporteffectiveandaccurateestimation.Inanagileprojectthisisdoneforeachiterativerelease,asopposedtothesinglerequirementsphasethatexistsinplan‐drivenapproaches.Theanalystdeliversjust‐in‐time,detailedrequirementstothedevelopmentteamsotheycanbuildonlywhatisrequiredforaspecificiteration.
Businessanalystsplayakeyroleinfacilitatingasharedunderstandingofthebusinessneedfortheprojectwithallstakeholders.Itistheroleofthebusinessanalysttofacilitateashared,agreeduponvisionfortheproductacrosstheentiredeliveryteam.Understandingandpresentingmultipleviewpoints,alongsidetheabilitytoholdsuccessfulconversations,trumptheneedforformal,detailed,longtermartifactssuchasrequirementdocuments.
Oneofthekeyelementsforabusinessanalystworkinginanagileenvironmentistheabilitytousefeedbacktodrivechange.Itisincumbentontheanalysttoconstantlyreviewrequirementswiththebusinessstakeholdersandensurethatanyshiftsinbusinessneedsareaccuratelyreflectedinfuturereleasesoftheproduct.
8 Agile Extension to the BABOK® Guide
What makes a BA Successful on an Agile Team? Introduction to the Agile Extension
ComplimentaryMemberCopy.NotforRedistributionorResale.
1.5 What makes a BA Successful on an Agile Team?Theverynatureofagileapproachesrequiresallteammemberstobeoperatingataveryhighlevelofcompetency,skill,andeffectiveness.Thisisespeciallytrueforbusinessanalysts.Onsuccessfulagileteams,businessanalystsareanintegralcomponentofthedeliveryteam.Theyareactiveparticipants,ifnottheactualfacilitatorsofplanning,analyzing,testing,anddemonstratingactivities.
Thebusinessanalystplaysacentralroleinensuringthattheproductroadmapclearlydefinestheproduct'sstrategicalignmenttothebusinessneed.Theanalystholdssharedresponsibilityindefiningthestrategiccriteriaforcompletionoftheproject.Thisrequirestheanalysttoexerciseanextremelyhighlevelofskillincommunication,facilitation,andnegotiation.Theyrequiretheabilitytolistentoandunderstandfeedbackfromallstakeholdersandusethisfeedbacktodrivethechangesrequiredtotherequirementsandprioritiesoftheproject.
Agile Extension to the BABOK® Guide 9
ComplimentaryMemberCopy.NotforRedistributionorResale.
TWOChapterBusiness Analysis in Agile Approaches
Agileisatermusedtodescribeanumberofiterativedevelopmentapproachesthathavedevelopedovertime.Itisimportanttonotethatthoughmostagileapproachesareiterative,notalliterativeapproachesareagile.Commontraitsamongstagileapproachesincludefrequentproductreleases,highlevelsofreal‐timecollaborationwithintheprojectteamandwithcustomers,reducedtimeintensivedocumentation,andregular,recurringassessmentsofvalueandrisktoallowforchange.
Afewexamplesofagileapproachesinclude
• Scrum,• ExtremeProgramming(XP),• Kanban,• Crystal,• DynamicSystemsDevelopmentMethod(DSDM),• AgileUnifiedProcess(AUP),• FeatureDrivenDevelopment,and• AdaptiveSoftwareDevelopment.
Eachagileapproachhasitsownuniquesetofcharacteristicsthatallowteamstoselectanapproachthatbestsuitstheprojectathand.Itiscommonforprojectteamstoblendcharacteristicsfrommorethanoneagileapproachbasedonuniqueteamcomposition,skills,experience,operatingenvironment,andotherfactors.DuetotimeandspacelimitationstheAgileExtensiondoesnotprovidecomprehensiveinformationoneachapproach.WedoprovideanoverviewofScrum,ExtremeProgramming(XP),andKanbaninordertoprovidealevelofcontextforthosewhoarenotfamiliarwiththeseagileapproaches.
Agileapproachestendtofocusonachievingbusinessvaluebasedonbusinessneeds.Plan‐drivenapproachestendtofocusonachievementoftheirquality/cost/deliveryanalysis(QCD)withintheprojectlife‐cycle.Whenworkinginan
10 Agile Extension to the BABOK® Guide
Scrum Business Analysis in Agile Approaches
ComplimentaryMemberCopy.NotforRedistributionorResale.
agileenvironmentbusinessanalystsworktotransformbusinessneedintobusinessvalue.
Althoughwedousetheplan‐drivenapproachasameansofarticulatingsomeofthedifferentiatingaspectsofagileapproaches,itshouldbenotedthatthesearenottheonlyapproachesavailabletothosepracticingbusinessanalysis.TheAgileExtensiontotheBABOK®Guidedoesnotrecommendoneapproachoveranother,nordoesittakeapositiononthebenefitsofapplyingagileapproaches.Duediligenceandresearchisrequiredwhenselectinganapproach.
2.1 ScrumScrumisoneofthemostpredominantagileprocessframeworksinusetoday.IntheScrumframeworkworkonaprojectisperformedinaseriesofiterations,calledsprints,whichgenerallylastfrom2to4weeks.Attheendofeachsprint,theteammustproduceworkingsoftwareofahighenoughqualitythatitcouldpotentiallybeshippedorotherwisedeliveredtoacustomer.
WithintheScrumframeworktherearefourformalmeetings,knownasceremonies:
• sprintplanning,• thedailyscrum(orstand‐up),• sprintreviews,and• sprintretrospectives.
2.1.1 Backlogs
IntheScrumframework,aproductbacklogliststherequirementsforaniterationprioritizedbyhighestcustomervalue.Thebacklogisacollectionofuserstoriesthatincludetheexpectedbusinessvalue.Theuserstoriesarerefinedastheacceptancecriteriaisdeveloped.Astheteamcollaborateswiththecustomerfortheproject,theproductbacklogisupdatedwitheachrequest.
Theproductbacklogisconstantlyprioritized,suchthatatanygiventimeitcanbeusedtoidentifyhighpriorityrequestsforthesolutionbeingdeveloped.Atthebeginningofeachsprint,inthesprintplanningceremony,theteamreviewstheprioritizedproductbacklogand
Agile Extension to the BABOK® Guide 11
Business Analysis in Agile Approaches Scrum
ComplimentaryMemberCopy.NotforRedistributionorResale.
identifiesthecustomer'shighest‐priorityuserstoriesthatcanbecompletedwithinthesprintperiod.Theselectedstoriesarethenplacedonasmallersprintbacklog.
2.1.2 Sprint Planning and Execution
Duringthesprinttheteamrefinestheirunderstandingoftheselecteduserstoriesandworkstoensurethattheyarecompletedwithinthedefinedtimelimitofthesprint.Assprintsareexecuted,theteammeetsonceperday(referredtoasthedailyscrumorstand‐upmeeting)tobrieflydiscusswhattheyareworkingonandidentifyanyimpedimentsthatmaypreventthemfromcompletingtheirwork.Attheendofthesprint,theteamdeliversworkingandtestedsoftwarethatfullyimplementsthesprint'suserstories.Thesprintisthencompletedwithacustomerreviewandaretrospective.Duringthecustomerreview,thesoftwareisdemonstratedandthecustomerprovidesfeedback.Duringtheretrospective,theteammeetsandcollaboratestofindwaystoimproveboththeproductandtheirprocessesusedtodelivertheproduct.Boththecustomerreviewandtheretrospectivemayidentifyadditionalitemsthatfeedintotheproductbacklog.Theseitemsarethenusedtore‐prioritizetheproductbacklogforthenextsprintplanningsession.
Thefollowingillustrationdemonstratesatypicalscrumlife‐cycle.
FIGURE 2.1 Scrum Life-cycle
12 Agile Extension to the BABOK® Guide
Scrum Business Analysis in Agile Approaches
ComplimentaryMemberCopy.NotforRedistributionorResale.
2.1.3 Roles and Responsibilities
InScrum,therearethreeroles:
• ProductOwner:Theproductownerprovidestheoverallvisionanddirectionoftheproduct.Theyareresponsiblefordefiningtheproductbacklogandperformbacklogprioritizationaccordingtocustomervalue.
• ScrumMaster:Thescrummasterensurestheteam'sScrumprocessesarefollowedandtheteamfunctionswellthroughcollaborationandfacilitation.Theymanageanyimpedimentsthatmaypreventtheteamfromaccomplishingworkandshieldtheteamfromexternalinterferences.
• TheTeam:Theteamisresponsiblefordevelopinganddeliveringtheproduct.Theycollaboratewiththeproductownertodeterminewhatuserstorieswillbedeliveredinasprintandcommittodeliveryoftheuserstories.
2.1.4 Business Analysis in Scrum
WhileScrumfocusesonvaluedrivendevelopmentitdoesnotaddressbusinessanalysisactivitiesindetailandmanyoftheseactivitiesoccurasimplicitstepsinthescrumframework.Thefollowingillustrationshowsthetypicalscrumlifecyclewithbusinessanalysistechniquessuperimposed.
FIGURE 2.2 Business Analysis in Scrum
Agile Extension to the BABOK® Guide 13
Business Analysis in Agile Approaches Extreme Programming (XP)
ComplimentaryMemberCopy.NotforRedistributionorResale.
Theproductbacklogisbuiltthroughacombinationofenterpriseanalysiswork(identifyinggapsandnewcapabilitiesrequiredtoaccomplishorganizationalgoalsanddefiningtheirvaluetotheorganization)andsolutionassessmentandvalidation(identifyingwaysinwhichtheexistingsolutioncanbeenhancedtobetterdeliverbusinessvalue).Withinasprint,businessanalysisactivitiesfocusonelicitingtherequirementsforthesprintbacklogitemsbeingworkedandtheacceptancecriteriaforthoseitems.Thisapproachisfrequentlyreferredtoasjust‐in‐timerequirementselicitation;developingonlywhatisrequiredforthecurrentsprintandonlydonetothelevelofdetailrequiredtoenabletheteamtobuildtheproductandacceptancecriteria.
2.1.5 Techniques• BacklogManagement:Backlogmanagementistheprimarymethodofhandlingbothrequirementsprioritizationandchangemanagementinmostagileapproaches.
• Retrospectives:Retrospectivesareacommonpracticeusedbyagileteamsseekingtoimprovetheirwaysofworking.Businessanalystsshouldlookforfeedbackontherequirementstheyprovidetotheteamandhowandwhenthoserequirementsareprovidedinordertofindwaystoimprovetheirprocesses.
• MoSCoWPrioritization:MoSCoWPrioritizationisusedtoprioritizestories(orotherelements).MoSCoWprovidesawaytoreachacommonunderstandingonrelativeimportanceofdeliveringastoryorotherpieceofbusinessvalueintheproduct.
2.2 Extreme Programming (XP)ExtremePrograming(XP)beganbeingusedbydevelopmentteamsinthemid‐1990s.Likeotheragileapproaches,XPisiterativeinnatureandprovidessmallreleasesattheendofeachiteration.XP'sprimaryfocusisontheengineeringaspectsofagilesoftwaredevelopmentandisbasedon12practicesinfourcategories.
14 Agile Extension to the BABOK® Guide
Extreme Programming (XP) Business Analysis in Agile Approaches
ComplimentaryMemberCopy.NotforRedistributionorResale.
TABLE 2.1 Extreme Programming Categories
2.2.1 User Stories
XPusestheconceptofuserstoriesasacentralmechanismtodefinerequirements.Theyarecreatedbyusersofthesystemtodefinefeaturesandfunctionalitytobeincludedinthesolutionanddonotcontainahighlevelofdetail.Eachuserstoryisnormallyaccompaniedbyalistofacceptancecriteriawhichidentifyspecificdetailsaboutthestory.
Storiesareusedto:
• prioritizeworkintoiterations,• identifyriskassociatedwitharequest,• estimatetheeffortrequiredtodelivertherequest,and• establishaconversationbetweentheteamandtheproductowneraroundthesubjectoftherealbusinessneed,inordertoconfirmacommonunderstandingofwhathastobedone.
2.2.2 Release Planning and Execution
XPreliesonthreelevelsofplanning:
• releaseplanning,• iterationplanning,and• dailyplanning.
Releaseplanningidentifiesthenextsetofusablefeaturesthatcouldmakeuparelease.Thereareoftenseveraliterationsworthofworkbeforetheproductisrelease‐ready.Iterationplanningservestoplan
XP Categories
Fine Scale Feedback
Continuous Process
Shared Understanding
Programmer Welfare
XP Practices
• Pair Programming
• Planning Game• Test Driven
Development• Whole Team
Testing
• Continuous Integration
• Re-factoring• Small
Releases• Coding
Standards
• Collective Code Ownership
• Simple Design• System
Metaphor
• Sustainable Pace
Agile Extension to the BABOK® Guide 15
Business Analysis in Agile Approaches Extreme Programming (XP)
ComplimentaryMemberCopy.NotforRedistributionorResale.
eachincrementaliterationthatwillultimatelyresultinareleasableproduct.Finally,indailyplanningtheteamplansouteachday'sactivitiestoensuretheteamisonscheduleandidentifyrisksthatmayhavearisen.
InXP,releaseplansareusedtotrackanddescribewhatfeaturesorfunctionalityistobedeliveredineachproductrelease.ThereleaseplanissimilartotheconceptoftheproductbacklogintheScrumframework.Iterationplanningmeetingsarethenusedasavehicleforteamcollaborationinplanningthecomingiteration.Astheteamworkstoscheduletherelease,theuserstoriesareorderedbasedonthemostimportantfeaturestothecustomer,ensuringthatthemostimportantfeaturesarealwaysdeliveredfirst.Storiesaredecomposedintotheirgranularfunctionalrequirementsinatechniqueknownasstorydecomposition,onajust‐in‐timebasis.Then,throughstoryelaboration,theteamidentifiesthedetaileddesignandacceptancecriteriaforthestory.
Whileaniterationisunderway,XPisalsosimilartoScruminthatitutilizesdailymeetingsasthekeycommunicationvehiclefortheteam.Thisdailystand‐upmeetingisusedtofacilitatedailyplanningactivitiesandreviewprogresssincethepriorday'sstand‐up.Inpractice,teamsemployingtheXPapproachfrequentlycombinesuchelementsascadence,roles,andceremonies(suchassprintplanningandsprintreviews)fromtheScrumframework.
ThefollowingdiagramprovidesanoverviewoftheXPmodel.
FIGURE 2.3 ExtremeProgrammingModel
16 Agile Extension to the BABOK® Guide
Extreme Programming (XP) Business Analysis in Agile Approaches
ComplimentaryMemberCopy.NotforRedistributionorResale.
2.2.3 Roles and Responsibilities
InExtremeProgramingtherearefourkeyroles:
• Customer:Thecustomercreatesandprioritizestheuserstoriesandperformsriskanalysis.
• Developer:Thedevelopercommunicatesdirectlywiththecustomerandbuildsonlywhatisnecessarytodeliveroneachiteration.
• Tracker:Thetrackerkeepstrackofthescheduleandthemetrics.• Coach:ThecoachguidesandmentorstheteaminapplyingXPpracticeseffectively.
2.2.4 Business Analysis in XP
WhileXPdoesfocusonvalue‐drivendevelopment,itdoesnotexplicitlyaddressbusinessanalysisactivities.XPreliesonthefundamentalassumptionthatthecustomerroleisfilledbyasmallnumberofpeoplewhoknowwhatthemostvaluablefeatureswillbe.WhenXPisappliedatalargerscale,orwithcustomerswhodonothaveaclearvisionoftheincrementalvalueoffeatures,abusinessanalystaddssignificantvalueinfacilitatingandnegotiatingwithstakeholderstoreachasharedunderstandingofwhatthemostvaluabledeliverableswillbe.Abusinessanalystcanalsocontributebyfacilitatingstorymapping.
IntraditionalXP,theuserstoriesarecreatedandmanageddirectlybythecustomer.Thiscanleadtounfilteredrequirementsthatareatriskofconstrainingasolutionwithoutconsiderationforrootcauseorapplicabilitytoothercustomergroups.Businessanalysisskillscanbeusedtoensureunderlyingproblemsarebeingaddressedinawaythatworksformost,ifnotall,ofthestakeholdersontheproject,aswellasensurethoroughacceptancecriteriahavebeencollectedforeachuserstory.Onprojectswherethereisadedicatedbusinessanalysttheyoftenperformstorydecompositionandelaborationactivities.
2.2.5 Techniques• UserStory:Userstoriesidentifywhichrolesinthestoryprovidevalueandthereforeidentifiesthestakeholderswhocanelaborateonthatvalue.
Agile Extension to the BABOK® Guide 17
Business Analysis in Agile Approaches Kanban
ComplimentaryMemberCopy.NotforRedistributionorResale.
• StoryMapping:Storymapsshowrelationshipsbetweenuserstoriesandlargeractivitiesthattheusermustbeabletoaccomplish.
• StoryDecomposition:Epics,features,orminimallymarketablefeatures(MMF)tiegroupsofuserstoriestogetherintolargerpackagesthatcanbediscussedwithstakeholders.
• StoryElaboration:Definesthedetaileddesignandacceptancecriteriaforauserstoryonajust‐in‐time/just‐enoughbasis.
2.3 KanbanScrumandXPareframeworksthatdefinesetsofroles,ceremonies,andpracticesforproductdelivery.Inthecontextofsoftwaredevelopment,Kanbanisanapproachformanagingtheflowofworktoallowforevolutionarychange.WithrootsintheTheoryofConstraintsandLeanproductdevelopment,Kanbanhasfivekeyprinciples:
• visualizethework,• limitworkinprocess,• focusonflow,• makeprocesspoliciesexplicit,and• continuallyimprove.
Unliketheotheragileframeworksthatwehavediscussed,Kanbandevelopmentdoesnotrequirefixediterations.Workmovesthroughthedevelopmentprocessasacontinuousflowofactivity.AkeyfeatureofKanbanistolimittheamountofworkunderwayatanyonetime(referredtoastheWorkinProgressLimitorWIP).Inthisapproachtheteamworksonlyonafixednumberofitemsatanyonetimeandworkmaybeginonanewitemonlywhenitisrequiredtomaintainflowdownstreamandafterthepreviousitemhasbeencompleted.
2.3.1 Queues
Kanbanreliesontheuseofworkqueuestomanagetheflowofactivitiesthatmusttakeplacetodeliveraworkingproduct.Theformatandcontentforworkqueuesislessprescriptiveinthisapproachthanotherswehavelookedat.Thequeueshouldonlydescribetheworktobecompletedinrelativeprioritytodelivertheproduct.Forthisreason,theKanbanapproachisoftencombinedwith
18 Agile Extension to the BABOK® Guide
Kanban Business Analysis in Agile Approaches
ComplimentaryMemberCopy.NotforRedistributionorResale.
approachessuchasScrumwherethebacklogisusedastheimplementationforthequeue.Whenanewfeaturerequestisreceived,itisassessedforrelativepriorityandurgencyandthenplacedintothequeueinitsrelativeposition,maintainingtheorderbypriority.
AnalogoustotheScrumtechniqueofmanagingtheproductbacklog,theteamevaluatesthefeatureswaitingintheinputqueuetoseeiftheyaretoolargeoroutofscopefortheupcomingrelease.Foritemsthataretoolargetobecompletedbeforeaplannedreleasedate,theprojectteamwillbreaktheitemdown(decomposeit)intosmallerchunksofwork,decidingwhichwillbeincludedinthereleaseandwhichwillnot.Theteamthenreassessesthepriorityoftheitemsinthequeueandreordersthemasneededtomaintainacontinuous,prioritizedflowofwork.
2.3.2 Roles and Responsibilities
Kanbandoesnotincludedefined,mandatedrolesorbusinessanalysispractices.Likeanyagileapproach,itstrivestobreakdownworksuchthatindividualworkitemscanbeimplementedinarelativelyshortperiodoftime.TheKanbanapproachalsoattemptstobringtheprojectteamtogetherbyincreasingcommunicationandcollaboration,enablingtheteamtoworktogetherasacollectiveandcohesiveunit.
2.3.3 Business Analysis in Kanban
Businessanalysis,likeallactivitiesintheKanbanapproach,occursinaconstantandcontinuousflowthroughthelifeofaproject.Inordertomaintainaprioritizedqueueofworkbusinessanalysistechniquesareusedtoelicitnewproductfeatures.Requirementsanalysispracticesarethenusedtoprioritizetherequirementsbasedonbusinessvalue,whilealsocontinuouslyusingbusinessanalysistechniquesforscopingtheproductandmanagingthequeueofrequirements.
WhenplanningandmanagingtasksintheKanbanapproach,ServiceLevelAgreements(SLAs)areusedtomaintaintheestimatesforhowlongafeatureorchunkofworkwilltaketobecompleted.InKanban,thisestimateincludestheplanningandanalysisactivitiesthattakeplacebeforesoftwaredevelopmentbegins.Thisapproachforcesabusinessanalysttofocusonplanningandmonitoringactivities,enablingconstantrevisionandrefinementofestimatesaseachnewrequestenterstheanalysisportionofthecycle.InaKanbanproject,
Agile Extension to the BABOK® Guide 19
Business Analysis in Agile Approaches Levels of Planning in Agile Approaches
ComplimentaryMemberCopy.NotforRedistributionorResale.
thebusinessanalystonlybeginstodefinerequirementsforanewworkitemwhenthequeuestepsforward.Atthatpointthedevelopmentteambeginstoworkononeofthecompletedrequirementswhilethebusinessanalystbeginscollectingrequirementsforthenextiteminthequeue.Byopenlyandvisiblymanagingtheworkoftheprojectteam,inefficiencieswillsurfaceasprocessimprovementopportunities.Thiswillhelptomitigatetheriskrelatedtothetimingofbusinessanalysisactivities,enablingthebusinessanalysttomanagetheriskearlyintheprocess.
2.4 Levels of Planning in Agile ApproachesDuetothefluid,dynamicnatureofagileapproaches,itisimportanttounderstandwhenandhowtoapplydifferentplanningtechniquesandtheappropriatelevelofdetailforeachlevelofplanning.Itisimportanttonotethatmanyofthetechniquesusedinanagileenvironmentaresimilartotraditionaltechniques;whatisdifferentishowandwhenthesetechniquesareapplied.Just‐in‐timeandjustenoughrequirementsthatareconsistentlyvalidatedbythebusinessarecentraltotheanalyst'sroleinagileapproaches.
Whenundergoingplanningexercisesintheagileworld,itishelpfultoconsiderhowtheanalyst'srolediffersfromplan‐drivendevelopmentapproaches.Inagiletheroleoftheanalystiscentraltothevalueoftheproject.Theanalystholdsakeyroleinmaximizingvaluebyfacilitatingtheinteractionswithalltheprojectstakeholders.Exceptionallyhighcommunication,facilitation,andnegotiationskillsareanimportantsetoftoolsforanalystsintheagileenvironment.
Successfulagileprojectsfollowaconsistentplanningcadenceof
• strategy,• release,• iteration,• daily,and• continuous.
Throughthiscadence,therequirementsfortheprojectareprogressivelyelaboratedtoanappropriatelevelofdetail.Ateachstepstableconceptsarecaptured,contextiscaptured,andlearningopportunitiesareidentified.Oneofthekeytenetsofagileistoperformasufficientlevelofanalysisateachplanninglevel.Toomuchanalysis
20 Agile Extension to the BABOK® Guide
Levels of Planning in Agile Approaches Business Analysis in Agile Approaches
ComplimentaryMemberCopy.NotforRedistributionorResale.
upfrontcanresultinthecreationofdocumentsthataresubjecttochange,requirethebusinessusertoexplaintheirneedsmultipletimes,andmaynotbenecessarytoachievethegoalsoftheproject.Toolittleanalysisupfrontcanresultinirresponsiblecommitments,rework,andalackoffocusoncustomervalue.Mostagileteamsfocusondailywork,iteration,andreleaseplanning.
FIGURE 2.4 AgileLevelsofPlanning
2.4.1 Strategy Planning
Projectsandproductdevelopmenteffortsstartwithavisionofthebusinessdirectionorneed.Thevisionincludesthewhat,why,andsuccesscriteriafortheeffort.Thevisionisoftenassociatedwitharoadmap.Theroadmapincludesthehigh‐levelscopeandmayincludeaninitialarchitecture.Inadditiontoactivitiessuchasestablishingavision,scope,androadmap,thestrategyworkonanagileprojectincludestheinitialcreationofafeaturerequestlist.Forexample,inScrumthisentailsseedingtheinitialrequestsinaproductbacklogor,inXP,userstories.Thisisanalogoustopre‐projectelicitationofbasicstakeholderrequirementsthatareusedtofacilitatediscussionsonscopingandphasinginplan‐drivenprojects.
Agile Extension to the BABOK® Guide 21
Business Analysis in Agile Approaches Levels of Planning in Agile Approaches
ComplimentaryMemberCopy.NotforRedistributionorResale.
Atastrategiclevel,thepersonwhoownstheproductorisleadingtheinitiativehelpsthedeliveryteamto
• identifythedesiredbusinessvalue,• definethebusinesscontext,• definethecontextofthesolutionneeded,• identifyandoutlinesthestepstorealizethevisionwiththedeliveryteam,
• identifytheprincipleswhichshouldbeusedwhenprioritizingwork,and
• definetheproductroadmap.
Strongenterprisebusinessanalysisskillsarerequiredtoeffectivelyplanastrategyforanagileproject.Insomeways,youcouldarguethattheseskillsbecomemoreimportantinagileapproaches.Thisisbecausewithoutdirectionbasedonbusinessvalueandaclearlydefinedscopeandaudience,agileprojectsareatriskfordeliveringincrementalfeaturesthatnevercometogethertocreateend‐to‐endvalueforanyonecustomergroup.Withoutaroadmapandsuccesscriteriafortheproduct,agileprojectscouldconceivablygoonforever,wastingtime,money,andotherresourcesintheprocess.
2.4.2 Release Planning
Releaseplanningistheactivityinwhichthepersonwhoownstheproductgroupsactivitiesandallocatesthemtoteams.Teamsworkondefiningenoughdetailtoresponsiblycommittosomerangeofscopefortherelease.Whenconsideringrelease,teamsconsiderbusinessconditionsandoperationalreadiness.Teamsshouldreleasewhenthebenefitsofdeliveryoutweighthecostsassociatedwithrelease.Thereleaseisdefinedbyadate,strategictheme,andplannedfeatureset.Releasedatescanbelinkedtoevents,likeconferencesorcompliancerequirements.Inreleaseplanningthetargetscopeisagreeduponandtheprioritizedlistoffeaturerequests,suchasaproductbacklog,isusedasthebasisforplanning.
2.4.3 Iteration Planning
Manyagileteamsworkinfixedtimewindowscalledsprintsoriterations.Aniterationplanningeventisheldat,orshortlybefore,thestartofeachiteration.Priortothatiterationplanningmeeting,theitemsinthefeaturerequestlistthatarebeingconsideredforthe
22 Agile Extension to the BABOK® Guide
Levels of Planning in Agile Approaches Business Analysis in Agile Approaches
ComplimentaryMemberCopy.NotforRedistributionorResale.
iterationneedtobesufficientlyunderstood,thusenablingtheteamtoresponsiblymakeacommitment.InScrumthisisknownasgroomingthebacklog.IncontinuousflowmodelslikeKanban,thefeaturerequestlistisstillgroomedbeforeitiscommitted,buttheplanningcadenceisbasedondemand,notonadefinedtimeperiod.Onsometeams,thecustomerorowneroftheproductcollaborateswiththedeliveryteamtogroomtherequestlistpriortoiterationplanning,whileotherteamsuselow‐fidelityspecificationsdevelopedduringworkshopsheldpriortoiterationplanning.Thisworkiscomprisedofrequirementcommunicationandanalysis,withadditionalelicitationanddocumentationasneeded.
Initerationplanningtheworkthatwillbeperformedinthesprintisidentified,estimated,reviewed,andcommittedtobecompleted.Thedeliveryteammeetswiththecustomerortheowneroftheproducttounderstandtherequirementsandacceptancecriteria,andtogainclarityonspecifications.Thisisanalogoustotheworkinaplan‐drivenprojectwherethebusinessanalystcommunicatesrequirementstostakeholders.Attheendofiterationplanning,thedeliveryteamcommitstodeliveringanincrementofworking,tested,anddeployablecode.
Afteraniterationhasbeencompletedaniterationrevieworproductdemonstrationisheld.Theresultsoftheproductdemonstrationfeedintothenextcycleofiterationplanning.Theproductdemonstrationmeetingissimilartolight‐weightuseracceptancetestingandisgenerallylimitedtoamaximumof4hours.
Duringtheproductdemonstration
• thedeliveryteamdemonstrateshowthecodethatwasdevelopedmeetstheacceptancecriteria,
• theowneroftheproductdetermineswhichitemsonthefeaturelisthavebeencompletedintheiteration,
• anynewrequeststhatarisefromthecustomerasaresultofviewingthelatestproductareaddedtothefeaturerequestlist,and
• theowneroftheproductanddeliveryteamreviewthestateofthebusiness,themarket,andthetechnology,andre‐prioritizethefeaturerequestlistforthenextiteration.
Aftertheiterationreviewmeetingtheprocessstartsupagain.Whileaworkingproductistheexpectedoutputofeachiteration,manyagileteamswillwaittoreleaseaproductuntilseveraliterationsworthofworkhavebeencompleted.Theteammustdeterminetheappropriatetrade‐offpointbetweenthecosttodeliverthelatestproductandthe
Agile Extension to the BABOK® Guide 23
Business Analysis in Agile Approaches Levels of Planning in Agile Approaches
ComplimentaryMemberCopy.NotforRedistributionorResale.
amountofneworimprovedfunctionalitythatwillbedeliveredtothecustomerbase.Iterationsproceeduntilenoughfeatureshavebeendonetocompleteorreleaseaproduct.
2.4.4 Daily Work Planning
Manyagileteamsperformdailyteammeetingstocoordinatethework.Thedailymeetingisusuallyafifteenminutemeetingdesignedtoclarifythestateofthework.
Duringthedailymeetingtheteam
• getsaglobalsnapshotoftheproject,• discoversanynewdependencies,• addressesanypersonalneedsofcommittedindividuals,and• adjuststheworkplantomeettheneedsofthedayandensuretheteamcandeliverontheiterationcommitment.
Frequentlythedialogueheldduringthismeetinguncoversitemsthatlackclarityorrequirefurtheranalysis.Theteamthenidentifiesaplanfordealingwiththeseimpedimentstotheproject.Thisoftenentailsassigningsomeonetodofurtherbusinessanalysisworkforelicitationandanalysisontheimpactedrequirements.
2.4.5 Continuous Activity Planning
Therearemanydynamicactivities,efforts,andchallengesthatariseduringtheplanningactivitiesofagileprojects.
Herearesomeguidingprinciplesthatthoseconductingbusinessanalysismayfindhelpful:
• Startwithvalueandkeeptheteamtruetovalue.Itisvitalthattheindividualholdingthebusinessanalysisroleispayingcloseattentiontotheproject'sbusinessvalue.
• Low‐fidelityartifactsserveasanenablerofbusinessvaluebycreatingcontextandgeneratingsharedunderstanding.However,theydonotreplace,oreventakeprecedenceovereffectivecollaborationandconversation.
• Businessanalysisisaboutfacilitatingdiscussionandunderstanding.Businessanalystsmaynotpossessthedepthof
24 Agile Extension to the BABOK® Guide
Levels of Planning in Agile Approaches Business Analysis in Agile Approaches
ComplimentaryMemberCopy.NotforRedistributionorResale.
understandingaboutthebusinessasdoesthebusinesssponsor,orasmuchabouttechnologyasthetechnologyteam.
• Operateinthebestinterestofthebusinessovertime.Responsiblybalancevalueandcapacitytodeliver.
• Identifyandcommunicatecompetingconcernsandgapsinunderstandingbetweenthebusinessandtechnology.Ensurethatcommonunderstandingisreached.
• Resourcesarelimitedandvaluable.Alwaysassistinmaximizingvalueovertime.
• Assisttheteamtotakeaction.Effectivelycommunicatewhatisrequiredwhentakingthenextsteps.Ensurethatfeedbackisclearlyunderstoodandactedonbytheteam.
• Deliverincrementallyanditeratively.Dothesmallest,simplestthingthatcouldpossiblywork.Iteratetoreachminimalvalue.Progressivelyelaborateinsmallpieceswhiletestingassumptionsandarticulatingclearacceptancecriteria.
• Producethesmallestamountofdocumentationthatmeetstheneedsoftheteamanddeliveritjustintime.
Agile Extension to the BABOK® Guide 25
ComplimentaryMemberCopy.NotforRedistributionorResale.
Mapping Agile Techniques to the
THREEChapterBABOK® Guide
ThefollowingareasofknowledgerepresentaselectionofpopularagilebusinessanalysistechniquesidentifiedthroughthedevelopmentoftheAgileExtensiontotheBABOK®Guide.ManyofthebusinessanalysistechniquesdescribedintheBABOK®Guidecontinuetobeusableinanagilecontext.Inaddition,theremayalsobeothertechniquesnotlistedhereorintheBABOK®
Guidethatmayprovetobeusefulandapplicableinaparticularsituation.TechniquesnotlistedintheAgileExtensiontotheBABOK®Guideshouldnotbediscreditedasvaluableinthecontextofperformingagilebusinessanalysis.
InthefollowingsectionwefocusourattentiononcommonbusinessanalysistechniquesapplicabletoagilethataresupplementaltothosedescribedintheBABOK®Guide.TheagiletechniquesthataremappedtoBABOK®KnowledgeAreasinthischapterareexplainedingreaterdetailinChapter4:Techniques.
3.1 Business Analysis Planning and MonitoringBusinessAnalysisPlanningandMonitoring(Chapter2oftheBABOK®Guide)describestheworkrequiredforabusinessanalysttodeterminetheactivitiesthatwillberequiredtoperformbusinessanalysisthroughthelifecycleofaproduct.Inagileapproaches,businessanalysisplanningcanbedoneup‐frontordeferreduntilworkonanactivityisreadytobegin.Somebusinessanalystswilldevelopaninitialplan,whichgetsupdatedpriortostartingeachnewactivitytoaccountforchangeandensuretheplanisalwaysuptodate.
3.1.1 Plan Business Analysis Approach (2.1)
Agileapproachesfallintothegeneralcategoryofchange‐drivenapproachesasdescribedintheBABOK®Guide.Somebusinessanalysisworkwillgenerallybeperformedupfronttodefineavisionfortheprojectandhowtheproblemoropportunitywillbeaddressed,butdetailedanalysiswillbeperformedas‐
26 Agile Extension to the BABOK® Guide
Business Analysis Planning and Monitoring Mapping Agile Techniques to the BABOK® Guide
ComplimentaryMemberCopy.NotforRedistributionorResale.
needed.Iftheproblemsthesoftwareissupposedtosolveareunclear,orseveralstakeholdergroupshaveconflictinginterests,itmaybenecessarytodobusinessanalysisworkpriortothebeginningofaproject.Thatup‐frontanalysiswillprovideabetterunderstandingofunderlyingproblems,theirdrivers,andthegoalsofthestakeholdersinordertoreachagreementonthevisionfortheproduct.Thisincludesasharedagreementontheproblemoropportunitytheproductisintendedtoaddress.Asaresult,theremaybeplannedbusinessanalysisactivitiesthataredefinedinthepre‐projectphase,inadditiontothebusinessanalysisactivitiesthataredefinedforeachcycleofwork,suchasforaniteration.
.1 Agile Techniques• BacklogManagement:Backlogmanagementistheprimarymethodofhandlingrequirementsplanning,prioritization,andchangemanagementinmostagileapproaches.Becausethebacklogoftendescribesthebreakdownofrequirementsintherelativeorderinwhichthefeaturesshouldbeimplemented,itcanserveasadescriptionfortheorderinwhichbusinessanalysisactivitieswilltakeplace.Somebacklogsalsoincludebusinessanalysisactivitiesastaskstobecompletedinadevelopmentcycle.
• PlanningWorkshop:Businessanalystsparticipateinplanningworkshopstodeterminethebusinessanalysiseffortandactivitiestosupportateamobjective.
• RealOptions:Realoptionanalysismayhelpdeterminewhenbusinessanalysisneedstobeconductedtoinvestigateaparticularbusinessissue.
• Retrospectives:Thefeedbackfrompriorretrospectivesshouldbeconsideredwhenselectingtheapproach.
Agile Extension to the BABOK® Guide 27
Mapping Agile Techniques to the BABOK® Guide Business Analysis Planning and Monitoring
ComplimentaryMemberCopy.NotforRedistributionorResale.
3.1.2 Conduct Stakeholder Analysis (2.2)
Stakeholdersmaybechallengedbytherapid,iterativedevelopmentfoundinanagileprojectandtheneedtobeoncallwheneverinformationisneededbytheteam.Inagiledevelopment,businessanalystsneedtoconsidertheimpactoftheagilecadenceonthestakeholderandhowthingslikeprogresselaborationwillaffectexpectations.Businessanalystsneedaskquestionssuchas,canthestakeholderparticipateinupdatingtheprocesses,interactions,andproductspecificationsduringthecourseoftheproject?Prototypingandfrequentfeedbackfromstakeholderscanhelptorefinewhatisknownabouttheneedsofastakeholderorstakeholdergroup
.1 Agile Techniques• CollaborativeGames:Manycollaborativegamescanbeusedtounderstandtheperspectivesofvariousstakeholdergroups.
• Personas:Personascanhelptheanalystordevelopmentteambyenablingthemtobetterdescribeandvisualizetheneedsofagrouporarchetypeofstakeholders,understandinghowthearchetypewillderivevaluefromasolution,potentialrisksforthearchetype,andotherinformationthatwillhelptheteamtobetterunderstandtheneedsofthestakeholdergroupsinvolvedwiththeproject.
3.1.3 Plan Business Analysis Activities (2.3)
Businessanalysisactivitiesareplannedasneeded,usuallyatthestartoftheprojectandrefinedwitheachiterationorwhenanewworkitemisreadyforanalysis.Thebusinessanalystshouldalwaysbeawareofandpreparedtoaddressthenextiterationofwork,keepingthevisionfortheproductandevolutionofincrementalvalueinmind.Thereislessofafocusonformaldocumentation(althoughitstillcanberequiredtomeetstatutoryorregulatoryrequirements,ortocaptureknowledgedevelopedduringtheanalysisanddevelopmentprocess)andmorefocusonprogressiveelaborationofdocumentationthroughoutthelifeoftheproject.Also,muchoftheelaborationisreplacedbyinteractionsandceremonysotheseoutcomesneedtobeaccomplishedwithactivitiesaddressedinthecommunicationplan.
.1 Agile Techniques• PlanningWorkshop:Decisionsregardingbusinessanalysisactivitieswillusuallybemadeduringaplanningworkshop.
28 Agile Extension to the BABOK® Guide
Business Analysis Planning and Monitoring Mapping Agile Techniques to the BABOK® Guide
ComplimentaryMemberCopy.NotforRedistributionorResale.
3.1.4 Plan Business Analysis Communication (2.4)
Duringdevelopment,formalcommunicationofrequirementsisgenerallyreplacedwithad‐hocinformaldiscussionsandmodeling.Somedeliverablesarereplacedbyspecificinteractionsorceremonies.Bydefinition,theseinteractionsandceremoniesrequirereal‐timeparticipationbythebusinessanalyst.Formaldocumentationmaybedevelopedfollowingdevelopmentofthesoftwaretoensureknowledgeretentionbytheorganizationortomeetregulatoryrequirements.
.1 Agile Techniques• Personas:Thesemayproveusefulinassessingtheneedsandavailabilityofthestakeholdergroupsforthenecessarycommunicationinanagileapproachandhowyouwillorganizethisagilecommunication.
• PlanningWorkshop:Theplanningworkshopisgenerallyusedastheforumforestablishinghowtheteamwilloperate,includingdecisionsabouthowtheresultsofbusinessanalysisactivitieswillbedeliveredandcommunicatedtotheteamthroughoutthecourseoftheproject.
3.1.5 Plan Requirements Management Process (2.5)
Inagileapproaches,requirementsmanagementisfocusedonensuringthattheintakeofnewworkbytheteammatchestheprioritiesofthestakeholdersand/orsponsor,anddeliversvaluetothebusiness.Agileapproachesstresstheimportanceofwelcomingchangingrequirements.Thismeansthattheorderingofworkitemsthatarereadyfordevelopmentmaybechangedatanytime.
.1 Agile Techniques• BacklogManagement:Mostagileapproachesusebacklogmanagementtodeterminewhichrequirementsarereadytobeworkedonbythedevelopmentteam.
Agile Extension to the BABOK® Guide 29
Mapping Agile Techniques to the BABOK® Guide Elicitation
ComplimentaryMemberCopy.NotforRedistributionorResale.
3.1.6 Manage Business Analysis Performance (2.6)
Thisactivitywillbeperformedonanongoingbasisasthebusinessanalystlearnstoworkeffectivelywithstakeholdersandthedevelopmentteam.Aseveryoneinvolvedbetterunderstandshowtoworktogethertodelivervalue,thebusinessanalysisprocess,methods,ortechniquesinusemayneedtochange.Effectivebusinessanalysisperformancewillresultinlimitedreworkoftherequirementsdocumentation,effectiveprioritizationandscopingofrequirements,andclearcommunicationofneedtothedevelopmentteam.
.1 Agile Techniques• Retrospectives:Retrospectivesareacommonpracticeusedbyagileteamsseekingtoimprovetheirwaysofworking.Businessanalystsshouldlookforfeedbackontherequirementstheyprovidetotheteamandhowandwhenthoserequirementsareprovidedinordertofindwaystoimprovetheirprocesses.
• ValueStreamMapping:Valuestreammappingcanbeusefulinassessinghowbusinessanalysisactivitiesarecontributingtothedeliveryofvaluetothecustomerandidentifyingactivitiesthatmaynotbeaddingvalue.
3.2 ElicitationElicitation(Chapter3oftheBABOK®Guide)describeshowbusinessanalystsworkwithstakeholderstoidentifyandunderstandtheirneedsandconcernsandunderstandtheenvironmentinwhichtheywork.Effectiveelicitationensuresthatthestakeholders'actualunderlyingneedsareunderstood,ratherthanstatedorsuperficialdesires.Elicitationisongoingthroughouttheprojectandperformedinconjunctionwithanalysisactivities(ascomparedtotraditionalapproaches,whereitispossibletoperformelicitationasadistinctactivityorphase).
Onagileprojects,themostcommonpatternisaninitialelicitationactivitywhichlooksatthehighlevelneeds,goals,andscopeofthesolution.Ineveryiteration,thereismoredetailedelicitationfortheuserstorieswhichconstitutethebacklogitemsforthatiteration.
30 Agile Extension to the BABOK® Guide
Elicitation Mapping Agile Techniques to the BABOK® Guide
ComplimentaryMemberCopy.NotforRedistributionorResale.
3.2.1 Prepare for Elicitation (3.1)
Preparingforelicitationchangesduringthelifeoftheproject.Earlyon,itisdonebythebusinessanalysttocoordinatesupportingmaterialsandscheduleresourcestodefinethehigh‐levelrequirements.Duringthisphaseoftheproject,elicitationactivitieswillgenerallybestructuredasmoreexploratorysessionstounderstandunderlyingneeds,buildouttheinitiallistoffeaturerequests,anddeterminewhatismostvaluabletoworkon.Astheprojectprogresses,workiscoordinatedbyprioritizationofthebacklog.Thiswilloftenresultinmorestructuredanddirectedelicitationsessionsdesignedtounderstandlow‐leveldetailsofaparticularfeatureorrequirement.Stakeholdersmayworkdirectlywiththedeveloperstoelaboraterequirements.Inthatsituation,thedeveloperisperformingbusinessanalysisactivitiesfortheprojectandshouldbetrainedingoodbusinessanalysispractices.Wherethisisnotpossible,thebusinessanalystwilloftenactasaproxy.Thistaskrequirestheschedulingofresourcesandthecoordinationofinputstoalignwiththeprogressiveelaborationofthebacklog.
Inpreparationforelicitationactivities,itisrecommendedthatthebusinessanalystperformcustomerresearchandastakeholderanalysistounderstandtheneeds,wants,andpreferencesofthestakeholderstheywillbeworkingwith.Bytailoringelicitationdiscussionstothestakeholder,businessanalystscanmaximizetheefficiencyandvalueoftheelicitationsession.
.1 Agile Techniques• Personas:Personasmayprovideinsightintotheparticularneedsofastakeholderorthetechniquesthatwillbemosteffectiveinunderstandingthoseneeds.
• UserStory:Auserstorywillidentifytheroleforwhomthestoryprovidesvalue(andthereforeidentifythestakeholderswhocanelaborateonthatvalue).
• StoryMapping:Developingauserstorymapwithusersandotherstakeholderswillensurethestoriesimplementedinthesolutionwillcometogetherasacohesiveproductintheend.
Agile Extension to the BABOK® Guide 31
Mapping Agile Techniques to the BABOK® Guide Elicitation
ComplimentaryMemberCopy.NotforRedistributionorResale.
3.2.2 Conduct Elicitation Activity (3.2)
Elicitationactivitiesareconductedonafrequentbasisthroughouttheproject,possiblyevendaily.Earlyon,elicitationisperformedtodefinehigh‐levelrequirementsoravisionfortheproduct.Astheprojectprogresses,stakeholdersinteractwiththedevelopmentteamdirectlyduringiterationplanninganddevelopment.Theintentofallelicitationactivitiesistogeneratejustenoughdetailtoensurethattheworkathandisperformedcorrectly.Theseelicitationactivitiesoftenoccurinworkshopswithproductusersandotherstakeholderswhohaveavestedinterestinthefeaturesorrequirementsbeingdiscussed.
.1 Agile Techniques• BehaviourDrivenDevelopment(BDD):Stakeholdersmayfinditeasiertoarticulatetheirneedsbyprovidingexamplesratherthanthroughabstractmodels.
• CollaborativeGames:Collaborativegamesencourageparticipantsinanelicitationactivitytocollaborateinbuildingajointunderstandingofaproblemorasolution.
Note:Asmentionedabove,analysisisusuallyperformedduringelicitationsessions.MostofthetechniquesfoundintheAgileExtension,aswellasmanyofthetechniquesintheBABOK®Guide,aresuitableforthispurpose.
3.2.3 Document Elicitation Results (3.3)
Amajorvalueofdocumentationisthatitcanbeusedforlong‐termknowledgeretention.Agileapproachesaimtominimizethetimebetweenthedevelopmentofrequirementsandtheirimplementationinsoftware,reducingtheoverallvalueofthatdocumentationtotheteam.Recordsofelicitationactivitiesshouldbekepttoensurethatkeydecisionscanbeunderstoodatalaterdate,ortoensurethatregulatoryorgovernancerequirementsaremet.Itisimportanttonotethatdocumentationshouldnotbelimitedtopurelytextualartifactstorepresentrequirementsandcontextforrequirements.Visualizingrequirementsthroughmodels,mock‐ups,andprototypesanbeaquickmechanismforconveyingalargeamountofinformationaboutasolution.However,careshouldalsobetakenwhenusingvisualizationsthatmimicthesolution,asitisimportanttodefinerequirementswithoutunnecessarilylimitingthesolutionoptions.
32 Agile Extension to the BABOK® Guide
Requirements Management and Communication Mapping Agile Techniques to the BABOK® Guide
ComplimentaryMemberCopy.NotforRedistributionorResale.
.1 Agile Techniques• LightweightDocumentation:Seethissectionforguidelinesondevelopingdocumentation.Inmostcases,therewillnotbeseparatedocumentationoftheelicitationandanalysiswork.
3.2.4 Confirm Elicitation Results (3.4)
Thiswillbeperformedbytheteamduringiterationplanning,throughoutthedevelopmentiteration,andatcustomeracceptance.Thecustomermaychangetheirmindaboutsomespecificelementofastoryafterseeingtheresult.Thisfeedbackbecomesaninputintotheconductelicitationactivity.
.1 Agile Techniques• BehaviourDrivenDevelopment(BDD):Elicitationoutcomeswillfrequentlybecapturedintheformofacceptancecriteriathatwillbeusedbytheteamtoverifythatthesoftwaremeetsstakeholderneeds.Inbehaviourortestdrivendevelopment,examplesareoftenusedasthebasisforgeneratingacceptancecriteriathatcanbeusedtoconfirmelicitedrequirements.
• Retrospectives:Duringretrospectivesessions,theinformationthatwaselicitedmaybeconfirmedorrefutedbasedontheperspectivegeneratedwhenacustomerseestheproductinaction.Thismayresultinmodificationstothesolutionrequirements.
3.3 Requirements Management and CommunicationRequirementsManagementandCommunication(Chapter4oftheBABOK®Guide)describeshowbusinessanalystsmanageconflicts,issues,andchangesinordertoensurethatstakeholdersandtheprojectteamremaininagreementonthesolutionscope,howrequirementsarecommunicatedtostakeholders,andhowknowledgegainedbythebusinessanalystismaintainedforfutureuse.Thisisnotaone‐timeactivity,butisperformedcontinuouslythroughoutthelifeoftheproject.
Agile Extension to the BABOK® Guide 33
Mapping Agile Techniques to the BABOK® Guide Requirements Management and Communication
ComplimentaryMemberCopy.NotforRedistributionorResale.
3.3.1 Manage Solution Scope and Requirements (4.1)
Asagileprojectsunfold,thescopeisdefinedwithincreasingspecificity.Dependingontheagileapproachbeingused,thespecificdetailsofthescopecanbefoundintheproductbacklogorasimilardocument.Contentfortheproductbacklog,userstories,orotherrequirementsdocumentationmanagedintheseactivitiesisgeneratedthroughelicitationactivities,whicharementionedintheprevioussection.Basedonthelevelofelaborationtheproductbacklogitselfmayvaryinitsownlevelofdetail.Itshouldalsobeconsideredthatthesponsormaydecidetoterminatetheprojectshouldtheydecidethatfurthereffortswillnotprovideanacceptablereturnofbusinessvalue.
.1 Agile Techniques• BacklogManagement:Mostagileteamsusetheproductbacklogtomanagebothsolutionscopeandrequirements.
• StoryDecomposition:StoryDecompositionenablesplanningattheappropriatelevelofgranularityandsupportsthejust‐in‐timenatureofagileapproaches.
3.3.2 Manage Requirements Traceability (4.2)
Onagileprojects,everythingisconnectedbacktothestrategicthemes,epics,andstoriesthatareusedtodefinetheproject.Thisismaintainedbytheproductownerorthebusinessanalyst.
.1 Agile Techniques• StoryDecomposition:Whenstoriesaredecomposedintosmaller,moregranularpieces,retainingthelargerepicorfeatureandtieingthedecomposedstorytoitslarger,parentconceptcanhelpcreaterequirementstraceability.
• StoryMapping:Whilestorymapsprimarilyshowrelationshipsbetweenuserstories,indicatingaprocessorflowofactivities,theyalsomapuserstoriestolargeractivitiesthattheusermustbeabletoaccomplish.Assuch,storymappingcanserveasatooltoprovidetraceabilitybetweenrelatedstoriesandbetweenstoriesandthelargeractivitiestheysupport.
34 Agile Extension to the BABOK® Guide
Requirements Management and Communication Mapping Agile Techniques to the BABOK® Guide
ComplimentaryMemberCopy.NotforRedistributionorResale.
3.3.3 Maintain Requirements for Reuse (4.3)
Inmatureagileorganizationsthishappensmuchthesamewayasitdoesintraditionalefforts,wheredocumentationandprototypesareretainedforthefuturedevelopmentoftheprojectorreusedonsimilar,relatedefforts.Thedifferenceisinthewaythatrequirementsaredocumentedthroughoutthelifeoftheprojectorattheendoftheproject.Inadditiontoproductbacklogs,userstories,andotherstandardrequirementsdocumentation,thesourcecodeitselfisoftenwrittentobeself‐documenting.Informationregardingtherequirementsthecodesatisfiescanbeincludedinthenotesthedeveloperscreateforthesourcecode.
.1 Agile Techniques• UserStory:Awelldocumenteduserstorycanberetainedandre‐usedasastartingpointforfuturerefinementsoftheproductorsimilarneedsforanotherproduct.
3.3.4 Prepare Requirements Package (4.4)
Preparingtherequirementspackagecanbehandledthroughtechniquessuchasscenarios,usecases,acceptancetests,mock‐ups,andmodelsassociatedwiththethemes,epics,andstoriesusedtodefinetheproject.Thisisanongoingactivitythroughthelifeofthedevelopmentofthesolution.Thespecifictechniquesusedwilldependupontheapproachchosenatthebeginningoftheproject,andwillchangebasedontheemergentunderstandingofwhatworksbestinthecontextoftheproject.Releaseplanningoftenhelpstoguidehowrequirementsshouldbepackagedbyunderstandinghowtheteamisproposingtobundlefeaturesinplannedproductreleases.
.1 Agile Techniques• StoryDecomposition:Epics,features,orminimallymarketablefeatures(MMF)tiegroupsofuserstoriestogetherintolargerpackagesthatcanbediscussedwithstakeholders.
Agile Extension to the BABOK® Guide 35
Mapping Agile Techniques to the BABOK® Guide Enterprise Analysis
ComplimentaryMemberCopy.NotforRedistributionorResale.
3.3.5 Communicate Requirements (4.5)
Inagileprojectsrequirementsarecommunicatedtodevelopersonanon‐goingbasis.Requirementscommunicationmostoftenhappensinreleaseplanningmeetingswherethemesandstoriesarereviewedandselectedforrelease.Theyarealsodiscussedinmoredetailiniterationplanningmeetingswherethemodelsandspecificationsareselectedanddiscussedamongtheteamandtheproductowner.Intheseiterationplanningmeetings,risksarealsoreviewedanddiscussed.Additionally,dailyteammeetingsareoftenusedasanopportunityfordeveloperstogetclarificationoridentifyambiguousrequirements,wherethebusinessanalystcommunicatesthedetailsoftherequirementsorclarifiesambiguity.Modelsandvisualizationsforrequirementscanbeaquickwaytocommunicatedetailedrequirementsandfacilitateunderstandingoftheproblemthesolutionneedstosolve.
.1 Agile Techniques• PlanningWorkshop:Seethistechniqueforfurtherdetails.
3.4 Enterprise AnalysisEnterpriseAnalysis(Chapter5intheBABOK®Guide)describeshowbusinessanalystsidentifyabusinessneed,refineandclarifythedefinitionofthatneed,anddefineasolutionscopethatcanfeasiblybeimplementedbythebusiness.Thisknowledgeareadescribesproblemdefinitionandanalysis,businesscasedevelopment,feasibilitystudies,andthedefinitionofsolutionscope.Enterpriseanalysisisaboutidentifyingthebusinessneed,opportunityorproblemtobesolvedanddecidingontheappropriateapproachtoaddressingtheneed.
3.4.1 Define Business Need (5.1)
DefineBusinessNeed,asdescribedinBABOK®Guide,extendstoagileapproaches.
36 Agile Extension to the BABOK® Guide
Enterprise Analysis Mapping Agile Techniques to the BABOK® Guide
ComplimentaryMemberCopy.NotforRedistributionorResale.
.1 Agile Techniques• BusinessCapabilityAnalysis:Abusinessneedwillusuallycorrespondtothedevelopmentofanewcapabilityortheenhancementofanexistingcapability.
• CollaborativeGames:Somecollaborativegamescanbeusefulinexposingun‐metbusinessneeds.
3.4.2 Assess Capability Gaps (5.2)
AssessCapabilityGaps,asdescribedinBABOK®Guide,extendstoagileapproaches.
.1 Agile Techniques• BusinessCapabilityAnalysis:Thiscanbeusedtounderstandwhatshortcomingsexistinanexistingcapability.
3.4.3 Determine Solution Approach (5.3)
Agileisasolutionapproach.Itmaybeselectedinordertoprovideafasterdeliveryofvaluethantraditionalapproaches,orbecausetheproblemareaneedstobeexplored.Italsosupportsincrementaldeliverysothesolutionapproachcanbeevolvedoverthecourseoftheproject.Thisapproachprovidesflexibilityindeterminingthebestsolutiontoaproblemoropportunitybeingexplored.Asolutionmaybeginasacustomdevelopedevolutionaryprototype,thentransitiontoacustomizedCOTSsolutionorbecomeanintegratedpartofanotherproduct,forexample.Assuch,onagileprojectsthesolutionapproachcansometimeschangeduringthecourseofdevelopment.
.1 Agile Techniques• PurposeAlignmentModel:Thepurposealignmentmodelcanprovideguidanceregardingthebestsolutionapproachtotakeforagivenbusinessneed.
3.4.4 Define Solution Scope (5.4)
Thescopeofagileprojectsevolvesduringthecourseoftheprojectastheteamlearnsmoreaboutwaystosolvetheproblemandthecustomerpreferencesforasolution.Thescopeisdefinedinhigher‐
Agile Extension to the BABOK® Guide 37
Mapping Agile Techniques to the BABOK® Guide Enterprise Analysis
ComplimentaryMemberCopy.NotforRedistributionorResale.
levelabstractions(suchasthemesandepics)andisdetailedastheprojectevolves.Thesehigher‐levelabstractionsareimportantforscopingthesolutionandenablingtheteamtocomeupwithaninitialvisionforthearchitectureandreleaseplanfortheproduct.Thisisoftenaniterativeprocess,asscopemayberefinedbasedonwhatistechnicallyfeasibleinaninitialarchitectureassessment,impactingthereleaseplanandprojecttimelines.Similarly,thearchitectureplanmaybemodifiedorcontainaphasedapproachtobuildingouttheinfrastructurebasedontheplannedhigh‐levelrequirementsthatwillbedeliveredintherelease.
.1 Agile Techniques• BusinessCapabilityAnalysis:Thescopeoftheprojectshouldberelatedtothebusinesscapabilitiesitiscreatingorenhancing.
• StoryDecomposition:Epicsandfeaturescanserveasthebasisfordefiningthescope.
• StoryMapping:Astorymapcanbeusedtoseetherelationshipbetweenthevariousstoriesdeliveredbytheproject.
3.4.5 Define Business Case (5.5)
Thebusinesscaseforagileprojectsistypicallybasedonachievingaspecificbusinessoutcomewithinaspecifiedcostandtime.Thebusinesscaseisrevisitedfrequentlyastheteamlearnswhatitcandeliver,howwellitmeetsthereal(notperceived)needs,andwhetherthebusinessoutcomeandintendedvaluecanbeachievedwithinthespecifiedcostandtime.
.1 Agile Techniques• BusinessCapabilityAnalysis:Definesthecustomerandorganizationalvalueassociatedwithabusinesscase.
• KanoAnalysis:Identifieswhichproductfeaturesarelikelytohavethegreatestmarketimpact.
• PurposeAlignmentModel:Identifieswhatkindofinvestmentislikelytogeneratethegreatestvaluefortheorganization.
• RealOptions:Allowsassessmentofwheninvestmentneedstobemadeinordertoensurevalueisobtained.
38 Agile Extension to the BABOK® Guide
Requirements Analysis Mapping Agile Techniques to the BABOK® Guide
ComplimentaryMemberCopy.NotforRedistributionorResale.
3.5 Requirements AnalysisRequirementsAnalysis(Chapter6intheBABOK®Guide)describeshowbusinessanalystsprioritizeandprogressivelyelaboratestakeholderandsolutionrequirementsinordertoenabletheprojectteamtoimplementasolutionthatwillmeettheneedsofthesponsoringorganizationandstakeholders.Itinvolvesanalyzingstakeholderneedstodefinesolutionsthatmeetthoseneeds,assessingthecurrentstateofthebusinesstoidentifyandrecommendimprovements,andtheverificationandvalidationoftheresultingrequirements.
3.5.1 Prioritize Requirements (6.1)
Onagileprojectsrequirementsareprogressivelyelaborated.Inotherwords,throughouttheelicitationtaskelicitationresultsareprogressively,orcontinually,brokendownandelaborated.Thisissimilartotheconceptofcontinuousimprovement,wherethebusinessanalystcontinuallyelaboratesontherequirementstoprovideadditionaldetailasneededandidentifiesnewrequirementsthatareprioritizedbasedontheintendedprojectoutcomes.Ateachpointofelaborationtheconstituentpartsneedtobeevaluatedandprioritizedbasedonbusinessvaluecontributionandriskburn‐down.Inagilethisisnotaone‐timeupfrontactivity.Thishappensthroughoutthelifeoftheprojectonallremainingworkandnewworkbroughtinfromlearningabouttheproduct.
.1 Agile Techniques• BacklogManagement:Backlogmanagementisthestandardmethodofprioritizingrequirementsinmanyagileapproaches.Thebacklogcanbere‐prioritizedwheneverbusinessneedschangeorarebetterunderstood.
• KanoAnalysis:Kanoanalysiscanprovideinsightintotherelativeimportanceoffeaturestoausergroup.
• PlanningWorkshop:Prioritizationnormallytakesplaceduringaplanningworkshop.
Note:alsoseetheexpandedtreatmentofMoSCoWPrioritization.
Agile Extension to the BABOK® Guide 39
Mapping Agile Techniques to the BABOK® Guide Requirements Analysis
ComplimentaryMemberCopy.NotforRedistributionorResale.
3.5.2 Organize Requirements (6.2)
Duetothejust‐in‐time,continualnatureofrequirementselicitationanddocumentationactivities,itisimportanttothinkabouthowrequirementswillbeorganizedforanagileproject.Forexample,userstoriescanoftenshowupinmultipledocumentsthatarededicatedtotheuserstorythattheydescribe.Asaresultitcanmakefindingtheappropriaterequirementsacumbersomeactivity.Whiledocumentationonagileprojectsshouldbelightweight,itisstillimportanttohavearequirementsmanagementplanandmethodfororganizingrequirementsthatcanbeusedbyprojectteammembersandotherstakeholders.
Inagile,itcanbevaluabletoorganizerequirementstominimizedependenciesbetweenfeaturesets.Thisreducescomplexityandriskandimprovestestabilityatthebusinesslevelvalue.Organizingrequirementsaroundbusinessvalueandprogressivelyelaboratedrequirements,asopposedtotechnicalimplementations,resultsinthesolutionbeingarchitectedfromabusinessstandpoint.Exceptionsdoexistonprojectssuchascomponentteams,wherethebusinessvaluearisesfromdeliveringenablingtechnology.Eventhen,theserequirementsneedtobeprioritizedandfilteredbasedonriskburn‐downandbusinessvaluecontribution.Storymapswithinepicscanbeusedasamethodtoorganizerequirements.
.1 Agile Techniques• StoryDecomposition:Individualstoriesmaybeorganizedaroundanepicorfeature,wheretheepicsand/orfeaturesareusedastheorganizationalmethod.
• StoryMapping:Storymappingalsoshowshowindividualstoriesarerelatedtoorsupportoneanother.Thismaybeusedasamethodfordeterminingrelatedstoriesandorganizingthosestoriesandtheirassociatedrequirementsbasedonthoserelationships.
3.5.3 Specify and Model Requirements (6.3)
Atdifferentlevelsofelaborationtherearedifferentmethodsforspecifyingandmodelingrequirements.Theapproachshouldsupportprogressiveelaboration,beadaptabletochangebasedonlearning,andnotcausetheteamtoselectsolutionstooearly.Itshouldalsoensurethatintentandintendedbusinessvaluearecommunicated
40 Agile Extension to the BABOK® Guide
Requirements Analysis Mapping Agile Techniques to the BABOK® Guide
ComplimentaryMemberCopy.NotforRedistributionorResale.
consistentlythroughtheelaboration.Agileteamstendtousestoriesandtasksatthelowestlevelofdecomposition.Thesestoriesandtaskscanbesupportedbydetaileddocumentationandusecases.Itisbecomingincreasinglycommonforacceptanceteststobeproducedaspartofspecifyingandmodellingtherequirements.
.1 Agile Techniques• BehaviourDrivenDevelopment(BDD):Concreteexamplesoffunctionalitymayhelpstakeholdersbetterspecifyandunderstandtheirneeds,ordealwithspecificscenariosthatareofgreatervalue.
• Storyboarding:Usedtodescribeuserinterface(UI)functionalityandbehaviour.
Note:alsoseetheexpandedtreatmentofUserStoryinthisextension.
3.5.4 Define Assumptions and Constraints (6.4)
Onagileprojectsdefiningassumptionsandconstraintsishandledthroughariskmanagementapproach.Forexample,someagileteamstreatrisksasstorieswithinthemessothattheycanbetrackedwiththefeaturesorepicstheypertainto.Riskmitigationactivitieswouldthenbeprioritized,burneddown,andthenre‐prioritizedasthestoriesareperformed.Thisistypicallyproducedbytheindividualsperformingthebusinessanalystandprojectmanagerfunctions,alongwiththesupportoftherestoftheteam.Prioritizationwouldthenbeperformedbytheproductownerorsomeoneinananalogousrole.
.1 Agile Techniques• LightweightDocumentation:Assumptionsandconstraintscanbedocumentedinlightweightdocumentationthatiscreatedbytheprojectteamasitprogresseswiththeproject.
• Personas:Personascanbeusedasawaytotrackrisksassociatedwithaparticularusergrouporstakeholdertypethattheproductteamshouldbeawareofduringdevelopment.Personascanalsobeoptionallymodifiedtoincludeinformationregardinganyassumptionsmadeaboutastakeholdertypeduringthestakeholderanalysis.
• UserStory:Userstoriescanbemodifiedtotrackassumptionsorconstraints(particularlythelatter)relatedtoastory.Teamcanalsousetheuserstoryformatasawayofcollectingriskstobeaddressedbytheteamasanoutstandingworkitem,althoughit
Agile Extension to the BABOK® Guide 41
Mapping Agile Techniques to the BABOK® Guide Requirements Analysis
ComplimentaryMemberCopy.NotforRedistributionorResale.
needstobecleartotheteamandstakeholdersthattheseareseparatefromthestoriesplannedfordevelopment.
3.5.5 Verify Requirements (6.5)
Verificationensuresthatsomethinghasbeendesignedtospecificationandadheringtoqualitystandards.Forexample,verifyingthatauserstoryorotherrequirementsdocumentisproperlystructured,containstheappropriatefields,andcontainstheappropriatelevelofdetail.Requirementsareverifiedbytheteamthroughoutthecourseoftheproject.Throughretrospectivesandoperationsreviews,theteammaydecidetomodifythelevelofdetailoftherequirementsorthemethodofspecifyingandmodelingrequirementstoimprovetheperformanceoftheteam.Verificationofrequirementsusuallyisdonethroughdirectstakeholderinteractionwiththeteamasthesoftwareisdeveloped,elicitingdirectfeedbackfromtheteamduringretrospectives,dailyteammeetings,orothermeetingsorworkshops.
.1 Agile Techniques• Retrospectives:Retrospectivesproviderapidfeedbackonwhathasbeenbuilttoverifythatwhathasbeenbuiltwillmeetthedesiredbusinessoutcomes.
• StoryMapping:StoryMappingisatechniquethatenablesconfirmingthattheselecteduserstorieswillactuallydeliverthedesiredbusinessoutcomes.
3.5.6 Validate Requirements (6.6)
Validationensuresthatadeliverableorproductactuallyfulfillsitsintendedpurpose.Forexample,validatingthatauserstoryadequatelydescribesthebusinessprocessoractivitythatitisintendedtodescribe.Requirementsarevalidatedthroughoutthedevelopmentanddeliveryofthesolutionthroughcontinualinvolvementwiththecustomerand,whereapplicable,theproductowneroranalogousrole.Thishappensatmanypointsduringtheproject,suchasreleaseplanning,iterationplanning,duringdevelopment,andatcustomeracceptance.Prototypescanalsobeaneffectivewaytovalidatetheutilityoffunctionalityrelativetoitsintendedpurposebygivingausersomethingtotestandtryearlyindevelopmentwithproductreviewsessionstoobtainfeedbackfromtheusersontheevolutionoftheprototype.
42 Agile Extension to the BABOK® Guide
Solution Assessment and Validation Mapping Agile Techniques to the BABOK® Guide
ComplimentaryMemberCopy.NotforRedistributionorResale.
.1 Agile Techniques• BehaviourDrivenDevelopment(BDD):InBehaviourorTestDrivenDevelopment,examplesareusedasameansfordesignedrequirementsandestablishingacceptancecriteriathatcanbeusedtodesignthesolution.Theabilitytomeetthesereal‐worldexamplescanserveasameanstovalidatesolutionrequirements.
• Retrospectives:Retrospectivesessionsenablecustomerstoassessthesolutionasitisbeingdevelopedtovalidatewhetherornotitisontracktoorsuccessfullymeetstheirneeds.
3.6 Solution Assessment and Validation
SolutionAssessmentandValidation(Chapter7oftheBABOK®Guide)describeshowbusinessanalystsassessproposedsolutionstodeterminewhichsolutionbestfitsthebusinessneed,identifygapsandshortcomingsinsolutions,anddeterminenecessarywork‐a‐roundsorchangestothesolution.Italsodescribeshowbusinessanalystsassessdeployedsolutionstoseehowwelltheymettheoriginalneedsothatthesponsoringorganizationcanassesstheperformanceandeffectivenessofthesolution.
3.6.1 Assess Proposed Solution (7.1)
Inagileprojectssolutionassessmentoccurscontinuallyasthesolutionisbuiltandrefined.Initialsolutionsoptionsareidentifiedup‐front,withdecisionsthatserveasastartingpointforcontinualevolutionoftheproduct.Throughoutthelifeoftheproduct,asthebusinessneedsevolveorbecomemorewelldefined,theteam'sunderstandingoftheproblem'ssolutionwillalsoevolve.Witheffectiveagilearchitectureanddesign,thecostofredoingcomponentsthathavealreadybeendevelopedcanberelativelylow.Withanagilecadence,assessingtheproposedsolutionbecomesanongoingassessmentofthesolutionoptionsagainstthebusinesscaseandcurrentstatusoftheproject.
.1 Agile Techniques• RealOptions:Allowsforassessmentofaspectsofthesolutiontodeterminewhendecisionshavetobemaderegardingaparticularproposal.
Agile Extension to the BABOK® Guide 43
Mapping Agile Techniques to the BABOK® Guide Solution Assessment and Validation
ComplimentaryMemberCopy.NotforRedistributionorResale.
3.6.2 Allocate Requirements (7.2)
Onagileprojects,requirementsallocationisdonebyallocatingrequirementsintogroupsorcategories.Thiscanbedonebylookingforthemesamongstproposedpiecesoffunctionalitythatcontributetooneormorefeatures.Agileteamsaretypicallysmallteamsandthisallocationshapesthedesignofthedeliveryorganizationitself.Featureteamsformaroundthefeaturesandcomponentteamssupportingcross‐featurerequirements.
.1 Agile Techniques• StoryDecomposition:Breaksdownhigh‐levelepicsandfeaturesintosmallersupportingstorieswhichcanbeallocatedtodifferentcomponents(includingprocessororganizationalchanges).
3.6.3 Assess Organizational Readiness (7.3)
Theorganizationalreadinessassessmentoccursonagileprojectsinmuchthesamewayasitdoesintraditionalprojects.Thedifferenceisthatthereleasecadencecanbemorefrequent.Asignificantareatodefineinagileprojectsishowoftentheorganizationcanabsorbreleases.Organizationalreadinessshouldincludenotjusttheend‐user/customeroftherelease,butthesupportingorganizationaswell(forexample,support,training,sales,marketing,andaccounting).Anassessmentshouldbemadeofwhatisrequiredforasolutionreleasetodelivervaluebyconsideringthingssuchaswhethertheproductneedstobefullytestedandwhatfeaturesareminimallyrequiredtoachieveuptakeandvalueforcustomers.
3.6.4 Define Transition Requirements (7.4)
Thedeterminationoftransitionrequirementsoccursinanagileprojectmuchasitdoesinatraditionalproject.Theabilitytodelivervalueincrementallyopensupnewpossibilitiesfortransition.Unlikeamonolithicrelease,theorganizationalimpactcanbesmallerbutmorefrequent.Sincethecostofdevelopmentperunitislower,temporaryintegrationintoexistingsystemscanbedeveloped,whichmakestheneedforrunningparallelsystemslesssignificant.Transitionrequirementsforagileshouldprojectsshouldbetracked,ensuringthoserequirementsaremetinthedevelopment,operations,andsupportplansforeachdeliverycycleoftheproduct,asneeded.
44 Agile Extension to the BABOK® Guide
Solution Assessment and Validation Mapping Agile Techniques to the BABOK® Guide
ComplimentaryMemberCopy.NotforRedistributionorResale.
.1 Techniques• UserStory:Userstoriescanbeusedfortheplanningoftransitionrequirements,wheretheyareprioritizedand/ororderedinthesamefashionasuserstoriesforanyothersolutionrequirement.Userstoriescanbeaccompaniedwithalistofacceptanceteststhatcanbeusedtoassessiftheuserstoryhasbeensatisfiedintheresultingproduct.
3.6.5 Validate Solution (7.5)
Validationofasolutionhappensasanongoingeffortinanagileproject.Withineachiteration,thecustomerisprovidedwithdetailedfeedbackonthecurrentrequirements.Atthecompletionofeachiterationcycle,theproductownerfacilitatesalignmentwiththecustomerneedandcontinuedalignmentwiththebusinesscase.
.1 Agile Techniques• Retrospectives:Retrospectivesarereviewsthatexamineifthepieceoftheproducthasbeenbuiltinthecurrentiterationmeetstheactualbusinessneed.
3.6.6 Evaluate Solution Performance (7.6)
Uponrelease,theproductownerfacilitatestheunderstandingofhowwellthesolutionmeetstheneedsofthecustomer.Whilethebusinessanalystorproductownermayalsoassesstheutilityandperformanceofthesolutionduringanypointinthedeliverycycle,itisimportanttoalsopauseattheendofthedeliverycycletoassessthecurrentstateoftheproductinthecontextofthebusinessvalueitneedstodelivertoitsusers.Thebusinessanalystorproductownershouldensurecompleteditemsmeetexpectationsandidentifynewopportunitiestoaddvalueforthebusiness.Asnewitemsareuncoveredabusinessanalystorproductownershouldassessthenewrequestsagainsttheproductroadmapandbusinessrequirementstoassesstherelativevalueofthenewitem.Theincrementalnatureofthebacklogallowsnewhigher‐valueitemsdiscoveredduringthisevaluationtoenterintothebacklogaheadofexistingitems.Thisislikelytocreatechangestoplansforsubsequentdeliverycycles;however,italsohelpstoensurethefeaturesofthehighestvaluearedeliveredfirsttoshortentimetodelivervaluetothecustomer/user.
Agile Extension to the BABOK® Guide 45
Mapping Agile Techniques to the BABOK® Guide Solution Assessment and Validation
ComplimentaryMemberCopy.NotforRedistributionorResale.
.1 Agile Techniques• BusinessCapabilityAnalysis:Allowsbusinessanalystsandstakeholderstounderstandtheimportanceandrelativeperformanceofabusinesscapability.
• ValueStreamMapping:Usedtoidentifythoseaspectsofthesolutionthataddvalueforcustomersandthosewhichdonotaddvalue.Thisassessmentbecomesthebasisforongoingimprovementefforts.
46 Agile Extension to the BABOK® Guide
Solution Assessment and Validation Mapping Agile Techniques to the BABOK® Guide
ComplimentaryMemberCopy.NotforRedistributionorResale.
Agile Extension to the BABOK® Guide 47
ComplimentaryMemberCopy.NotforRedistributionorResale.
FOURChapterAgile Techniques
4.1 A Context for Agile Business AnalysisThischapteroftheAgileExtensiontotheBABOK®Guideprovidesanalystswithtechniquesandtoolsthatwillassisttheminexcellingintheagileworld.Inorderforthetechniquesandskillspresentedinthissectiontobeappliedsuccessfully,therearesomefoundationalprinciplesthatneedtobeunderstood.Theseprinciplesaresupportedbyanumberofpracticaltechniquesthatcanbeusedbypractitionerswhentheyundertakebusinessanalysisonagileprojects.
Theprinciplesthatguidesuccessfulbusinessanalysiscanbecategorizedintotwodistinctframeworks:
• theDiscoveryFrameworkand• theDeliveryFramework.
TheDiscoveryFrameworkdealswiththewhatsandthewhysoftheproduct.Effectivediscoveryissupportedbythreeunderlyingprinciples:
• SeeTheWhole,• ThinkasaCustomer,and• AnalyzetoDetermineWhatisValuable.
TheDeliveryFrameworkdealswiththehowsandthewhensoftheproduct.Effectivedeliveryissupportedbyfourunderlyingprinciples:
• GetRealUsingExamples,• UnderstandWhatisDoable,• StimulateCollaborationandContinuousImprovement,and• AvoidWaste.
Pleasenotethattheseguidingprinciplesaremeantasaguideandnotnecessarilyashardandfastrules.Forexample,whileGetRealUsing
48 Agile Extension to the BABOK® Guide
A Context for Agile Business Analysis Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
ExamplesisincludedintheDeliveryFramework,thetechniquesdescribedinthisprinciplecancertainlyproveeffectivewithintheDiscoveryFrameworkaswell.
ThefollowingtableshowstheAgileExtensiontechniquesthatsupporteachprinciple.
TABLE 4.1 Agile Extension Techniques
Principles of Agile Business Analysis
The Discovery Framework Delivery Framework
See the Whole
Think as a Customer
Analyze to Determine
What is Valuable
Get Real Using
Examples
Understand What is Doable
Stimulate Collaboration
and Continuous
Improvement
Avoid Waste
Business Capability Analysis
Story Decomposition
Backlog Management
Behaviour Driven Development
Relative Estimation
Collaborative Games
Lightweight Documentation
Personas Story Elaboration
Business Value Definition
Planning Workshop
Retrospectives
Value Stream Mapping
Story Mapping
Kano Analysis
Real Options
User Story MoSCoW Prioritization
Storyboarding Purpose Alignment Model
Agile Extension to the BABOK® Guide 49
Agile Techniques A Note on Agile Extension Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.
4.2 A Note on Agile Extension TechniquesThetechniquesdescribedherehaveprovenvalueinsupportingagilebusinessanalysis,butwedonotclaimthatthislistisall‐inclusiveorinanywaycanonical.Thetechniquesherewereselectedbasedontheexperiencesoftheteammembers,andrepresentbothexpansionstoexistingcontentintheBABOK®Guideandnewtechniquesnotdescribedinthecurrentversion.FutureversionsoftheAgileExtensionwilllikelyincludenewtechniques,anditisalsopossiblethatsomeofthetechniqueslistedherewillberemoved.
Inaddition,manyofthetechniqueslistedheremayproveusefultobusinessanalysispractitionerswhoarenotworkingonagileteams.
Agileapproachestendtofocusoncontinuousimprovementintheirmethodsandtechnique.ThetechniquesintheAgileExtensiontotheBABOK®Guidewillberequiredtoreviewedandupdatedonaregularbasis.
4.3 BA Techniques Mapped to Agile GuidelinesThefollowingtablemapstechniquesasdescribedintheBABOK®Guidetotheprinciplesforagilebusinessanalysispresentedinthisdocument.
TABLE 4.2 Business Analysis Techniques Mapped to Agile Business Analysis Guidelines
Business Analysis
Technique
BABOK v.2
Chapter
See the
Whole
Think as a Customer
Analyze to Determine
What is Valuable
Get Real using
Examples
Understand What is Doable
Stimulate Collaboration
and Improvement
Avoid Waste
Acceptance & Evaluation criteria definition
9.1
Base lining 4.1.5.2
Benchmarking 9.2
Brainstorming 9.3
Business Rule Analysis
9.4
50 Agile Extension to the BABOK® Guide
BA Techniques Mapped to Agile Guidelines Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
Checklists 6.5.5.2
Coverage Matrix
4.2.5.1
Data Dictionary and Glossary
9.5
Data Flow Diagrams
9.6
Data Modeling
9.7
Decision Analysis
9.8
Document Analysis
9.9
Estimation 9.10
Feasibility Analysis
5.3.5.2
Focus Groups 9.11
Force Field Analysis
7.3.5.2
Functional Decomposition
9.12
Interface Analysis
9.13
Interviews 9.14
Lessons Learned Process
9.15
Metrics and Key Performance Indicators
9.16
MoSCoW Analysis
6.1.5.2
Non-functional Requirements Analysis
9.17
Observation 9.18
Business Analysis
Technique
BABOK v.2
Chapter
See the
Whole
Think as a Customer
Analyze to Determine
What is Valuable
Get Real using
Examples
Understand What is Doable
Stimulate Collaboration
and Improvement
Avoid Waste
Agile Extension to the BABOK® Guide 51
Agile Techniques BA Techniques Mapped to Agile Guidelines
ComplimentaryMemberCopy.NotforRedistributionorResale.
Organization Modeling
9.19
Problem or Vision Statement
5.4.5.2
Problem Tracking
9.20
Process Modeling
9.21
Prototyping 9.22
RACI Matrix 2.2.5.2
Requirements Documentation
4.4.5.1
Requirements for Vendor Selection
4.4.5.2
Requirements Workshops
9.23
Risk Analysis 9.24
Root Cause Analysis
9.25
Scenarios and Use Cases
9.26
Scope Modeling
9.27
Sequence Diagrams
9.28
Signoff 4.1.5.3
Stakeholder Map
2.2.5.3
State Diagrams
9.29
Structured Walkthrough
9.30
Survey/Questionnaire
9.31
SWOT Analysis
9.32
Timeboxing/Budgeting
6.1.5.3
Business Analysis
Technique
BABOK v.2
Chapter
See the
Whole
Think as a Customer
Analyze to Determine
What is Valuable
Get Real using
Examples
Understand What is Doable
Stimulate Collaboration
and Improvement
Avoid Waste
52 Agile Extension to the BABOK® Guide
BA Techniques Mapped to Agile Guidelines Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
User Stories 9.33
Variance Analysis
2.6.5.2
Vendor Assessment
9.34
Voting 6.1.5.4
Business Analysis
Technique
BABOK v.2
Chapter
See the
Whole
Think as a Customer
Analyze to Determine
What is Valuable
Get Real using
Examples
Understand What is Doable
Stimulate Collaboration
and Improvement
Avoid Waste
Agile Extension to the BABOK® Guide 53
Agile Techniques Guidelines for Agile Business Analysis
ComplimentaryMemberCopy.NotforRedistributionorResale.
4.4 Guidelines for Agile Business AnalysisThefollowing7guidelinesforpracticingbusinessanalysisinsideanagilecontext,arebasedonthevaluesandprinciplesoftheAgileManifesto.Togethertheseguidelinesembodythedisciplineofagilebusinessanalysis.
Theseguidelinesprovidevaluablecontextwhenapplyingthevarioustechniquesdescribedinthischapter:
• Inanagilecontext,businessanalysisviewstheentiresystemofpeople,process,andtechnologytofindwheretruevalueliesandtohelporganizationsmaximizethelikelihoodofdeliveringavaluableandvaluedsolution.
• Agileanalysispaysspecialattentiontothevoiceofthecustomertounderstandtheirvaluesandexpectations.
• Toconfirmwhatisvaluable,itiscommontouseconcreteexamplestobothelicitandvalidateproductneeds.
• Technologystakeholdersareempoweredbyeffectivelyanalyzedneeds.Ithelpsthemdeterminehowmuchworktheycandeliveratanygivenpointintime,identifyproductrequirementsoptions,andproviderecommendationstobusinesspartnersonsolutions.
• Facilitativetechniquesenableefficientandeffectivecollaborationandaccelerateateam'sabilitytodefineanddeliverproducts.
• Trustandsafetyareintegraltohealthyteamsandallowsthemtotransparentlyidentifyimprovementopportunities.Improvingbothproductandprocessisimperative;thereforeagileteamscontinuallystrivetogetbetter.
• Alwaysbeonthelookoutfor,andavoid,anythingwasteful.
Adoptingtheseguidelinesrequiresleveraging,extending,andadaptingfoundationalbusinessanalysistechniques.See“BATechniquesMappedtoAgileGuidelines”onpage49foramatrixofbusinessanalysistechniquesthatmayapplyinanagilecontext.
54 Agile Extension to the BABOK® Guide
The Discovery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
4.5 The Discovery FrameworkTheDiscoveryFrameworkdealswiththewhatsandthewhysoftheproduct.Effectivediscoveryissupportedbythreeunderlyingprinciples:
• SeeTheWhole,• ThinkasaCustomer,and• AnalyzetoDetermineWhatisValuable.
4.5.1 See The Whole
SeetheWholeisaconceptthatdescribestheneedtolookataproblemoropportunityinthecontextofthebigpicture,focusingonthebusinesscontextandwhyaprojectisbeingundertaken.Itdescribesnotjustwhatasystemisbuthowitwillbeused.Itisimportanttoassesshowthesolutionachievessomethingofvalueforitsrecipients.Thevaluecontextforthesolutioniscreatedbyunderstandingboththesolutionandthestakeholders,andthenarticulatingwhotheyareandhowtheywillfindvalueinthesolution.TheideasbehindSeetheWholeareinfluencedbysystemsthinking.
Onagileprojectsthereisahighriskofgettingmiredinthedetailsoneachiteration.Whendevelopingthebusinesscaseforasolutionandperformingiterationandreleaseplanningactivitiesitisimportanttomaintainthefidelityofthecontext.Bydoingsothecontextguidesthenextlevelofelaboration.Bythinkingaboutthestrategicoutcomeforthesolution,thedeliveryteammovesfromordertakerstoagroupthatdeliversbusinessvaluewithlesscodebloat,scopecreep,andnever‐endingprojecttime‐lines.Seeingthewholecreatessituation‐appropriatecontextandasharedunderstandingofthebusinessproblemthatneedstobesolved,whichinturnwillguidedecisionmaking.
Thefollowingsectionsdescribecommonlyusedtechniquesforthisprinciple:
• BusinessCapabilityAnalysis,• Personas,and• ValueStreamMapping.
Agile Extension to the BABOK® Guide 55
Agile Techniques The Discovery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
ThereareothertechniqueswithintheAgileExtensiontotheBABOK®Guide,theBABOK®Guide,andotheradhoctechniquesthatcanbeutilizedhereaswell.
.1 Business Capability Analysis
Purpose
Provideaframeworkforproductscopingandreleaseplanningby
• generatingasharedunderstandingoftheoutcomesofabusinessorproduct,
• identifyingalignmentwithastrategyandspecificperformancegaps,and
• providingascopeandprioritizationfilterthatisstableandhaslowfrictiontomaintainovertime.
Description
Businesscapabilityanalysisistheanalysisoftheperformanceandriskassociatedwithasetofbusinesscapabilitiestoidentifyspecificperformancegapsandtoprioritizethesebasedonbusinessvalueandrisk.Businesscapabilitiesdescribetheabilityofabusinesstoactonortransformsomethingthathelpsachieveabusinessgoalorobjective.Manyproductdevelopmenteffortsareanattempttoimprovetheperformanceofabusinesscapabilityortodeliveranewbusinesscapability.
Agileapproachescreateaframeworkthatfacilitatesfrequentre‐assessmentofbusinessneedsandvalue.Thedirectionofthebusinessandthegapsrequiredforthebusinesstomeetitsobjectivesmustberevisitedforeachiterationplanningsession,whichgenerallyoccursevery2‐4weeksinmostagilelife‐cycles.Thismeansthatanagileprojectteammustmaintainaconstantviewofthebusinesscapabilitiesthatarerequiredforthebusinesstobesuccessful,particularlythosethatareinscopefortheproductbeingdelivered.
Elements
Capabilities
Capabilitiesaretheabilitiesinabusinesstoperformortransformsomething.Capabilitiesshoulddescribethepurposeoroutcomeoftheperformanceortransformation,nothowtheperformanceortransformationisperformed.Itdescribesthewhat,asopposedtothe
56 Agile Extension to the BABOK® Guide
The Discovery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
how.Forexample,sendingafaxisnotacapability;notifyingthecustomeristhecapability.
Using Capabilities
Capabilitiesimpactbusinessvaluethroughincreasingorprotectingrevenue,reducingorpreventingcost,improvingservice,achievingcompliance,orpositioningthecompanyforthefutureinalignmentwiththebusinessstrategy.Notallcapabilitieshavethesamelevelofvalue.Forexample,whiledistributingpayrolltoemployeesisimportanttoacompany,itislikelyneitherofhighbusinessnorcustomervalue.Inotherwords,thismaynotbeacapabilitythataddsvalueforthecompanytobuildandmaintaininternally.Therearevarioustoolsthatcanbeusedtomakebusinessandcustomervalueexplicitinacapabilityassessment.
Performance Expectations
Sincecapabilitiesidentifytheabilitiesrequiredtoperformortransformsomething,capabilitiescanbeassessedtoidentifyexplicitperformanceexpectations.Whenacapabilityistargetedforimprovement,aspecificperformancegapcanbeidentified.Theperformancegapisthedifferencebetweenthecurrentperformanceandthedesiredperformancegiventhebusinessstrategy.
Risk Model
Risksintheperformanceofthecapabilityfallintothefollowingcategories:
• businessrisk,• technologyrisk,• organizationalrisk,and• marketrisk.
Strategic Planning
Businesscapabilitiesforthecurrentstateandfuturestateofanorganizationcanbeusedtodeterminewherethatorganizationneedstogoinordertoaccomplishtheirbusinessstrategyandimperatives.Asaresultofperformingabusinesscapabilityassessmentthereisgenerallyasetofrecommendationsorproposalsforsolutionsthatneedtobeputinplace.Thisinformationformsthebasisofaproductroadmapandservesasaguideforreleaseplanning.
Capability Maps
Frequentlyorganizationsusecapabilitymapstoprovideagraphicviewofelementsinvolvedinbusinesscapabilityanalysis.The
Agile Extension to the BABOK® Guide 57
Agile Techniques The Discovery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
followingillustrationdemonstratesoneelementofacapabilitymapthatwouldbepartofalargercapabilitiesgrid.
FIGURE 4.1 SampleCapabilityMap
FIGURE 4.2 SampleCapabilityMapCell
58 Agile Extension to the BABOK® Guide
The Discovery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
Usage Considerations
Capabilityanalysisisusefulwhenanorganizationchangesitsbusinessfocusorstrategy,orthereismoredemandforchangethanthereiscapacitytodeliver.Whenthedemandoutweighsthecapacitytodeliver,alargeundifferentiatedbacklogofchangesorimprovementrequestscanresult.Capabilityanalysishelpstoidentifythoseimprovementrequeststhatwilladvancethestrategicgoalsofthebusiness.Uponcompletionofaprojecteffort,thecapabilityanalysiscanbeupdatedtoreflectimprovementsinperformanceandtoidentifythenextmostimportantcapabilityperformancegaptofocuson.
Theoutcomesofacapabilityanalysisserveaslong‐livedartifactsthatrepresentacommonviewofthebusiness.Thiscanbeusedtogeneratesharedunderstandingandalignefforts.Whenthebusinessstrategychangesorcustomerdesiresevolve,thismodelcanbeusedtorapidlyre‐prioritizethelistofwantsforasolution(forexample,re‐prioritizingthebacklog).
Advantages• Theadvantagesofcapabilityanalysisarethattheyresultinasharedarticulationofoutcomes,strategy,andperformance.Thesehelpcreateveryfocusedandalignedinitiatives.Themodelworkswellwithagileteamsbutitalsohelpsidentifyopportunitiesthatarenottechnologybased,includingprocess,talent,anddataimprovements.
• Thecapabilityanalysishelpsalignbusinessinitiativesacrossmultipleaspectsoftheorganization.
Disadvantages• Thismodelrequiresanorganizationtoagreetocollaborateonthismodel.
• Whenthismodeliscreatedunilaterallyorinavacuumitfailstodeliveronthegoalsofalignmentandsharedunderstanding.
• Themodelalsorequiresabroad,cross‐functionalcollaborationindefiningthecapabilitymodelandthevalueframework.
Agile Extension to the BABOK® Guide 59
Agile Techniques The Discovery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
.2 Personas
Purpose
Usercentereddesignpracticesoftenusepersonasasapowerfulandsimpletooltohelpdesignsoftwarethatuserswillenjoyandbenefitfrom.
Description
Personasarefictionalcharactersorarchetypesthatexemplifythewaythattypicalusersinteractwithaproduct.Theyareoftenusedinagileapproachestounderstandvaluefromtheperspectiveofaparticularcustomerandallowateamthatmaynothavedirectaccesstoacustomerrepresentativetobetterunderstandtheirneeds.Workcanthenfocusonthefeaturesofgreatestvaluetoaparticularpersona.
Elements
Apersonashouldbedescribedasthoughtheyarearealperson.Personasmayprovideaname,personality,family,workbackground,skilllevel,preferences,behaviorpatterns,personalattitudes,goals,andneeds.Itisalsoagoodpracticetoincludeapictureandwriteashort“dayinthelife”narrativethathelpstheteamvisualizetheuser.
Usage Considerations
Usepersonaswhenyouwanttogetadeeperunderstandingofkeystakeholdersthanonegenerallygetsfromatraditionalroleoractordescription.Personashelpdriveproductsthatarefitforpurposeandhighlyusable,becausetheyarepatternedafterthesubtlequalitiesofrealpeoplethatwillinteractwiththesystemsandhowtheydotheirjob.
Ifthedataisavailable,usingdemographic(oranthropomorphic)dataabouttheintendeduserpopulationisagoodwaytostartbuildingpersonas.Howeverinsomecasesitisnecessarytobecreativeandinventpersonasbasedonlittlemorethanafewdryfactsabouttheintendedendusers.Ineithercase,arepresentativepoolofpersonasshouldbeidentified.
Personasarethenrankedtoidentifythosewillrealizethemostbenefitfromthesystemdesign.
Advantages• Personasfacilitatethesharedunderstandingofspecificrequirementsfordifferentsetsofusers.Theserequirementscanbe
60 Agile Extension to the BABOK® Guide
The Discovery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
visualizedwithinthecontextoftheirusergroupandthenusedtodevelopuserstories.
• Proposedsolutionscanbeguidedbyhowwelltheymeettheneedsofindividualuserpersonas.Featurescanbeprioritizedbasedonhowwelltheyaddresstheneedsofoneormorepersonas.
• Provideahuman“face”soastofocusempathyonthepersonsrepresentedbythedemographics.
Disadvantages• Personasarefictionalsothereisoftenatendencytocreatepersonasthatembodytraitsthatarecommontomostusers,butindoingsocreatingagenericuserthatisnotdistinctorrealistic.Thiscanleadtosoftwarethatistryingtobeeverythingtoeveryone.
• Personasmaynotbeagoodsubstituteforarealuser,iftheyareavailable.Personascandistanceateamfromausercommunity.
.3 Value Stream Mapping
Purpose
Valuestreammapping(alsoknownasmaterialandinformationflowmapping)providesacomplete,fact‐based,time‐seriesrepresentationofthestreamofactivitiesrequiredtodeliveraproductorservicetothecustomer(internalorexternal).Itisusedtoidentifyareasofpotentialimprovementinanend‐to‐endprocess.
Description
Avaluestreamrepresentstheflowofmaterialandinformationrequiredtobringaproductand/orservicefromrawmaterialtothecustomer.AValueStreamMap(VSM)isagraphicalrepresentationthatcapturesasnapshotofthevaluestream.
Therearetwomaintypesofvaluestreammapsthatarewidelyused:
• CurrentStateValueStreamMap:Depictsavaluestreamasitisappliedbythosewhoareresponsibleforexecutingit.Itisusuallyusedasastartingpointforanalysisofanexistingprocesstoidentifyimprovementopportunities.
• FutureStateValueStreamMap:Derivedfromthecurrentstateanditshowswhatthevaluestreamwilllooklikeaftertheimplementationoftheimprovements.
Inanagileenvironment,thisdiagramisusuallysimpleanddrawnonawhiteboard.Itcanbeusedtohelpre‐engineerbusinessprocessesto
Agile Extension to the BABOK® Guide 61
Agile Techniques The Discovery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
optimizeuseofsoftware.Itcanalsobeusedtore‐engineerandtunethesoftwaredevelopmentprocessitself,forexample,toreduceleadtimefromproductdiscoverytorelease.
Elements
Thefollowingisabroaddescriptionforoneapproachtobuildingavaluestreammap.
Prepare1. Gatheracross‐functionalteam.Intheagileworldthisshould
includepeoplewithbusinessdomainknowledgeandtechnicalteammembers(suchasdevelopers,testers,andarchitects).Oftensomeoneactingasthebusinessanalystwillfacilitatethesession.
2. Assignavaluestreammapowner.Ideallythisissomeonewhohasadeepunderstandingofthecurrentprocess.
3. Selectaproduct,aproductfamily,oraservice,anddefinethescopeofthevaluestreammap.
4. Identifythecustomervaluereceivedsoitcanbetracedback.
Create Current State
Thecurrentvaluestreammapcanbecapturedfollowingthesesteps:
1. Observeorsimulatevaluestream.Followaproduct(orproductfamily)pathbystartingattheendclosesttothecustomerandrecordtheprocessworkingyourwaybackwardstothebeginning.
2. Drawthevaluestreammap.
3. Capturetheinformationflow.Theinformationthatisvitalforthevaluestreamtofunction.Informationflowincludes(butnotlimitedto)thingssuchasorders,schedules,inventorytime,changeovertime,cycletime,andnumberofoperatorsinvolved.
4. Buildamodelthatshowseachstepintheflowwithhand‐offsandsequence.Toassistintheanalysisneededtoidentifyopportunitiesforimprovementintheprocess,ensurethatyouincludetime/costvaluesontothestepsintheprocess.Thesetimevaluesmaybeestimated,ifneeded.Themoredetailsavailable,theeasieritistoidentifyimprovementopportunities.
5. Validatethevaluestreammap.Theinitialdraftofthecurrentvaluestreammapmustbevalidatedbeforeproceedingtotheimprovementphase.
62 Agile Extension to the BABOK® Guide
The Discovery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
Analyze Current State
ThecurrentvaluestreammapcanbeanalyzedasdescribedinRootCauseAnalysisoftheBABOK®Guideversion2.0(9.25RootCauseAnalysis)toidentifyvalueaddedsteps(suchastransformationprocesses)fromthosethatarenon‐valueadded(suchasexcessiveinventories).
Thenon‐valueaddedstepscanbeanalyzedfurthertodeterminewhichonesarenecessary(suchasmeetingregulatoryrequirements)andwhichonesareunnecessary(suchasexcessivepaperwork).
Create Future State
Thefuturestatevaluestreammapcanbedrawnasfollows:
1. Identifyimprovementareas.Unnecessarynon‐valueaddedstepsarethesourceofwasteandtheycanbeeliminated.Teammemberscanmarktheseareas(suchasreducingleadtime)onthecurrentvaluestreammap.
2. Capturethefuturestatevaluestreammap.Drawthevaluestreammapthatshowswhatthevaluestreamwilllooklikeafteryouhaveeliminatedthewaste(unnecessarywaittime,excessiveadministrativepaperwork,highinventories,andsoforth).
Oncethefuturestateiscaptureditcanbeusedasthetargetstateoftheimprovementinitiative.
Implement Process Improvement • Identifysupportingmaterialrequiredforimplementingtheimprovementsuchasinformationtechnologysystems,training,andchangeover.
• Implementtheimprovement.
Inanagileproject,valuestreammappingwillbemostutilizedwhenimplementingprocessimprovement.Oftenthechangestobemadeinthebusinessprocesswillrequirechangestoorimplementationofsupportingsoftwareproducts.Therequirementsforthesechangesorenhancementsbecomebacklogitemsthatfeedintoanagileinitiative.
Oncetheimprovementismade,thefuturestatebecomesthecurrentvaluestreammapanditcanbeusedasastartingpointforanotherimprovementcycle.
Agile Extension to the BABOK® Guide 63
Agile Techniques The Discovery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
Thefollowingisanexampleofavaluestreammap.
FIGURE 4.3 ValueStreamMap
Usage Considerations
Advantages• Morecomprehensivethanaprocessflowdiagram.• Providesablueprintforimplementingimprovement.• Establishesasharedunderstandingofprocesswastesandbottlenecks.
• Providesacommonvisuallanguagefordiversestakeholders.
Disadvantages• Noteasytoconstructincomparisonwithothervisualmodelingtechniques.
• Canlookdauntingbecauseofalltheinformationcaptured.• Mappingparalysis.Itiseasytogetcaughtmakingthecurrentstatevaluestreammapcompleteandperfectinsteadofproceedingtotheimprovementstage.
• Doesn'tworkwellinknowledgebasedornon‐linearwork.• Leadstodisruptiveor“re‐engineering”approach.Doesn'tworkwellwithongoingimprovementefforts.
64 Agile Extension to the BABOK® Guide
The Discovery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
4.5.2 Think as a Customer
Thinkinglikeacustomerisakeycomponentofagilebusinessanalysis.Thecustomeristhepersonwhogetsvaluefromtheproductwearebuilding.Westartwithahighlevelviewofcustomergoalsandprogressivelydecomposetheseintoamoreandmoredetailedunderstandingofthespecificneedsthattheproductmustmeet.
Agileprocessesincorporatefeedbackloopstocontinuouslyvalidatethisunderstanding.Asproductdeliveryprogresses,thecustomerandteamunderstandingoftheneedswillevolve,itisimportantthatthesechangesinfluenceanddefinetheworkoftheteamgoingforward.
Agileanalysisslicesthedeliveryintothesmallestpracticalincrementsthatdeliverbusinessvalueoverthelifeoftheproject.
Itisimportantthatagileanalysisstartwithaholisticperspective,inordertohelptheteamunderstandtheoverallproductthatneedstobedelivered.Theteamcollaborateswiththecustomertoconsidertheuserexperienceexpected.
Agoalofanalysisistoensurethevoiceofthecustomer,especiallytheend‐user,iselicitedandexpressedintheproduct.
Backlogitemsrepresentworktobedoneandconveycustomerthinking,andcanberepresentedthroughprototypes,userstories,usecases,minimalmarketablefeatures,features,epics,orworkitems.
Thefollowingsectionsdescribecommonlyusedtechniquesforthisprinciple.
Thetechniqueslistedbelowarebasedonuserstories:
• StoryDecomposition,• StoryElaboration,• StoryMapping,and• UserStory.
Atechniqueforprototypingauserinterfaceandusingthattodefinedetailedrequirementsis:
• Storyboarding.
Agile Extension to the BABOK® Guide 65
Agile Techniques The Discovery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
ThereareothertechniqueswithintheAgileExtensiontotheBABOK®Guide,theBABOK®Guide,andotheradhoctechniquesthatcanbeutilizedhereaswell.
.1 Story Decomposition
Purpose
Storydecompositionisaderivationofexistingrequirementsanalysistechniquessuchasfunctionaldecomposition.Inanagilecontext,storiesareoftenusedtorepresenttheworkoftheteamandtherequirements(oracceptancecriteria)ofthatwork.Storydecompositionensuresthattherequirementsforaproductarerepresentedattheappropriatelevelofdetailandarederivedfromavaluablebusinessobjective.
Thistechniqueprovidesastructurefordefiningthevariouselementsofrequirementsatprogressivelysmallerlevelsofgranularity,startingwiththebroadsystemcontextanddrillingdowninmultiplelevelstoeventuallydefinethedetailedacceptancecriteriaforindividualuserstories.
Description
Themostcommonagileapproachtostorydecompositioncanbedescribedas“breadth‐before‐depth”:
• startwithaveryhighlevelpictureofwhatbusinessgoalsneedtobeachieved,
• decomposethoseintosmallercomponentsthatprovideincrementsofvaluablefunctionality(sometimescalledminimallymarketablefeaturesetsorMMFs.MinimalviableproductsorMVPsaretheaggregationofmultipleMMFs),and
• splitthecomponentsintouserstories,andeventuallyelaboratetheuserstorieswithacceptancecriteria,see“StoryElaboration”onpage68.
Astorythatistoolargeorinsufficientlyunderstoodtoelaborate,estimate,ordeliverasastoryissometimescalledanepic.Epics,whenused,arelaterdecomposedintosmallerstories.
66 Agile Extension to the BABOK® Guide
The Discovery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
FIGURE 4.4 StoryDecomposition
Differentteamsapplythistechniqueindifferentways.Forexample,someteamsfollowthemodellinearly,asshownintheabovediagram,whileotherteamsutilizetechniquesthatworkbestintheirenvironment.Forexample,onceateamhasdevelopedtheMMF(sometimesreferredtoasfeaturegroups),theymayemployusecasesinsteadofstories.Theanalyst'srolehereistofocusondynamiccollaboration,facilitation,andcommunicationingettingacceptanceforjustwhatisrequiredtodevelopanddelivertheproduct.
Agile Extension to the BABOK® Guide 67
Agile Techniques The Discovery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
Thefollowingtabledescribesthedifferentlevelsofstorydecomposition.
TABLE 4.3 Story Decomposition
Usage Considerations
StoryDecompositionisundertakenprogressively.Oneofthemostsignificantdifferencesbetweenagileprojectsandplan‐drivenprojectsisinthedefinitionofdetailedrequirements.Inagileprojectstheinitialanalysisactivitieswillidentifythegoals,MMFs,andmostoftheepics.Theinitialsetofuserstories(probablyforthefirstreleaseoftheproduct)willbedoneintheprojectinitiationactivities.Thereisaclearunderstandingthatthesestoriesarelikelytochangeandthattheteams'understandingoftherequirementswillevolveovertime.Therefore,decomposingtothelowestlevelofdetailislikelytobeawastefulactivityearlyintheproject.
Advantages• Thisdecompositiontechniquehelpsavoidthecommonproblemofgettinglostinthedetailoftheuserstoriesandlosingthebig‐picturecontext.
• Itisimportantthatteammemberskeeptheproject'sgoalsandobjectivesinmind,andwhileusingthedecompositionapproach
Level DescriptionSystem Goals The product goals are the highest level of business requirements. They
represent the business drivers for undertaking the project and form the rationale against which all of the detailed level needs are assessed.
MMF/Component
MMF stands for Minimal Marketable Feature. Minimal Viable Products or MVPs are the aggregation of multiple MMFs. These are logical groupings of functionality and capabilities the delivered product needs to provide to be worth releasing. Often these will form the themes for a single release and serve to provide a big-picture context for the product being developed.
Epic A piece of functionality that enables a user to achieve a clearly identified business objective. Often epics are at the level of elementary business processes---a piece of work undertaken by one person, at one time, in one place that delivers on a specific operational objective. Epics are often a user story that is too large to fit into an iteration. Therefore it requires story decomposition in order to break it into less than iteration sized stories.
User Story Represents a user requirement that is to be implemented in the delivered system. The user story is the most common backlog item used in agile projects.
Acceptance Criteria
Conditions of satisfaction or criteria needed to validate a user story. Can be written as lists of items, specifications, or user acceptance tests (or a combination). Detailed requirements are represented and validated in the acceptance criteria.
68 Agile Extension to the BABOK® Guide
The Discovery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
theyareabletotraceimplementedorrequestedfunctionalitybacktothedrivingbusinessobjectives.
• BreakingtheproductintoMMFsandepicshelpswithrelease‐levelplanning,providesvisibilityintothedevelopmentproject,andhelpscoordinateexternalprogramactivitiessuchasorganizationalchangemanagementandusertraining.
Disadvantages• Acommonanti‐patternisthetemptationtotreatstorydecompositionasawayofrevertingtodetailedrequirementsup‐front.Ensuringthecontinuedemphasisonjust‐enoughandjust‐in‐time,meansknowingwhentostopdecomposing.
.2 Story Elaboration
Purpose
Storyelaborationisatechniqueusedtodefinethedetaileddesignandacceptancecriteriaforauserstoryonajust‐in‐time/just‐enoughbasis.Storyelaborationisanongoingactivitythatispartofthedevelopmentprocess.
Description
Storyelaborationisthelowestlevelofstorydecompositionandtheprocessbywhichthestorysentenceisintobrokendownintopiecesofwork.Thisisoftendonebysomeoneontheteamwhohasstrongbusinessanalysisskills,particularlywithfacilitationandcommunication.Storyelaborationisthetechniquethroughwhichdetailedrequirementsareelicitedandcommunicatedtotheprojectteam.
Duringeachiteration,theteamthatworksonastoryschedulestimetoexpandonthestorytounderstandthedetail.Often(butnotalways)thisiscompletedinashortworkshopwiththeprogrammerswhowillworkonthestory,thebusinessSMEorcustomerwhoneedsthestory,thepersonwhowilltestthestory,andsomeoneactingasabusinessanalysttofacilitateandchallengethestory.Typically,storyelaborationisundertakenafewdaysaheadofthedevelopmentofthestory.
Storyelaborationshouldbedoneonanas‐needed,just‐in‐timebasisforstoriesthathavebeendeterminedtobeinscopefortheupcomingiteration.Theprojectteamshouldnotinvestigatestoriesforfurther
Agile Extension to the BABOK® Guide 69
Agile Techniques The Discovery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
elaborationiftheyhavenotbeenplannedforthereleaseinquestion,astheinformationcollectedmaybestaleandoutofdate.
Storyelaborationisacommunicationtechniquethathelpsensurethecorrectproductisbuilt.Inanagileproject,thedetailedrequirementsareproducedbystoryelaboration.However,asopposedtoplan‐drivenapproaches,andconsistentwiththejust‐in‐timephilosophyofagile,thedetailedrequirementsdefinedduringstoryelaborationcontainonlytherequirementdetailsforthepieceofworkthatistobecompletedinthecomingrelease.
Elements
Theresultofstoryelaborationisasharedunderstandingamongtheparticipantsofwhatthestorymeansandwhatshouldbedeliveredtoachievethe“Done”stateforthisstory.Theroleofthebusinessanalystindevelopingandcommunicatingdynamicrequirementsnecessitatesahighdegreeofskillinbothfacilitationandcommunication.
Someteamsusestasksasawaytocommunicatetheiranalysisoftheuserstory.Theoutputsofeffectivestoryelaborationdescribeand/ordocumenttasksthatenabletheteamtosuccessfuldelivertheupcomingiteration.Theseoutputsmayinclude
• taskdefinitionsandbreakdowns,• examplesandscenariosthatexplainthecustomer'sintentforthestory,
• low‐fidelitymodelsthatclarifythetechnicalorprocessdesign(forexample,datamodels,anddataflowdiagrams),
• screenorreportmock‐ups,• acceptancecriteria(testdesignspecifications)toclarifyhowthestorywillbetested,ofteninthe<given><when><then>formatofbehaviordrivendevelopment,
• input/outputdatatables,and• otherartifactsthatwillbeusefulinthedevelopmentandtestingofthisstory.
Usage Considerations
Advantages• Themajoradvantageofstoryelaborationisthatitdecreaseselicitationtime,andpotentiallydocumentation,byfocusingoncurrentfeatures.Byelaboratingonrequirementsonlyastheyareneeded,theteamavoidstheworkofelicitingrequirementsfor
70 Agile Extension to the BABOK® Guide
The Discovery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
featuresthatmayneverbebuiltorthatwillneedtobechangedbythetimetheyarereadyforimplementation.
Disadvantages• Forthosewhoarerelativelynewtoagileapproaches,itcanbedifficulttodeterminethebesttimingforconductingastoryelaboration.Ifconductedtooearly,theinformationmaynolongerbecorrectforthegivenreleaseandwillneedtobere‐elicited.However,whencollectedtoolate,itcandelayprojectteamprogressiontodevelopment.
• Anotherchallengetoimplementingstoryelaborationistheabilitytoelicittheappropriatelevelofdetailsuchthattherequirementscanbedeveloped,tested,andcomparedtoacceptancecriteria.
.3 Story Mapping
Purpose
Storymappingprovidesavisualandphysicalviewofthesequenceofactivitiestobesupportedbyasolution.Itusesatwo‐dimensionalgridstructuretoshowsequenceandgroupingsofkeyaspectsoftheproductonthehorizontaldimension,withdetailandpriorityofstoriesontheverticaldimension.
Description
Astorymapisatooltoassistincreatingunderstandingofproductfunctionality,theflowofusage,andtoassistwithprioritizingproductdelivery(suchasreleaseplanning).Itisalsodecompositiontechniquethatallowsfortheevolutionaryunderstandingofaproductstartingwithanend‐to‐endviewanddrillingdowntothedetaileduserstories.
Astorymapisdesignedtobeaninformationradiator,usedtovisualizeaproduct'srequestsinthecontextofusageandpriority.Thestorymapisoftenplacedondisplayfortheprojectteamduringreleaseplanningsessions.Byanalyzingthestorymap,theteamcanmorereadilyidentifydependenciesgeneratedasaresultoftheintendedflowthroughtheuserstories.Themapcanalsobeusedforriskassessmentandmanagementbyexamininghowthestorieswillneedtoworktogetherinthecontextofdeliveringbusinessvalue.
Agile Extension to the BABOK® Guide 71
Agile Techniques The Discovery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
Thefollowingillustrationisanexampleofastorymap.
FIGURE 4.5 StoryMap
Elements
Thestorymaphasacentralbackboneofelementsthatwillmakeuptheproduct.Abovethisbackbonearethelargefeaturesets(activities)thatneedtobedeliveredoverthelifeoftheproject.Thebackboneisasequentialsetoftasksthatneedtobeenabledbythesoftware.Belowthebackbonearethedetailedstoriesthatimplementthespecificpiecesoffunctionalitytoenablethetaskstobeaccomplished.
Usage Considerations
Advantages• Whenthelargercontextofaproductisnotaccountedfor,agileprojectscanbesubjecttogettingmiredinthedetailswithaninabilitytoeffectivelystringcomponentstogethertocreateend‐to‐endbusinessvalue.Storymappinghelpsavoidthecommonproblemofgettinglostinthedetailoftheuserstoriesandtheriskoflosingthebig‐picturecontext.
Disadvantages• Storymappingcanbecomecumbersomewheretheproductisverylargeandmayrequirebuildinganumberofstorymapsthatcoveralargeprogramofwork.Whilestorymapsillustrateaflow,theydonotanalyzeorillustratedependenciesbetweenrequirements(thoughtheycanbeusedtohelpfacilitatethatanalysis).
• Environmentsthatarenotprocessorientedwillfindstorymapslessuseful.
72 Agile Extension to the BABOK® Guide
The Discovery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
.4 User StoryUserStoriesaredescribedindetailintheBABOK®Guideversion2.0(9.33UserStories).Thisinformationfoundherereflectsandexpandsonthatinformationinthecontextofagiledevelopmentapproaches.
Purpose
Auserstoryrepresentsasmall,concisestatementoffunctionalityneededtodelivervaluetoaspecificstakeholder.
Userstoriescanbeused
• tocaptureandprioritizeuserneeds,• asabasisofestimatingandplanningproductdelivery,• asabasisforgeneratinguseracceptancetests,• asawaytomonitorprogressindeliveringofvalue,• asaunitfortracingrelatedrequirements,• asabasisforadditionalanalysis,and• asaunitofprojectmanagementandreporting.
Description
Userstoriesareaplanningtechniquethatenablesagileteamstotrackfeaturesofvaluetoacustomerorenduser,andareusedasabasisforestimatingwork.Typically,theyareoneormoresentenceswrittenbythecustomers,productowners,orbusinessanalyststhatdescribesomethingofvaluetoastakeholder.Userstoriesprovideamechanismfortheproductownertoscope,coordinate,andprioritizetheincrementsofuservaluefordevelopment.Astoryshouldbeshortenoughtobewrittenonasmallpapernotecard,usuallya3×5inchindexcardorstickynote.Storiesmayalsoberecordedinanelectronicsystem.
Userstoriescapturestakeholderneedsusingshort,simpledocumentationandinviteexplorationoftherequirementsthroughconversations,tests,andsupplementalrequirementsrepresentationsasneeded.Theyareconciseandeasytochangeasstakeholderneedsarebetterunderstoodorasthoseneedsevolve.
Someteamsmakeuseofothertypesofstoriestocatalogue,estimate,plan,andtrackotherworkneededtobuildtheproduct.Thesestoriestypicallydefineworkneededtoenableproductdevelopment,deployment,andsupport.
Agile Extension to the BABOK® Guide 73
Agile Techniques The Discovery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
AcommonlyusedconstructforensuringqualityinuserstoriesistheINVESTcriteria,whichcallforuserstoriestobe
• Independent,• Negotiable,• Valuable,• Estimable,• Small,and• Testable.
Elements
Title (optional)
Thetitleofthestorydescribesanactivitythattheuserwantstocarryoutwiththesystem.Typically,itisanactive‐verbgoalphrase,similartothewayusecasesaretitled.
Description
Thereisnomandatorystructureforuserstories;however,themostpopularformatincludesthreecomponents:
• auserroleorpersona[WHO],• anecessaryaction,behaviour,orfeature[WHAT],and• thebenefitorbusinessvaluereceivedbytheuserwhenthestoryisimplemented[WHY].
Usageexample:
"Asa<role>,Ineedto<behavior>sothat<businessvalue>."
Analternativeformatis:"Inorderto<businessvalue>,asa<role>,Ineedto<behavior>."
Thiscanonicalformatcanalsobeusedforstoriesusedtoidentifyqualityattributes.Forexample:
"AsaSecurityOfficer,IneedtoonlyallowauthorizeduserstoaccessthexyzfunctionalitysoIcanensureweenforceabcsecuritydirective".
Conversation
Userstoriesserveasareminderthattheteamneedstoexploreandunderstandthefeaturedescribedinthestoryandthevaluethatitwilldelivertothecustomer.Thestoryitselfdoesn'tcaptureeverythingthereistoknowaboutthecustomerneed,andtheinformationimplied
74 Agile Extension to the BABOK® Guide
The Discovery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
bythestorycanbesupplementedbyanalysismodelstopromotesharedunderstanding.
Acceptance Criteria
Whenauserstoryiswelldefinedandunderstood,itisaccompaniedbyacceptancecriteria.Acceptancecriteriadefinetheboundariesofauserstoryandhelpproductowners,customers,orbusinessanalyststoanswerwhattheyneedtoprovidevaluewiththeproduct.
Acceptancecriteriahelpdevelopersidentifywhentostopaddingmorefunctionalityandtoderivetestsforverificationandvalidationpurposes.Theycanalsobedevelopedasastorybecomeswellunderstoodtoenablethedevelopmentteamtoverifythatthesolutionwillmeettheuser'sneeds.
Usage Considerations
Advantages• Tiedtosmall,implementable,andtestableslicesoffunctionalityfacilitatingrapiddeliveryandfrequentcustomerfeedback.
• Easilyunderstandablebystakeholders.• Canbedevelopedthroughavarietyofelicitationtechniques,includingbutnotlimitedtofacilitatedworkshops,contextualinquiry,andotherethnographicelicitationtechniques.
• Userstoriesaresimpleenoughthatpeoplecanlearntowritetheminafewminutes,beingcarefulaboutalwaysdeliveringbusinessvalue.
• Theprocessofcollaboratingondefiningandexploringstoriesbuildsteamcommitmentandsharedunderstandingofthebusinessdomain.
• Storiesinviteconversationforfurtherdecompositionandexploration.
• Tofacilitateestimating,planning,anddelivery,manyagileteamssupplementstorieswithanalysismodels(suchasadatamodel,businessrules,useracceptancetests,screenmock‐upsorprototypes,contextdiagram,andstatediagram).
Disadvantages• Thisconversationalapproachcanchallengetheteam,sincetheydonothavealltheanswersanddetailedspecificationsupfront.
• Toomanystoriescaninflatethebacklog.• Large,chunkystories(epics)canbevagueanddifficulttousewithoutbreakingthemdownintosmallstories.
Agile Extension to the BABOK® Guide 75
Agile Techniques The Discovery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
• Storiesspawnmorestoriesviadecompositionsotheinformationmustbeorganizedtoensureitiscurrentandrelevant(calledpruningorgrooming).
• Thecollectionofstoriesneedstobemanaged(forexample,withbacklogmanagement).
• Storiesrequirecontext.Iftheteamdoesn'ttracestoriesback(throughvalidation)orsupplementthemwithhigher‐levelanalysisandvisionartifacts,thentheteamcanlosesightofthebigpicture.
• Somepractitionerscanbeconfusedaboutthedifferencebetweenusecases,userstories,andstorytechniques.
.5 Storyboarding
Purpose
Storyboardingisusedinconjunctionwithothertechniquessuchasusecases,userstories,andprototypingtodetailvisuallyandtextuallythesequenceofactivitiessummingupdifferentuserinteractionswiththesystemorbusiness.
Storyboardingserves
• toelicit,elaborate,organize,andvalidatetherequirements,• tocommunicatetodeveloperswhatneedstobebuilt,• toassistinginuserinterfacedesign,• toshowdifferentvariationsoftheproposedsolution,• toalignstakeholderswiththevisionoftheproposedsolution,and• asaninputtotests.
Description
Storyboards(alsoknownasdialoguemap,dialoghierarchy,ornavigationflow)userepresentativeimagesandtexttodescribeatask,ascenario,orastory.Itcanalsobeusedwithprototypingtorepresentpartsofthesystemthatarewellunderstoodorexpensiveandunnecessarytoproduceviaformalprototypes.
Whenusedtodescribetheinteractionwiththesystem,thestoryboardshowshowscreenswilllookandhowtheywillflowfromonetoanother.Whenusedtodescribebusinessorganization,thestoryboardshowstheinteractionwithabusinessprocesssuchasbackoffice.
Storyboardscanbedevelopedusingwhite‐boardsandstickynotesorusingsoftware.
76 Agile Extension to the BABOK® Guide
The Discovery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
Storyboardsarecommoninmanyanalysisanddevelopmentapproaches,andareaformofprototyping(seetheBABOK®Guideversion2.09.22Prototyping).However,asagileapproachesfavourthedevelopmentofworking,usablesoftwareoverthrowawayprototypes,storyboardingisausefultoolforunderstandinghowpeoplewillactuallyusethesystem.
Elements
Storyboardscanbecreatedinaworkshopenvironmentwithrelevantstakeholders.
Preparation1. Identifymainscenarioswithinthescopeoftheproject.Thiscanbe
derivedfromusecasesoruserstoriesorcanbeidentifiedinacustomervisitoraninformation‐gatheringsessionwithexperts.
2. Selectthescenariosthatneedtohaveastoryboarddeveloped.Whilesomescenariosneedtobedetailedinastoryboard,othersareobviousandcanbeomittedsuchasalternatescenariosandexceptions.
3. Identifyparticipantsandschedulethesession.
4. Arrangeroomandequipmentsuchasflipcharts,markers,glue,scissors,rulers,printers,andaccesstotheinternet.
Session1. Haveattendeescreateillustrationsforthestoryboardsofthe
selectedscenarios.
2. Enhancestoryboardillustrationswithtextualinformationsuchasoptionalinteractions,unavailableinteractions,furtherstakeholderrequestsnotassociatedwiththeprimaryscenario,andgeneralnotesassociatedwithaspecificstep.
3. Makesureeachstoryboardstandsonitsownbyaddingrequiredexplanationsastext.
Wrap up
Attheendofthesession,thebusinessanalystreachesconsensusonthehighlevelflowofthedevelopedstoryboards.
Aftertheworkshop,thecompanytemplatesmaybeusedtoformallydocumenttheoutcomeofthesession,addingadditionalelementstothestoryboardssuchasstoryboardidentification,description,user,trigger,input,output,andissues.
Agile Extension to the BABOK® Guide 77
Agile Techniques The Discovery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
Usage Considerations
Advantages• Storyboardingcansignificantlyreduceabstractnesscausedbyothertechniquessuchasusecasesanduserstories.
• Storyboardscanbeproducedquicklyandataverylowcostcomparedtoothertechniquessuchasprototypes.
• Theintuitivenatureofthestoryboardencouragesstakeholderparticipation.
Disadvantages• Differentlookandfeelthanthefinalproduct.• Easytogetboggeddownonhow,ratherthanwhy.
4.5.3 Analyze to Determine What is Valuable
Theagileapproachcontinuouslyassessesandprioritizesbusinessvaluetoensurethatthemostvaluableworkisdeliveredatanypointintime,alwaysusingtheendcustomerperspective.Itisalsoimperativetoquestionthepurposebehindrequirements,challengingthoserequirementsthatdonotsupportthebusinessgoals.Agileapproachesenabletheartofmaximizingtheamountofworknotdone,somethingessentialtodelivervaluablesoftwareearlyandcontinuously.Thetechniquesoutlinedinthissectionfacilitatethevaluationofproductneedsonanon‐goingbasis.
Thefollowingsectionsdescribecommonlyusedtechniquesforthisprinciple:
• BacklogManagement,• BusinessValueDefinition,• KanoAnalysis,• MoSCoWPrioritization,and• PurposeAlignmentModel.
ThereareothertechniqueswithintheAgileExtensiontotheBABOK®Guide,theBABOK®Guide,andotheradhoctechniquesthatcanbeutilizedhereaswell.
78 Agile Extension to the BABOK® Guide
The Discovery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
.1 Backlog Management
Purpose
Thebacklogisawishlistofrequestsforfeaturestobeincludedinaproduct,andisthemainmechanismformanagingrequirementsonanagileproject.
Description
Theproductbacklogisestablishedatthebeginningofaproject.Thebacklogisafluidcollectionofstoriesthatevolvesoverthecourseoftheprojectasmoreislearnedabouttheproductanditscustomers.Theproductownerisresponsiblefororderingtheitemsonthebacklogbasedonbusinessvalue,featureimportance,orotherrelevantcriteria.Whenmanagingabacklog,itemsshouldbeorderedsuchthatthemostimportantitemsoccuratthetopofthelistandareorderedbasedondescendingpriority.
Duringtheplanningsessions,itemsareselectedfromthebacklogbasedonfactorssuchaspriority,risk,valuetotheproductorcustomer,andabilitytodeliverthefeaturewithinthegivenrelease.Attheendofeachrelease,feedbackonwhatwasdevelopedmayresultinnewitemsbeingaddedtothebacklog,changedpriorities,orremoveditems.
Thebacklogisdevelopedatthebeginningofanagileproject,butitdoesnotneedtobecompleteatthistimesinceitwillcontinuetoevolvethroughouttheproject.
Thebacklogissometimesreferredtoasaportfolioofoptionsthatthebusinesscaninvestin.Othertermsusedaremasterstorylistandprioritizedfeaturelist.
Elements
Items in the Backlog
Thebacklogcancontainuserstories,usecases,features,functionalrequirements,andqualityattributestoriesaswellasitemsthathavebeenaddedbytheteamtosupportdevelopmentoftherequirementssuchastechnicalinfrastructure.Toaidinorderingthebacklog,itemsshouldbeexpressedinsuchawaythatthebusinessvalueoftheitemsisclear.Productriskmitigationitemsmayalsogetaddedtothebacklogasstoriesorpiecesofworktobedone.
Agile Extension to the BABOK® Guide 79
Agile Techniques The Discovery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
Appropriate level of detail
Itemswithhighorderinthebacklogwillbedevelopedinnear‐termreleases,sotheyneedtobedetailedenoughtoallowthedevelopmentteamtoestimatethemwithaccuracyandbeabletodecomposethemintothetasksneededtodevelopthem,ifneeded.Itemswithlowerprioritycanremainhigh‐levelandlesspreciseuntiltheyriseintheorderandneedtobespecifiedinmoredetail.LargeitemsinthebacklogaresometimesreferredtoasepicsorMMFs,andmaybebrokendownintomultiple,moregranularitemsasthebacklogiselaboratedviastorydecomposition.Someaspectsofthestorymaybeimportantnear‐termandotherslessimportant.
Estimation Accuracy
Itemswithhighorderinthebacklogneedtobeestimatedwithenoughaccuracytousethemforplanningreleases.Itemsinlowerorderalsoneedtobeestimated,butwithlessaccuracysincetheyareoftenlessdetailed.Estimatesfortimetocompleteitemsisoftenmaintainedwithinthebacklogitself.
Prioritization
Itemsinthebacklogareorderedrelativetoeachother.Orderingcanbeestablishedusingnumbering,valuepoints,high/medium/low,oranyotherprioritizationtechnique.Theorderofitemsonthebacklogislikelytochangeoverthecourseoftheproject,especiallyastheproductevolvesandtheteamreceivesfeedbackfromthestakeholdersandcustomers.Itisimportanttonotethatorderingneartermitemsisvaluable,butputtingalotofeffortintoorderingthebacklogfarintothefuturecanbeawastefulactivitybecausethefartheroutbacklogitemsaresubjecttochange.
Managing Changes to the Backlog
Thebacklogisthemainmechanismforbothmanagingchangetotherequirementsonanagileprojectandforcontrollingscope.Whenneworchangedrequirementsareidentified,theyareaddedtothebacklogandorderedrelativetotheotheritems.Thebacklogisalsousedtotrackandmanagereporteddefectsorbugs.Orderingtheentirebacklogcanbedoneupfrontusingrelativeimportancedesignations(basedonbusinessvalue),whichallowshigh‐levelprioritizationwithoutgettingintotoomuchdetail.Sincereleasesanditerationsaretime‐boxedonagileprojects,theitemsloweronthebacklogareoftennotincludedinagivenrelease.Rigorousorderingofthebacklogallowstheteamtocontrolthescopeoftheprojectandreleases.
80 Agile Extension to the BABOK® Guide
The Discovery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
Whenanitemisdevelopedandacceptedbytheproductowner,theitemisremovedfromthebacklog.Theproductownerroleisresponsibleformanagingthebacklog,addingandorderingneworchangeditems,removingcompleteditems,andrevisingtheorderonanongoingbasis.Thisprocessissometimesreferredtoaspruningorgroomingthebacklog.
Usage Considerations
Advantages• Sincetherequirementsonthebacklogareorderedinimportance,theteamknowsthatwhattheyareworkingoninagiveniterationishighpriorityandwillcontributebusinessvaluetotheproduct.Themembersoftheteamresponsiblefordetailingtherequirementscanreviewthebackloganddetermineiftheitemsthatwillbedevelopedinanupcomingreleaserequirefurtheranalysisinordertoreadythemfordevelopment.
• Sinceeachreleasetypicallyimplementsasmallsetofrequirements,requirementsareanalyzedindetailonajust‐in‐timebasis.Whattheteamandthestakeholderslearnabouttherequirementsdevelopedduringareleasecaninformtheanalysisofotherrequirementsinupcomingiterations.
Disadvantages• Largebacklogsmaybecomecumbersomeanddifficulttomanage.Breakingtheoverallproductbacklogintobacklogsforreleases(calledreleasebacklogs)canhelpaddressthisdisadvantage.Also,alackofdetailinthestoriesinthebacklogcanresultinlostinformationovertime.
.2 Business Value DefinitionInorderforaprojecttodelivervalue,theprojectteammustfirstbeabletoidentifywhetherarequestisactuallyvaluabletotheorganization.Withoutaclearunderstandingofbusinessvalue,itispossiblefortheprojecttodeliversomethingthatsoundsvaluablebutisactuallynot.
Aprojectcreatesbusinessvaluewhenitdeliversanythingthatcontributestoanorganization'sstatedprimarygoals,forexample
• increasingorprotectingrevenue,• reducingoravoidingcosts,• improvingservice,
Agile Extension to the BABOK® Guide 81
Agile Techniques The Discovery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
• meetingregulatoryorsocialobligations,• implementingamarketingstrategy,and• developingstaff.
Oftenprojectscreateoptionsforthebusinesstoexploit.Forexample,theoptiontosell1000itemsofaproductaday.
Businessvalueshouldbeexpressedasarangeorsetofbenefits.Theevolutionofclarityaboutbusinessvaluewilldevelopunderstandingofwhytheprojectisneeded.Themostimportantaspectofexpressingbusinessvalueistheconversationthatgeneratesthesharedunderstanding.
Examplesofbadbusinessvaluestatementsare:
• Thisenablesstraightthroughprocessing.• Thiswillmake1milliondollars.• Thiswillsave1milliondollars.• Mr.Bigneedsthisproduct.
Noneoftheseshowalignmentwiththegoalsoftheorganization.
Examplesofgoodbusinessvaluestatementare:
• Thisprojectwillgenerateanadditional$20millioninprofit.Themodelisbasedonthefollowingassumptions:*Wemaintain25%ofthesalesofexistingproductXYZ($150millionayear).
• Thetotalcostofdesigning,producing,andmarketingtheproductis$7.5million.
• Ourproductisfirsttomarket.• Weareabletoreleasetheproductinthespring.
Thisstatementconveysunderstandingofwhytheprojectisneededandwouldlikelypromotevaluableconversationthatgeneratesasharedunderstandingoftheproject.
.3 Kano Analysis
Purpose
Kanoanalysishelpsanagileteamunderstandwhichproductcharacteristicsorqualitieswillprovetobeasignificantdifferentiatorinthemarketplaceandhelptodrivecustomersatisfaction.
82 Agile Extension to the BABOK® Guide
The Discovery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
Description
Kanoanalysisassistsinidentifyingfeaturesthatwillhavethegreatestimpactoncustomersatisfaction,eitherbecausetheyareexceptionallyimportantorbecausetheirabsencewillcauseintensedissatisfaction.Thishelpstheteamdeterminewhichfeaturesaremostimportanttoimplementbeforereleasingaproducttomarket.
Kanoanalysisratesproductcharacteristicsontwoaxes:
• theextenttowhichthefeatureisimplementedintheproduct,and• thelevelofcustomersatisfactionthatwillresultfromanygivenimplementationlevel.
Theresultinggraphisplottedona2×2matrix.Basedontheresultingprofile,theproductcharacteristicshouldfallintooneofthreecategories:
• thresholdcharacteristics,• performancecharacteristics,and• excitementcharacteristics.
Thisanalysiscanthenbeusedtotryandidentifycharacteristicsthatwillgivetheproductauniquepositioninthemarketplace.
Elements
Threshold Characteristics
Thresholdcharacteristicsarethosethatareabsolutelynecessaryforstakeholderstoconsideradoptingaproduct.Theirabsencewillcauseintensedissatisfactionbut,astheyrepresentminimumacceptancecriteria,theirpresencewillnotincreasecustomersatisfactionbeyondacertainlowlevel.Thechallengewithelicitingrequirementsforthesefeaturesisthatpeopleexpectthemtobepresentandsotendnottothinkaboutthemunlessexplicitlyasked.
Performance Characteristics
Performancecharacteristicsarethoseforwhichincreasesinthedeliveryofthecharacteristicproduceafairlylinearincreaseinsatisfaction.Theyrepresentthefeaturesthatcustomersexpecttoseeinaproduct(speed,easeofuse,etc).Requirementsforthesetypesoffeaturesarelikelytomostreadilycometomindforthemajorityofstakeholders.
Agile Extension to the BABOK® Guide 83
Agile Techniques The Discovery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
Excitement Characteristics
Excitementcharacteristicsarethosethatsignificantlyexceedcustomerexpectationsorrepresentthingsthatthecustomerdidnotrecognizewerepossible.Theirpresencewilldramaticallyincreasecustomersatisfactionovertime.Asthesecharacteristicsarenotmetbyanythingcurrentlyonthemarket,stakeholderswillnottendtothinkaboutrequirementsthatdescribethem.
Usage Considerations
Inordertodeterminethecategorytowhichacharacteristicorfeaturebelongs,customerscanbesurveyedusingtwoformsofaquestionaboutthefeature:
• Functionalform:Howdoyoufeelifthisfeatureorcharacteristicispresentintheproduct?
• Dysfunctionalform:Howdoyoufeelifthisfeatureorcharacteristicisabsentintheproduct?
Possibleanswerstoeachquestionformare:
• Ilikeitthatway.• Iexpectittobethatway.• Iamneutral.• Icanlivewithitthatway.• Idislikeitthatway.
Determiningthecategoryisbasedonmappingtheanswerstobothformsofthequestiontothefollowinggrid.Thetoprowrepresentstheanswerstothedysfunctionalformofthequestion.Theleftcolumnrepresentstheanswerstothefunctionalformofthequestion.
84 Agile Extension to the BABOK® Guide
The Discovery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
TABLE 4.4 Kano Analysis Questions Grid
Thisapproachismostapplicableforconsumerproductsorgoodsthatwillberesold,asitfocusesonidentifyingrequirementsthatwillencouragewidespreaduseoradoptionofaproduct.Thecategorizationofaparticularcharacteristictendstoshiftovertime,ascustomersgrowtoexpectfeaturesorcharacteristicstobepresentinaproduct.Exciterseventuallybecomeastandardexpectationandthresholdcharacteristic(thinkofthenoveltyofATMswhentheywerefirstintroduced;nowcustomersassumetheirbankwillhaveATMs).
.4 MoSCoW Prioritization
Purpose
Toidentifythemostcriticalsetoffeaturesorstoriesthatwilldeliverbusinessvalueandproducedasequenced,prioritizedlist.
Description
MoSCoWisamethodtoprioritizestories(orotherelements)inincrementalanditerativeapproaches.MoSCoWprovidesawaytoreachacommonunderstandingonrelativeimportanceofdeliveringastoryorotherpieceofbusinessvalueintheproduct.
Allstoriesinthebacklogarevaluable,butoftennotallofthemcanbedeliveredatthesametime.MoSCoWprovidesamechanismfor
Like Expect Neutral Live With Dislike
Like Q E E E P
Expect R I I I T
Neutral R I I I T
Live With R I I I T
Dislike R R R R Q
E=Exciters
P=Performance
T=Threshold
I=Indifferent(Doesnotfitintooneofthe3categories)
QorR=QuestionableorReversed(theanswerdoesn'tmakesense)
Agile Extension to the BABOK® Guide 85
Agile Techniques The Discovery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
prioritizingstoriesinabacklogacrossmultiplereleases.Prioritizationisimportantforanysoftwaredevelopmentapproach,butagileapproachescannotsucceedwithoutconstantandfrequentprioritizationofwork.
MoSCoWgetsitsnamefromanacronymformedbythefollowingclassificationsofpriority:Musthave,Shouldhave,Couldhave,andWon'thave.Theletteroisaddedtomaketheacronympronounceable.Theclassificationsareasfollows:
• Must:TheuserstoriesthataddsignificantvalueandconstituenttheMinimalMarketableFeatureset.
• Should:Theuserstoriesthatadddistinctvalue,butarenotrequiredfeatures.
• Could:Theuserstoriesthataddsomevalue,buthaveminimalimpactonfeatures.
• Won't:Theuserstoriesthataddlittletonovalue,andwillnotbeincludedasfeatures.
Thereisanexpectationthatprioritiescanchangeoverthelifeofaproject,andprioritiesarereassessedonaregularbasis.
Elements
Product Backlog
Acollectionofuserstoriesdescribingthedesiredfunctionalityofaproduct.
Strategy
Anunderstandingoftheoutcomesforaninitiative.
Customer Preference
Clarityonwhatismostimportanttothecustomer.
Usage Considerations
MoSCoWisusefulwhentryingtoprioritizeabacklog.Unlikesomeprioritizationmethods,thismodelhelpsdifferentiatebetweenasetofusefuluserstoriesfromthosespecificallyfocusedonanoutcome.AftergroupingthebacklogelementsintheMoSCoWcategoriesitisimportanttothensequenceatleasttheMustHaveandShouldHaveelementsintoaranked/numberedorderasthiswillbeusedtosequencetheworkonthebacklogitems.
86 Agile Extension to the BABOK® Guide
The Discovery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
SometoolsmaynotsupportMoSCoWasaprioritizationstructureandmayneedtobeconfiguredtosupportit,inwhichcaseanalternatecategorizationmaybeappropriatesuchas“High,Medium,Low”.
Advantages• MoSCoWiseasytodescribeandtypicallyispowerfulinprioritizingbacklogs.
Disadvantages• MoSCoWcanbesubjective.Ifthereisnoteffectivecollaborationamongtheteammemberswithacarefulfocusonbusinessvaluethismethodofprioritizationcanbeinaccurate.
• Onaprojectwhereabusinessvalueincrementsapproach(MinimalMarketableFeatures)isused,theteamshouldonlydeliverMustHavesintheincrement.MoSCoWisthereforeinappropriate,howeveritisstillimportanttoprovideasequencedlisttoprovideguidancefortheorderinwhichworkshouldbeundertaken.
.5 Purpose Alignment Model
Purpose
Thepurposealignmentmodelisusedtoassessideasinthecontextofcustomerandbusinessvalue.Fromanagileperspective,themodelaidsinmakingprioritizationdecisionsandfocusinginvestmentonthosefeaturesorcapabilitiesthatareofgreatestvaluetotheorganization.
Description
Thepurposealignmentmodelisusedtorateactivities,processes,products,orcapabilitiesintwodimensions,andusethatinformationtohelprecommendthebestactionstotaketoimprovethembasedonthoseratings.Thefirstdimensioniswhetherornottheactivitycreatesmarketdifferentiation,theseconddimensioniswhetherornottheactivityiscriticalforthecontinuedfunctioningoftheorganization.
Agile Extension to the BABOK® Guide 87
Agile Techniques The Discovery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
Thefollowingillustrationisanexampleofapurposealignmentmodel.
FIGURE 4.6 PurposeAlignmentModel
Elements
Differentiating Quadrant
Features,products,orservicesthatbothservetodifferentiatetheorganizationinthemarketplaceandarecriticaltothefunctioningofthecompanyarepartofthedifferentiatingquadrant.Thesearethethingsinwhichtheorganizationshouldbepreparedtoinvesttooffersomethingthatisdistinctfromcompetitorofferings.Adifferentiatingactivityisonethatmightbeusedtoadvertisethecompany,thatisdifficultforcompetitorstomatch,orotherwisehassignificantstrategicvalue,andauniqueapproachtotheseactivitiesislikelytobeneeded.
Parity Quadrant
Thingswhicharemissioncritical,butnotmarketdifferentiating,fallintotheparityquadrant.Manystandardfunctions,suchasfinance,HR,payroll,andothersfallintothisquadrantformostorganizations.Activitiesinthisquadrantareimportantbuttheydonotprovidean
88 Agile Extension to the BABOK® Guide
The Discovery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
advantagetothefirminrelationtocompetitorsandsoadoptionofbestpracticesisgenerallysufficient.
Partner Quadrant
Activitiesthatmayhaveuniquevaluetocustomers,butwhicharenotcriticaltothefunctioningoftheorganization,fallintothepartnerquadrant.Eventhoughtheseactivitiesareimportanttocustomersorotherstakeholders,theorganizationdoesn'tneedtoperformthemtosurvive.Thatmeansthattheorganizationisunlikelytohavetheresourcestoexcelattheseactivities(asmoremission‐criticaloperationswilltakeprecedence),whileapartnermayperformthemmoreeffectively.
Who Cares? Quadrant
Activitieswhichareneithermission‐criticalnorhelptodifferentiatetheorganizationinthemarketplacefallintothewhocares?quadrant.Astheseactivitiesdonotaddcustomervalue,andtheorganizationcanfunctionwithoutperformingthem,theyareprimecandidatestobeeliminatedandtheresourcesreallocatedtosupportmoreusefulwork.
Usage Considerations
Thepurposealignmentmodelisdesignedforusebyfor‐profitorganizationsthatfacecompetitioninthemarketplace.Governmentalorganizationsandno‐profitsmayfindthatmarketdifferentiationisnotasignificantdriverfortheirdecisions.Stakeholderormembervalue,alignmentwiththeorganizationalmissionordeliveryofsocialgoodmayserveasanalternativetothemarketdifferentiationdimension.Evenwhendifferentlabelsareusedforthedimensions,thethinkingbehindtheuseifthemodelremainsthesame.
Secondly,themodelprovidesguidanceonwhethersomethingshouldbeanareaofstrategicconcernbutdoesnotprovideanyguidanceonwhatstrategiesordecisionsmightbethecorrectones.
Advantages• Oneofthekeyadvantagesofthismodelisitssimplicity.Itcanbetaughttobusinesssponsorsandusersinacoupleofminutessothattheycancriticallyassessanideathemselvesratherthanthebusinessanalystdotheanalysisthatmaythenbechallenged.
• Themodeliseasytouseinafacilitatedcollaborativeenvironment.• Itcanbeappliedallthewayupanddowntheinvestmentdecisionprocess.Fromstrategicinvestmentdowntoanindividualfeatureinasystem.
• Itisfastandentirebacklogcanbeanalyzedinlessthananhour.
Agile Extension to the BABOK® Guide 89
Agile Techniques The Delivery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
Disadvantages• Itassumespositiveintentinthebusinessstrategy.Itdoesnotincorporate“spoiler”behaviourbycorporations.
4.6 The Delivery FrameworkTheDeliveryFrameworkdealswiththehowsandthewhensoftheproduct.Effectivedeliveryissupportedbyfourunderlyingprinciples:
• GetRealUsingExamples,• UnderstandWhatisDoable,• StimulateCollaborationandContinuousImprovement,and• AvoidWaste.
4.6.1 Get Real Using Examples
Inagileapproaches,inordertoelicitandvalidateproductneedsbusinessanalysispractitionersuserealcustomerexamplestocommunicatewiththeteam,includingthecustomer.Realexamplesservetobridgeunderstandingofthecustomer'sbusinessandhowtheyseetheproductservingafuturestateneed.Analysismodelscanbeconcurrentlydevelopedandelaboratedusingthesesameexamples.Modelsmaybeusefulfortheteambutexamplesaremoreconcreteforthecustomer.Thetechniquesareusediterativelybyalternatingbetweenexamplesandanalysismodelstoexploremultipledimensions(forexample,userrole,useractions,data,andbusinessrules)ofaproductneed.Thisisacontinuouspracticethatbuildsasharedteamunderstandingofproductneedsusefulforbothplanninganddelivery.Thesetechniquesengagecustomersinrequirementselicitation,analysis,andvalidation.
Examplesandmodelsshouldbeatalevelofgranularitythatisappropriatefortheoutcomeyouseek.Whenplanningtheproduct,modelsareusedtosetcontextandhelptheteamandcustomeridentifyscope.Thesemodelsaremoreabstractandprovideabroadperspectiveoftheproblemdomain.Whendeliveringtheproduct,thesamemodelcanbeprogressivelyelaboratedandrelatedexamplesareelicitedandspecifiedtolaunchintoadeeperdiscussionofthedimensions.Theexamplescanbeusedtoderiveacceptancecriteria,
90 Agile Extension to the BABOK® Guide
The Delivery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
helpthedeveloperdesignthesolution,andprovideafoundationforfunctionaltesting.
Thefollowingsectionsdescribecommonlyusedtechniquesforthisprinciple:
• BehaviourDrivenDevelopment.
ThereareothertechniqueswithintheAgileExtensiontotheBABOK®
Guide,theBABOK®Guide,andotheradhoctechniquesthatcanbeutilizedhereaswell.
.1 Behaviour Driven Development (BDD)
Purpose
Anapproachthatenhancesthecommunicationbetweenstakeholdersandprojectteammembersbyexpressingproductneedsasconcreteexamples.
Description
Traditionalbusinessanalysistechniquesofteninvolvecreatinganalysismodels.Inadditiontoanalysismodels,agiletechniquesfavourcommunicationusingexampleswhicharemoreconcreteforthecustomer.Manypeopleareuncomfortablewithabstractionsandprefertoworkwithrealexamples.
Examplestendtobeadditive(growinginbothclarityoftheneedanddetailofthesolutionastheprojectprogresses)andcanformaspecification.Theycanbeusedduringagileplanninganddeliveryworktohelpclarifyanddescribetherequirementsfortheproductbeingbuilt.Asmodelschange,examplescanberefinedbybuildingonpreviousexamples.Inagile,itishelpfultoiteratebetweenusingexamplesandanalysismodelsencouragingthemtocomplimenteachother.Progressiveelaborationleadstoricherexplorationofmultipledimensions(forexample,userrole,useractions,data,andbusinessrules)relatedtotheexample.
Supplementingproductneeddiscussionswithexamplescreatesamuchmorestablesetofrequirementsthanusingamodelalone.Examplesfeedsmoothlyintoabehaviour/testdrivendevelopmentapproach.
Agile Extension to the BABOK® Guide 91
Agile Techniques The Delivery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
Elements
Examples
Examplesmayalsobeknownasscenarios.Examplesshouldnotbeartificialormadeup.Theyshouldbereallifebusinessscenariosprovidedbythebusinessusers.Businessanalysisactivitieshelptofacilitatethediscoveryoftheexamplesandensurethatthesetofexamplesiscomprehensive.Notallexamplesidentifiedwillnecessarilybewithinthescopeofadevelopmenteffort.
Behaviour Driven Development
Behaviourdrivendevelopmentprovidesasimplegrammarformatthatallowsrealscenariostobefilledin.Thistakestheform
• GIVEN<acontext>• WHEN<anevent>• THEN<anoutcome>
BothGIVENstatementsandmultipleTHENoutcomesforasinglescenariocouldbecompoundconditionslinkedwithANDstatements.ThereisnormallyonlyoneWHENeventthattriggersthescenario.
Forexample,anATM.
Scenario1:Accounthassufficientfunds.
• GIVEN:I'mincredit• ANDtheATMhassufficientcashavailable• WHEN:Irequest$20• THEN:Ireceive$20• AND:myaccountbalanceisreducedby$20• AND:mycardisreturned
Scenario2:Accounthasinsufficientfunds.
• GIVEN:I'minoverdrawn• ANDtheATMhassufficientcashavailable• WHEN:Irequest$20• THEN:Ireceivenomoney• AND:mycardisreturned
Scenariosthatarewritteninabehaviourdrivendevelopmentformatspecifyingevents,conditions,andactionsareverifiable.Theycanserveasacceptancecriteriaforstories[See“StoryElaboration”on
92 Agile Extension to the BABOK® Guide
The Delivery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
page68]andserveastestsinsupportofAcceptanceTestDrivenDevelopment(ATDD)thatdriveacommonunderstandingofrequirementsandfutureproductneeds.
ThetermsBDD,ATDD,andSpecificationbyExampletendtobeusedinterchangeablyingeneraluse.
Testing
Therearenowanumberofsoftwareproductsthatwilltakeexamplesinthisformat(butmayhavetheirownspecificsyntaxandstructure)andallowthemtobeeasilyconvertedintoautomatedtests,thusenablingmoreagiledelivery.Withacomprehensivesetofexamplesthatcanbeexecutedasautomatedtests,businessanalysisandtestingactivitiescanbemoretightlycoupled.
Usage Considerations
BDDisatechniquetomakeneedsclearandisdesignedtoimprovecommunicationandunderstandingacrossallmembersofaprojectteam.Technicalteammembersusetheexamplestounderstandwhattheproductneedstodo(development)andhowtoensurethatitdoeswhatisneeded(testing).Customerrepresentativesprovidetheexamplesandclarifytheirthinkingbydoingso.BusinessAnalysisentailsidentifyingthescenariosbyaskingmany“what‐if”questiontoexposeadditionalscenariosandexpressingtheseasadditionalexamples.
Advantages• BDDexpressescustomerneedsinnaturallanguage,inaformatthatallteammembersshouldbeabletoeasilyunderstand.
• ThestructureofBDDlendstowardsacceptancetestautomationandsupportstheproductionofeffectivetestcases.
• ToolsexisttosupporttheuseofBDDinprojects,andtheseprovideadditionalmetricssuchastestcasecoverageorrequirements.
• Scenarioscanbeeasilyprioritizedwhichsupportstheiterative,incrementalnatureofagileprojects.
Disadvantages• Itispossibletomissimportantscenariosunlessthereissomeonewhoactivelyasksthe“whatif”and“whatabout”questions.
• Wherebusinessrulesareverycomplextherecouldbetoomanyscenariostoeasilymanageandtrackwithouttoolsupport.
Agile Extension to the BABOK® Guide 93
Agile Techniques The Delivery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
4.6.2 Understand What is Doable
Asanagileprojectteamplansfordelivery,itisimportanttothinkaboutwhatispragmaticanddoable.Theteammustbalancecapacityanddemandwhentheyestimatetheworktobedonetodelivertheproduct.Agileprojectteamscontinuallyreviewmeasures,suchasteamcapacity,priordeliverycyclecommitmentsandactuals,andvelocitytrendstoadjustcommitmentsonanon‐goingbasis.Thisenablestheteamtoquestionwhatcanbedeliveredgiventheirknowledgeofthework‐set,andtosetappropriateexpectationsandmakebetterestimates.Understandingwhatisdoableoccursthroughoutanyagiledeliverycycle,suchasreleaseplanning,work‐aheadanalysis,orwheneverateamispullingnewbacklogitemsforconsiderationinaproductdeliverycycle.
Theentireteamusesthefollowingtechniquesasmethodstoidentifyandestimateunitsofworkthataredecomposedwithbusinessvalueinmind.
Thefollowingsectionsdescribecommonlyusedtechniquesforthisprinciple:
• RelativeEstimation,• PlanningWorkshop,and• RealOptions.
ThereareothertechniqueswithintheAgileExtensiontotheBABOK®
Guide,theBABOK®Guide,andotheradhoctechniquesthatcanbeutilizedhereaswell.
.1 Relative Estimation
Purpose
Accurateestimationiscriticaltoanagileteam'sproductivity,reliability,andreputation.Bybeingabletodevelopaccurateestimatesofcost,time,andeffort,theagiledevelopmentteamhastheabilitytofaithfullycommittoaprojectorworkeffort.
Estimationisateamactivity,andbusinessanalysismakesanimportantcontributionbyhelpingtheteamtobetterunderstandthecomponents,characteristics,andcomplexityofthework.
94 Agile Extension to the BABOK® Guide
The Delivery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
Althoughestimatesarenotalwaysvisibleinthefinalproduct,theydoaddsignificantvaluetoanagileproject.Providingcredibleestimatesallowstheprojectteamto:
• determinecostandeffort,• establishtheprioritiesoftheproject,and• committoaschedule.
Onagileprojectsestimationisnotrestrictedtobeinganinitialplanningactivity,itisfrequentlyundertakenearlyintheprojectduringtheinitialstoryidentificationactivitiesandestimatesarerefinedandimprovedthroughconstantfeedbackintheongoingiterationplanningactivities.
Description
EstimationisdiscussedatlengthintheBABOK®Guideversion2.0(9.10Estimation).HerewebuildontheinformationintheBABOK®Guideandsummarizetherelativeestimationtechniquesthatcanbeappliedintheagiledevelopmentenvironment.
Uniquetoagileapproaches,estimatingisprogressiveandoccursinalignmentwithiterations.Nooneexpectsearlyestimatestobeasaccurateaslatterestimates.Improvementoccursovertimeastheteamsbuildconfidenceintheircapacityandcapabilities.
Inadditiontothebasicapproachofestimatingbasedonhistoricalknowledge,agileestimatorsfrequentlyapplyarelativeestimatingmodelinwhichteamsdevelopnarratives(stories)thatdefineuserneedsandbenefits.Thesestoriesareanalyzedbytheteamandnumericvaluesareappliedtoeachstory(storypoints).Storypointsarenormallyusedasanabstractmeasurementthatprovidesanumericvaluetoastory;someteamsandorganizationsuseidealdeveloperdays(IDDs)insteadofrelativepoints,althoughmanycommentatorsrecommendagainstthisapproach.
Astorypointisarelativenumberassignedtoeachstorythatdefinestheestimatedeffortateamwillhavetoapplytodeliverthestory.Storypointsareusuallybasedonwhattheteamknowsaboutthestoryinfourkeyareas:
• Knowledge:Howmuchinformationdoestheteamhave?• Complexity:Howdifficultistheimplementationlikelytobe?• Size:Howbigisthestory?Howlongwillittake?
Agile Extension to the BABOK® Guide 95
Agile Techniques The Delivery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
• Uncertainty:Whatvariablesandunknownfactorsmightimpactthestory?
Thetotalnumberofstorypointsdelivered(totheagreedDefinitionofDone)withinanygiveniterationisconsideredtobetheteam'svelocity,orhowmuchateamaccomplishedwithintheiteration.Overseveraliterationsteamswillhaveabetterunderstandingoftheiractualvelocity.Thiswillallowthemtomakebetterinformedestimatesandcommitmentsinsubsequentiterations.
Thereareseveralwaystogetstartedwithstorypointestimation.Theagileestimatorcanbeginwith
• anorderofmagnitude,• agivensetofresourcesandafixediteration,or• ateambasedestimationofthetimerequiredforasampleofstoriesofdifferentsizes,andthenextrapolatefromtheretoestimatetheworkthatcanlikelybedoneinaniteration.
Usage Consideration
Advantages• Relativeestimationisasimple,reliablemethodologythatfitswellwithagilepractices.Itishighlyadaptiveandislikelytobecomeincreasinglyaccuratethroughoutsuccessiveiterations.
• Theplanningpokertechniqueisahighlycollaborativeprocessthatisbasedonconsensusandwilllikelyhaveapositiveimpactondevelopmentteams.Itbuildsuponthewisecounselto“asktheteam.”
Disadvantages• Relativeestimatesarebasedonhistoricaldata,andaccuracyisdependentuponthesimilarityofnewstoriestostoriespreviouslydelivered.Ifnewstoriesdifferradicallyfrompreviousstories,itispossiblethattheaccuracyoftheestimatemaydecrease.
• Theaccuracyofvelocityisdependentontheknowledgeandexperienceofthedevelopmentteamworkingtogether.Anychangestoteamcompositionwillimpactvelocityandthereforefutureestimates.
• Planningpokerandrelativeestimationarenottheonlyapproachestoestimationandnotallteamsestimatetheirworkbeforestarting.Thereareotherapproacheswhicharenotdefinedindetailhere,andothermetricswhichareoftentracked.
96 Agile Extension to the BABOK® Guide
The Delivery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
.2 Planning Workshop
Purpose
Toenabletheteamtodeterminewhatvaluecanbedeliveredoveranagreedtimeperiod.
Typicallytherearetwolevelsofplanningworkshop:
• onethatcoversthecurrentreleaseoftheproductandtakesplacepriortothestartofiterations,and
• amoredetailedworkshopthatfocusonworktobedoneduringtheiteration.
Description
Aplanningworkshopisexecutedwhentheteamneedstoarriveatacommitmenttosomesetoffunctionalitythattheyfeelreasonablyconfidenttheycancompleteoveranagreedtimeperiod.
Thereleaseplanningworkshopproducesthereleaseplanshowingtheintendedsequenceofdeliveryofuserstoriesoverthewholerelease.
Theiterationplanningworkshopisperformedatthebeginningofeachiteration,butmayalsooccurwhenevertheteamisneartocompletingtheirbacklogofworkorthatbacklogneedstobeordered.Itisimportantthattheteamunderstandsandfocusesontheiterationobjectives,thevalueassociatedwithaparticularMMF,businessissues,storydecomposition.Priortotheworkshop,thereisapre‐planningstagethatinvolvesanalysistogetareasonablegaugeofthesize,scope,andcomplexityofeachbacklogitemthatwillbebroughttotheiterationplanningworkshop.
Inagileapproachesplanningworkshopsneedtobeperformedonafrequentandregularbasisastheorderinwhichworkismeanttobeperformedisregularlyalteredandupdated.Thisallowstheteamandcustomerstochangetheprioritiesofoutstandingworktoincorporatefeedbackorchangingbusinessneeds.
InKanban,theamountofworkbeingperformedbytheteamislimitedbyrestrictingthenumberofworkitemsthatcanbeinanyworkflowstate,notbasedoniterations.
Agile Extension to the BABOK® Guide 97
Agile Techniques The Delivery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
Elements
Estimated and Ordered Backlog
Typicallybasedonuserstories,itisthemaininputfortheplanningmeeting.
Team Velocity
Priorvelocity(throughputcapacityofbacklogitems)iscriticaltoenablingtheteamtoschedulearealisticamountofwork.WhenusingKanban,work‐in‐progress(WIP)limitswillbeusedtomanagethisworkloadinstead.
Iteration Goal or MMF Set
Manyteamssetanoverallgoalfortheiterationtohelpguidetheselectionoffeatures.Thisisasubsetofthereleasegoal.Itisanobjectivethatwillbemetthroughtheimplementationoftheproductbacklog.
Requirement Selection
Atthebeginningofthemeetingtheiterationgoalandthehighestpriorityfeaturesareselectedfromthereleaseplanbytheproductowner,productchampion,oracustomerbasedonbusinessvalueandteamvelocity.
Non-Feature Selection
Thebacklogcanalsobecomposedofnon‐featureitems(elementsnotrelatedtoaproductincrement)identifiedasnecessarytoachievetheiterationgoalordeliveranMMF.Forexample,therecanbebugstobefixed,systemorenvironmentsetup,researchinitiatives,managementworkitems,oranyotheractivitythataddvaluetotheproject.
Task Planning
Theteamcanchoosetobreakthefeatureandnon‐featureitemsdownintotasks.Taskstypicallyrangeinsizefrom4hoursto2days,withmosttaskscapableofbeingdeliveredwithinaday.
Usage Considerations
Advantages• Customer,productowner,anddevelopmentteamcancommunicateandcollaboratefrequentlyaboutproductvisionandevolution.
• Customerandproductownercanguidetheprojectnotjustatthestartbutateveryiteration.
98 Agile Extension to the BABOK® Guide
The Delivery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
• It'seasiertounderstand,estimate,andplanthescopeofsmalliterationsinsteadofthescopeofbigreleases.
• Planscanbechangedinadvancebasedonfeedbackfromincrementaldeliveryofworkingsoftware.
• Iterationplanningcanfacilitatevisibilityofthewholeprojectandsynchronizationbetweenmultipleteams.
Disadvantages• Itisnecessarytogetallpeopletogetherinordertoavoidinterruptionsandrework,especiallywhenworkingwithdistributedorconcurrentteams.
• Iftheproductisnotwellunderstoodduringtheiterationplanningworkshop,it'spossibletoresultinasuboptimalplan.
.3 Real Options
Purpose
Anapproachtohelppeopleknowwhentomakedecisionsratherthanhow.Theapproachhelpsyouunderstandwhetheryouhaveacommitmentoranoption.
Description
Thecoreconceptbehindrealoptionsisthatyoushoulddelaymakingadecisionoracommitmentinaprojectuntilthelastresponsiblemoment,whenthedecisionreallyneedstobemade.Therealoptionapproachhasthreesimplerules:
• optionshavevalue,• optionsexpire,and• nevercommitearlyunlessyouknowwhy.
Thefirstandthirdruletellyoutoavoidcommitmentsandkeepyouroptionsopen.Thesecondruletellsyoutounderstandwhenanoptionexpiressothatyoucanactivelymanagewhetheryouchoosethatoptionorletitlapse.Asthereisvalueinoptions,youshouldseektoextendthematurityoftheoptions.
Realoptionsaddresspeople'saversiontouncertaintybyprovidingtheconditionswhenacommitmentshouldbemade(theoptionexpiry)ratherthansimplysuggestingthattheywait.
Themostcommonusageofrealoptionswithinagileprojectsisthewayinwhichbusinessinvestorschosewhichitemtoinvestinnext.
Agile Extension to the BABOK® Guide 99
Agile Techniques The Delivery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
Traditionally,investorsprioritizetheirrequirementsforanextendedperiodoftime.Withrealoptions,theyonlyprioritizeuntilthenextinvestmentdecisionpoint.OnScrumprojectsthisoccursduringthenextsprintplanningsession.InKanban,itoccursthenexttimecapacitybecomesavailabletoworkonsomethingnew.
Realoptionssupportagileapproachesbyallowingustoreducethenumberofdecisionswehavetoconsideratanyonetimeanddelayingdecisionsaboutthedetailofrequirementsaslongaspossible.Thisisachievedbytreatingthedetailofrequirementsasoptionsandthecommitmentpointiswhenweelaborateindetail.
Elements
Options and Commitments
Realoptionsforcesyoutoidentifywhetheryouhaveoptionsornot,andalsoforcesyoutoidentifythecommitmentsyouaremaking.
Examplesofoptionsinclude:
• Auserstory:anoptiontoimplementapieceoffunctionality.Theoptionexpireswhenthebusinessneedchanges.
• Ahotelreservation:anoptiontostayatthehotel.Theoptionnormallyexpiresat6p.m.onthedayofthestayatwhichpointyouarecommittedtopayingforthehotelroom.
• Abusinesscard:theoptiontocontactthepersonwhogivesyouthecard.Theoptionexpireswhenthepersonchangescontactdetails.
Optionsarethingsyoucanchosetodoornotdo.Ifyouarecommittedtodoingsomethingandthereisonlyoneway,thenyoudonothaveoptions.Oftenthereisapenaltyassociatedwithfailingtomeetacommitment.
Someexamplesofcommitmentsinclude:
• Usingtheorganization'sstandardsoftwaredevelopmentlanguagetobuildaproduct.
• Turninguptoworkontime.Failuretomeetthiscommitmentmayresultinterminationofyourcontractofemployment.
• Deliveringitemsfromthebacklogthatyouhavecommittedtodeliver.Failuretomeetthiscommitmentwillreducetrustanddamagetheteam'sreputationwithcustomers.
100 Agile Extension to the BABOK® Guide
The Delivery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
Examplesofthingsthatarenotoptions.
• Thingsyoucannotdo.• Thingsyoucannotafford.• Thingsyoucannotdointime.• Thingsyoucannotbuyorsell.• Thingsyoudonothavethetoolsfor.
Options Expiry
Realoptionsforcesustounderstandwhenouroptionsexpireorwhenwenolongerhaveachoice.Wehaveanoptionuptotheexpirydatebutnotafterit.Infinancialoptions,theexpirydateoftheoptionisexplicitlystatedasaseriesofdate/times.Inrealoptions,theexpirydateisconditional.
Determinationofwhenanoptionexpiresisthemostimportantaspectofrealoptions.Withoutthisknowledgeyouareblindinyourdecisionprocess.Youeithermakedecisionstoosoonortoolateandyoudonotknowwhich.
Example
Youhaveauserstoryinthebacklogwhichisduetobedeliveredinthenextiteration.Priortotheiterationplanningworkshopyoucanelaboratethestorytoacceptancecriteriatoensurethereissufficientunderstandingthatthepieceoftheproductcanbebuilt.Notdoingthestoryelaborationcouldresultinsurpriseswhentheworkisstartedonthestorywhichmayresultintheteambeingunabletomeettheircommitmentsforthecurrentiteration.
Asoptionshavevalue,pushingtheexpirydatebackaddsvaluetoyourprojectandallowsyoumoreflexibility.Theconceptofthe“lastresponsiblemoment”iskey‐makingdecisionstooearlyrestrictsourchoices,anddeferringthemtoolongcanresultinreworkorotherwaste.
Right / Wrong / Uncertain
Arationaldecisionprocesswouldorderourpreferenceasbeingright,thenuncertain,andfinallywrong.Observingpeople'sbehaviourthoughtheirpreferenceisright,wrong,andthenuncertain.
Ifyouasksomeonetodeferadecision,theyarefacedwithunboundeduncertaintyandasaresulttheyarelikelytomakeadecisionbasedontheinformationtheyhavenow.Thisemotionalcommitmentthenmakesithardertochangethedecisionasfurtherinformationarrives.
Agile Extension to the BABOK® Guide 101
Agile Techniques The Delivery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
Realoptionssuggestsusingboundeduncertainty.“Makethedecisionwhen...”Specifytheconditionswhenthedecisionshouldbemade.
Specifyingtheconditionswhenacommitmentshouldbemadeallowsthedecisionprocesstobemanaged.Aseniormanagercanasktheirassistanttomonitortheconditionsonhisbehalf.
Feature Injection
Featureinjectionisacollectionoftraditionalbusinessanalysistechniquesthathavebeencombinedtoallowabusinessanalysttoperformanalysisinafastandeffectivemanner.Thisspeedthenallowsinvestmentcommitmentstobedeferredbecausethisreducesthelengthoftimethatanalysistakes.
ThespeedoftheprocessisduetofollowingtheRealOptionsprocess.Theanalysisstartswiththeoutputandthenworksbackthroughtheprocesstotheinputs.Itthenconsidershowdifferentexamplesaffecttheprocess.
Therearethreestepstotheprocess:
1. Identifythebusinessvaluewhichspecifiestheoutputs/outcomesrequiredfromthesystem/process.
2. Injectthefeaturesthatworkoutwhichprocessesandinputsarerequiredtoproducetheoutputs/outcomes.
3. Usemodelstoidentifyalltheexamplesthatproduceadifferentbehaviourinthesystem/process.
Usage Considerations
Advantages• RealOptionssimplifydecisionmakingbyprovidingasimplesetofprinciplestofollow.
• RealOptionsmakedecisionmakingfastasyouonlyfocusontheimmediatedecisionsanddeferprioritizationuntilalaterdatewhencomplexityisresolved.
• RealOptionsinformwhen,nothow,toconstructdecisions,whichmakesthembroadlyapplicableasanapproach.
• RealOptionsoptimizeprocessesbyforcingtheconsiderationofthedecisionpointsandtheinformationarrivalprocess(whendataarrivesandwhetheritarrivesbeforethedecision).
102 Agile Extension to the BABOK® Guide
The Delivery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
Disadvantages• RealOptionscanbecounter‐intuitiveastheyrequireustoanalyzesystemsfromtheoutputstotheinputs.
• RealOptionsarenotasimpleprocesstobefollowedbyrote.Theyareathinkingtoolthatrequirespracticeandstudy.
4.6.3 Stimulate Collaboration and Continuous Improvement
Agileapproachesemphasizetheimportanceofcontinualcollaborationbetweenmembersoftheprojectcommunity.Itistheroleofthebusinessanalysttocreateanenvironmentwhereallprojectstakeholderscancontributetotheoverallprojectvalue,ideallyinfacetofacefacilitatedworkshops.Therealityformanyprojectsisthattheyaredistributedintermsofteam,time,andgeography.Facilitationskills,inconjunctionwiththetechniquesoutlinedinthissection,enablescollaborationforbothlocalanddistributedteams.Thetechniquesinthissectionentailworkingtogetheringroupstocreateasharedunderstanding.Thiscollaborativepointofviewpervadesanagileproject,andisnotlimitedtoanyspecifictechnique.
Oneofthefundamentalprinciplesofallagileapproachesistheneedforcontinuousimprovement,notjustoftheproductunderdevelopmentbutoftheprocessusedbytheteamtodelivertheproduct.Thisisachievedthroughbothstructuredandunstructuredfeedbackonacontinuousbasis.Forexample,theretrospectiveisanopportunityfortheteamtoexaminetheirprocessesandproducttoidentifyopportunitiesforimprovement.Healthycollaborativeteamshavethetrustandsafetynecessarytotransparentlyidentifyopportunitiesforimprovement.
Thefollowingsectionsdescribecommonlyusedtechniquesforthisprinciple:
• CollaborativeGamesand• Retrospectives.
ThereareothertechniqueswithintheAgileExtensiontotheBABOK®
Guide,theBABOK®Guide,andotheradhoctechniquesthatcanbeutilizedhereaswell.
Agile Extension to the BABOK® Guide 103
Agile Techniques The Delivery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
.1 Collaborative Games
Purpose
Collaborativegamesarenotusedstrictlybyagileteams,althoughtheyareprevalentinagilepracticesbecausetheyemphasizetheconceptsofteamworkandcollaborationwhicharehighlyvaluedbyagilepractices.Collaborativegameshelpagroupofpeoplepromoteacommonunderstanding,gaininsightintoaproblem,orinspirenewideasaboutsolvingaproblem.
Description
Collaborativegamesrefertoseveralstructuredtechniquesinspiredbygameplayanddesignedtofacilitatecollaboration.Eachgameincludesrulestokeepparticipantsfocusedonaspecificobjective.Thegamesareusedtohelptheparticipantssharetheirknowledgeandexperienceonagiventopic,identifyhiddenassumptions,andexplorethatknowledgeinwaysthatmaynotoccurduringthecourseofnormalinteractions.Thesharedexperienceofthecollaborativegameencouragespeoplewithdifferentperspectivesonatopictoworktogethertobetterunderstandanissueanddevelopasharedmodeloftheproblemorofpotentialsolutions.
Collaborativegamesoftenbenefitfromtheinvolvementofaneutralfacilitatorwhohelpstheparticipantsunderstandtherulesofthegameandhelpstoenforcethem.Thefacilitator'sjobistokeepthegamemovingforwardandtohelpensurethatallparticipantsplayarole.
Collaborativegamesalsousuallyinvolveastrongvisualortactileelement.Activitieslikemovingstickynotes,scribblingonwhiteboards,assemblingthings,ordrawingpictureshelpovercomeinhibitions,fostercreativethinking,andthinklaterally.
Elements
Purpose
Gamesalwayshavesomedefinedpurpose,typicallytodevelopabetterunderstandingofaproblemortostimulatecreativesolutions.Theparticipantsinthegameneedtounderstandthatpurpose,andthefacilitatorwillhelpkeepthemmovingtowardit.
Process
Gamesalsohaveaprocessorrulesthattheyfollowtokeepthegamemovingtowarditsgoal.Often,eachstepinthegameistimelimited.Gamestypicallyhaveatleastthreesteps:
104 Agile Extension to the BABOK® Guide
The Delivery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
1. anopeningstep,wheretheparticipantsgetinvolved,learntherulesofthegame,andstartgeneratingideas,
2. theexplorationstep,whereparticipantsengagewithoneanotherandlookforconnectionsbetweentheirideas,testthoseideas,andexperimentwithnewones,and
3. aclosingstep,wheretheideasareassessedandparticipantsworkoutwhichideasarelikelytobethemostusefulandproductive.
Outcome
Finally,attheendofacollaborativegame,thefacilitatorandparticipantswillworkthroughtheresultsofthegameanddetermineanydecisionsoractionsthatneedtobetakenasaresultofwhattheparticipantshavelearned.
Usage Considerations
Itisnotpracticaltoelaborateonthemanycollaborativegamingtechniquesandtheirusageconsiderationsinthisdocumentbutthefollowingexamplesmayprovideastartingpoint.
TABLE 4.5 Examples of Collaborative Games
Advantages• Mayrevealhiddenassumptionsordifferencesofopinion.• Encouragescreativethinkingbystimulatingalternativementalprocesses.
• Challengesparticipantswhoarenormallyquietorreservedtotakeamoreactiveroleinteamactivities.
Disadvantages• Theplayfulnatureofthegamesmaybeperceivedassillyandbeuncomfortableforparticipantswithreservedpersonalitiesorculturalnorms.
Game Description ObjectiveProduct Box
Participants construct a box for the product as if it was being sold in a retail store.
Used to help identify features of a product that help drive interest in the marketplace.
Affinity Map
Participants write down features on sticky notes, put them on a wall, and then move them close to other features that appear similar in some way.
Used to help identify related or similar features or themes.
Fishbowl Participants are divided into two groups. One group of participants speak about a topic, while other participants listen intently and document their observations.
Used to identify hidden assumptions or perspectives.
Agile Extension to the BABOK® Guide 105
Agile Techniques The Delivery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
• Gamescanbetimeconsumingandmaybeperceivedasunproductiveespeciallyifobjectivesoroutcomesareunclear.
• Groupparticipationcanleadtoafalsesenseofconfidenceinconclusionsreached.
.2 Retrospectives
Purpose
Theobjectiveofaretrospectivemeetingisforateamtocometogetherinordertoreflectonwhatithasdonewell,whatitcoulddobetter,andtoreachagreementonhowanyimprovementswillberealizedforboththeproductandtheprocessestheyusetocreatetheproduct.Retrospectivesareheldatkeymilestonesintheproductlife‐cycle,normallyattheendofeveryiteration,andateveryreleasesothatlearningscanbequicklyembeddedintheprocessesandpracticesgoingforward.
Description
Theretrospectiveprovidesanopportunityforallmembersoftheteamtoreflectonthemostrecentdeliveries.Theretrospectiveshouldincludethewholeteam.Itiscommonfortheretrospectivetobesplitintotwoparts.Thefirstpartinvolvingthewholeteamandthesecondparttodiscusstechnicalaspectsoftheprojectthatonlyaffectpartoftheteam.
Theretrospectiveshouldbefocusedonidentifyingissueswiththeprocess.Itshouldidentifyprocessimprovements,andnotbepersonalinanysense.Akeyelementofaretrospectiveisthattheteamfeelssafetodiscussanyissuethatconcernsthem.
Itmaybeusefulforretrospectivestobefacilitatedbyaneutralfacilitatorratherthanbyamemberoftheteam.
Wherefixediterationcyclesarenotbeingused,itisagoodideatoscheduleregularretrospectivessotheteamcanexaminetheirprocesses.
Elements
Preparation
Theteampreparesideasfromtherecentiterationthatmaybeanalyzedintheretrospective.
106 Agile Extension to the BABOK® Guide
The Delivery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
Safety Check
Theteammustagree,together,totrusteachotherandtobelievethateverycommentorsuggestionisintendedforthesolepurposeofimprovingtheteam'sperformance.
Identify the Issues
Therearemanymechanismstoidentifyissuestodiscuss.Oneofthemostcommonisforallteammemberstowriteupthingsthatwentwell,thingstoimprove,andthingsofinterestonpost‐itnotes.Colourcodingthenotesandapplyingthemtoavisualtime‐lineassistinaddingunderstandingtotheemergingpicture.
Choosing Future Actions
Oncealltheideashavebeendiscussedtothesatisfactionoftheteam,thefacilitatoraskstheteamtodecidewhichsolutions/improvementstheywanttofocusonnext.Theteamthenidentifieswhichimprovementswillbeaddressedandassignsresponsibilitytoanindividualteammemberwhoensuresthesolution/improvementisimplemented.
Usage Considerations
Advantages• Anexcellentwayfortheteamtofindacollectivevoicearoundopportunitiesforteamimprovement.
Disadvantages• Teammembersmayfeelobligedtopretendthattheytrusteachother,eventhoughtheydonot.
• Retrospectivesareonlyofvalueiftheteamactsuponthelearningfromthesessiontoimprovetheprocess.
• Mostideasraisedintheretrospectiveareknowntoatleastonememberoftheteam.Amatureteamshouldbeaddressingissuesastheyariseratherthanbatchingthemuptobehandledinaretrospective.
• Ifissuesraisedintheretrospectivearenotaddressed,thereisarisktoteammoraleandmotivation.
4.6.4 Avoid Waste
Agileapproachesemphasizethedeliveryofworkingsoftwaretothecustomer.Businessanalysisworkaddsvaluebyensuringthattheneedsofthecustomerareunderstoodandthattheteamdeliverswhat
Agile Extension to the BABOK® Guide 107
Agile Techniques The Delivery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
thecustomerreallyneed.Anyactivitythatdoesnotcontributedirectlytothisgoal,orthatthecustomerwouldnotbewillingtopayfor,iswaste.
Wasteeliminationisanissuethathasbeentreatedwithgreatemphasisbytheagilecommunity.Itisamind‐setoriginatedfromLeanasaneffectivewaytoincreasetheprofitabilityofanybusiness.Leanthinkingconsidersavaluestreamashavingtwocomponents:
• valueaddingactivities,and• muda(theJapanesewordforwaste).
TheaimofLeanthinkingistoremovethemuda,orwaste,fromthevaluestream.Wasteisfurthersub‐dividedintotwocomponents:
• thoseactivitiesthathavevaluebutdonotcontributetothefinalproductdirectly,and
• thoseactivitiesthatdonotaddvalueatall.
Theaimistoremovecompletelythoseactivitiesthatdonotaddvalue,andminimizethoseactivitiesthatdonotcontributetothefinalproductdirectly.
Thefollowingprinciplesarehelpfulwhenworkingtoidentifywasteinanybusinessanalysisactivity:
• Avoidproducingdocumentationbeforeitisneeded.• Ensurecommitmentsaremetandtherearenoincompleteworkitemsthatadverselyimpactdownstreamactivities.
• Avoidreworkbymakingcommitmentsaslateaspossible.• Trytoelicit,analyze,specify,andvalidaterequirementswiththesamemodels.
• Analysismodelsshouldbeassimpleaspossible.Donotincludeinformationthatisnotdirectlyusefultoastakeholder.
• Workincloseproximitytothecustomersanddevelopmentteambecauseunnecessarymotionorwork‐a‐roundsthatsubstituteface‐to‐faceconversationsarealsowaste.
• Keepcontinuousattentiontotechnicalexcellence.Qualitydefects(suchasunclearrequirements)resultinreworkandareoneofthemostundesirableformsofwaste.
Thefollowingsectionsdescribecommonlyusedtechniquesforthisprinciple:
• LightweightDocumentation.
108 Agile Extension to the BABOK® Guide
The Delivery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
ThereareothertechniqueswithintheAgileExtensiontotheBABOK®Guide,theBABOK®Guide,andotheradhoctechniquesthatcanbeutilizedhereaswell.
.1 Lightweight Documentation
Purpose
Ensurethatalldocumentationproducedisintendedtofulfillanimpendingneed,hasclearvalueforstakeholders,anddoesnotcreateunnecessaryoverhead.
Description
Lightweightdocumentationisaprinciplethatgovernsalldocumentationproducedinanagileproject.Theteamshouldaimtoproduceaslittledocumentationaspossible,allofwhichshouldbeofvalue.Thevalueofdocumentationshouldbeexplicitandclear.Inaheavilylegislatedenvironment,suchashealth‐care,compliancedocumentationhasvalueandisnotwaste.
Thecontextplaysanimportantfactorintheamountofdocumentationrequired.Someprojectsaremandatedtoproducedocumentationbyexternalentities(forexample,regulators).Documentationmayalsobeneededtoprovidealong‐termrecordofdecisionsreachedbytheteamorfunctionsimplementedintheapplication.Thisdocumentationcanbewrittenafterthesoftwareisdeveloped,whichensuresthatitactuallymatcheswhattheteamdelivered.
Itisworthconsideringthatifadocumentisvaluableenoughtobecreated,itisprobablyimportantenoughtobeautomatedsothatitispartofthelivingcodebase.Thisconsiderationhasledtotheriseofautomatedacceptancetestingandbehaviourdrivendevelopmentthatallowsbusinessanalyststoworkwithqualityassuranceprofessionalstocreateexecutablespecificationintheformofexamples.
ThisapproachcomesdirectlyfromtheAgileManifestowhichsays“Workingsoftwareoverextensivedocumentation”.Itisoftenmisinterpretedasmeaningnodocumentation.Instead,documentationshouldbebarelysufficienttomeettheneedsoftheteam.
Usage Considerations
Advantages• Reducesamountoftimespentwritingdocumentation.
Agile Extension to the BABOK® Guide 109
Agile Techniques The Delivery Framework
ComplimentaryMemberCopy.NotforRedistributionorResale.
• Reduceseffortspentreadingandreviewingdocumentation.• Reducesnumberofdraftsofdocuments.• Allreviewerscanfocusonkeyissuesratherthanextraneousdetails.
• Training(knowledgetransfer)isdonetosuiteachpersonratherthanusingthedocumentation.
• Thedocumentationlivesintheformofautomatedexamples.
Disadvantages• Producinglightweightdocumentationmaycauseconflictwithgroupswhoenforcecorporateprocessstandards.
• Somemaymisunderstandtheprincipleasmeaningnodocumentation.
• Someproducedocumentationthatisnotsufficientforanexternalentity.
110 Agile Extension to the BABOK® Guide
The Delivery Framework Agile Techniques
ComplimentaryMemberCopy.NotforRedistributionorResale.d
Agile Extension to the BABOK® Guide 111
ComplimentaryMemberCopy.NotforRedistributionorResale.
AappendixGlossary
Acceptance CriteriaRequirementsthatmustbemetinorderforasolutiontobeconsideredacceptabletokeystakeholders.Acceptancecriteriacanrefertoarequirementofanygranularity,product,ordeliverycycle.
Acceptance Test Driven Development (ATDD)Involveswritingoneormoretests(or“customertests”)foracustomer‐centricfeature,beforethesolutionhasbeendeveloped.
Agile ManifestoAstatementoftheprinciplesthatunderpinAgileSoftwareDevelopment.ItwasdraftedfromFebruary11ththrough13th,2001.
Agile RetrospectiveRetrospectivesareavariationofprojectretrospectiveswherebytheretrospectiveworkshopisconductedatregularintervalsthroughoutthedeliveryprocess,suchasaftereachiterationand/orrelease.
Anti-patternAcommonlyused,yetineffective,processorpractice.
BacklogAwishlistofrequestsforfeaturestobeincludedinaproduct.
Backlog ItemAnelementthatbelongstoabacklog.Itcanbeafeature,abugfix,adocument,oranyotherkindofartifact.
Behavior Driven Development (BDD)Arequirementselicitationandspecificationtechniquethatenhancesthecommunicationbetweenbusinessusersandthedevelopmentteambyusingrealexamples.
Burndown ChartUsedtotracktheworkremainingovertime.WorkremainingistheYaxisandtimeistheXaxis.AlsoseeReleaseBurndownChart.
Business ValueInmanagement,businessvalueisaninformaltermthatincludesallformsofvaluethatdeterminethehealthandwell‐beingofthefirminthelong‐run.Inagiledevelopment,businessvalueisrelatedtoalldeliverablesthatincrease/protectrevenueorreduce/avoidcostsinabusiness.
CeremoniesControlledprocessesanddocumentsthatconstituteeventsandoutputsinanygivenapproach.Ahighdegreeofceremonyfrequentlyimpliesahighdegreeofcontrolandtraceability.Basedonthejust‐in‐time
112 Agile Extension to the BABOK® Guide
ComplimentaryMemberCopy.NotforRedistributionorResale.
andjust‐enoughmodel,agileprojectsgenerallyhavealowerdegreeofceremony.Agileceremoniesincludeiterationplanning,dailymeetings,andretrospectives.
Class-Responsibility-Collaboration (CRC) CardsAbrainstormingtoolusedinthedesignofobject‐orientedsoftware.
Daily MeetingOneachdayofaiterationtheteamholdsmeetings.Thismeetingisusedtosettheprioritiesandcontextforthedailywork.
Daily Scrum MeetingSeeDailyMeeting.
Daily StandupSeeDailyMeeting.
Delivery TeamAcross‐functionalteamofskilledindividualswhobringavarietyofexpertisetobearontheprocessofbuildingasoftwareproduct.
ElicitationAnactivitywithinrequirementsdevelopmentthatidentifiessourcesforrequirementsandthenuseselicitationtechniques(forexample,interviews,prototypes,facilitatedworkshops,documentationstudies)togatherrequirementsfromthosesources.
EpicApieceoffunctionalitythatenablesausertoachieveaclearlyidentifiedbusinessobjective.Epicsareoftenlargecomponentsofworkthatare
decomposedintosmallerstoriesandfeatures.Anepichelpstiefeaturesandstoriesbacktoavalue‐addedbusinessobjective.
Feature Adiscreetpieceoffunctionalitythathasmeasurablebusinessvalue.Afeatureisoftendeliveredthroughthedevelopmentofanumberofuserstories.
Iteration BurndownSeeProductBurndownChart.
Iteration PlanningTheprocessofassigninguserstoriestoparticulariterationsbasedonresources,effort,andpriority.
Just-in-time RequirementsRequirementsthatdefineonlywhatisneededforthecurrentiterationandonlytothelevelofdetailrequiredfortheteamtodelivertheitem.
Minimal Marketable Feature (MMF)Acoherentportionoffunctionalitythatiscapableofreturningvaluewhenreleasedonitsown.Thiscouldbeanepicorastory,butisanylevelofdetailthatisminimallyrequiredtocreateameaningful,valuablereleaseforthecustomer.
Minimal Viable Feature (MVF)Commonlyusedwithnewproducts.AlsoseeMinimalMarketableFeature.
Agile Extension to the BABOK® Guide 113
ComplimentaryMemberCopy.NotforRedistributionorResale.
On-site CustomersThetermusedfortheindividualresponsiblefortherelativeprioritiesforthesolutionrequirementsintheExtremeProgrammingapproach.
PersonaFictionalcharactersorarchetypesthatexemplifythewaythattypicaluserswillinteractwithaproduct.
Plan-drivenAsoftwaredevelopmentapproachthatfollowsanorderlyseriesofsequentialstages.Requirementsareagreedupon,designiscreated,andthenthecodeisdevelopedandtested.
Product Backlog ItemAproductbacklogitem(PBI,backlogitem,oritem)isaunitofworksmallenoughtobecompletedbyateaminoneiteration.
Product ChampionSeeProductOwner.
Product OwnerTheroleontheteamthatrepresentstheinterestsofallstakeholders,definesthefeaturesoftheproduct,andprioritizestheproductbacklog.
Alsoreferredtoasproductchampion,businessvoice,andcustomervoice.
Product RoadmapAlongterm/longrangeplanninghorizonfeaturestodelivervisionandvalue.
Progressive ElaborationTheactofcontinuallydefiningrequirementswithsuccessivelygreaterlevelsofdetailasneededthroughthelifeoftheproductorthefeaturewithinaproduct.
Rapid Application Development (RAD)Agenerictermreferringtoanynumberoflighter‐weightapproaches,usingfourth‐generationlanguagesandframeworks(suchaswebapplicationframeworks),whichacceleratetheavailabilityofworkingsoftware.
Relative EstimationAwayofestimatingworkeffortbyidentifyingfeatures/requirementswithstoriesandthenassigningstorypointstoeachstory.Thecumulativestorypointsaretheamountofefforttoestimatetheamountofeffortrequiredtodelivereachstory.Thestorypointsarethencalculatedagainsttheteam'svelocitytocreateanestimateonhowmuchtheteamcandeliverinaparticulariteration.
Release PlanningAtthebeginningofaprojecttheteamwillcreateahigh‐levelreleaseplan.Theteamcannotpossiblyknoweverythingupfrontsoadetailedplanisnotnecessary.Thereleaseplanshouldaddress:thenumberanddurationoftheiterations,howmanypeopleorteamsshouldbeonthisproject,thenumberofreleases,thevaluedeliveredineachrelease,theshipdateforthereleases.
114 Agile Extension to the BABOK® Guide
ComplimentaryMemberCopy.NotforRedistributionorResale.
Scrum TeamTheteamthatbuildstheproductthatthecustomerisgoingtoconsume.TheteaminScrumiscross‐functional‐itincludesalltheexpertisenecessarytodeliverthepotentiallyshippableproducteachsprint‐anditisself‐organizing,withaveryhighdegreeofautonomyandaccountability.
Shippable Product ShowcaseAfullytestedunitofcodewhichmeetsacceptancecriteriathatisdeliveredattheendofaniteration.
Service Level AgreementsFormalagreementsthatcontractlevelofserviceandperformance.
Solution Assessment and ValidationThesetoftasksthatareperformedinordertoensurethatsolutionsmeetthebusinessneedandtofacilitatetheirsuccessfulimplementation.Theseactivitiesmaybeperformedtoassessandvalidatebusinessprocesses,organizationalstructures,outsourcingagreements,softwareapplications,andanyothercomponentofthesolution.
SprintAniterationofworkduringwhichanincrementofproductfunctionalityisimplemented.
Sprint GoalAshortdescriptionofwhatthesprintwillattempttoachieve.
Sprint RetrospectiveThemainmechanismfortakingthevisibilitythatScrumprovidesintoareasofpotentialimprovement,andturningitintoresults.
Standup MeetingSeeDailyMeeting.
StorySeeUserStory.
Story MappingAtechniquetofacilitatetheunderstandingofproductfunctionality,theflowofusage,andtoassistwithprioritizingproductdelivery(suchasreleaseplanning).Theoutputofthestorymappingexerciseisaproductcalledastorymap,whichdescribesaworkflowofuserstories.Storymapsmaybreakuserstoriesdownintotasksforeachprocessandmayrepresentthesetasksbasedonpriority.
Task BoardThetaskboardshowsalltheworktheteamisdoingduringaniteration.Itisupdatedcontinuouslythroughouttheiteration‐ifsomeonethinksofanewtasktheywriteanewcardandputsitontheboard.Eitherduringorbeforethedailymeeting,estimatesarechanged(upordown)andcardsaremovedaroundtheboard.
Team VelocityTherateatwhichateamcanconsistentlydeliversoftwarefeaturesperiteration.Typically,itcanbeestimatedbyviewingpreviousiterations,assumingtheteam
Agile Extension to the BABOK® Guide 115
ComplimentaryMemberCopy.NotforRedistributionorResale.
composition.anditerationdurationarekeptconstant.Itcanalsobeestablishedonaiteration‐by‐iterationbasis,usingcommitment‐basedplanning.
Theory of ConstraintsDevelopedbyDr.EliGoldratt,theTheoryofConstraints(TOC)holdsthateverysystemhasatleastoneconstraintlimitingit.TOC'sgoalistoincreaseefficienciesbyidentifyingandmitigatingtheseconstraints.
User Acceptance CriteriaTestcasesthatusersemploytojudgewhetherthedeliveredsystemisacceptable.Eachacceptancetestdescribesasetofsysteminputsandexpectedresults.
User StoryAhigh‐level,informal,shortdescriptionofasolutioncapabilitythatprovidesvaluetoastakeholder.Auserstoryistypicallyoneortwosentenceslongand
providestheminimuminformationnecessarytoallowadevelopertoestimatetheworkrequiredtoimplementit.
User Story MappingSeeStoryMapping.
Value driven developmentAprocessusedtoprioritizerequirementsorbacklogitemsbasedonbusinessvalue.
VelocitySeeTeamVelocity.
Whole Team TestingTheconceptembracedbymanyagileapproacheswheretheentireprojectteamisresponsibleforqualityassuranceandtestingthecode.
Agile Extension to the BABOK® Guide 117
ComplimentaryMemberCopy.NotforRedistributionorResale.
BappendixIndex
Aacceptance & evaluation criteria definition 49acceptance criteria 4, 6, 10, 13, 14, 15, 16, 22, 42, 65, 67, 69,
70, 74, 100acceptance test driven development 92acceptance tests 34, 44adaptive software development 9affinity map 104agile levels of planning 20Agile Manifesto 2, 3, 4, 53, 108agile team 4Agile Unified Process 9analyze to determine what is valuable 47, 49, 54, 77anthropomorphic data 59anti-pattern 68architecture 4ATDD 92avoid waste 47, 106
Bbacklog 11, 13, 21, 26, 30, 33, 34, 44, 58, 64, 67, 74, 85, 88,
96, 97backlog management 26, 28, 33, 38, 75, 78base lining 49BDD 31, 32, 40, 42, 90behaviour driven development 31, 32, 40, 42, 90benchmarking 49brainstorming 49burn-down 38, 39business capabilities 55business capability analysis 36, 37, 45business capability assessment 56business case 35, 37, 42, 44business conditions 21business context 21business need 4, 5, 7, 8, 14, 35, 36, 42, 55business objective 67business rule analysis 49business rules 5, 74business value 4, 10, 13, 18, 21, 38, 39, 54, 55, 56, 64, 70, 77,
78, 80, 81, 86, 101business value. 33
Ccadence 15, 19, 22, 27, 42, 43capability maps 56ceremonies 10, 15, 28
change management 13checklists 50coach 6, 16coaching 7collaboration 18, 66, 102collaborative games 27, 31, 36, 103communication 7, 8, 18, 19, 66, 68, 69component teams 43continuous improvement 38, 102coverage matrix 50cross-functional team 3, 61crystal 9current state value stream Map 60customer 16customer acceptance 41customer review 11customer value. 10
Ddaily meeting 23daily planning 15daily scrum 10, 11daily team meetings 35, 41data dictionary and glossary 50data flow diagrams 50, 69data model 5, 69, 74data modeling 50data tables 69decision analysis 50decomposition 65delivery framework 47, 89delivery team 54demographic data 59developer 16dialog hierarchy, 75dialog map 75differentiating quadrant 87discovery framework 47, 54document analysis 50DSDM 9dynamic systems development method 9dysfunctional form 83
Eelaboration 16, 27, 40, 54elicitation 38, 39, 69, 74eliciting 13
118 Agile Extension to the BABOK® Guide
ComplimentaryMemberCopy.NotforRedistributionorResale.
enterprise analysis 13, 21epics 17, 33, 34, 37, 39, 40, 43, 64, 65, 67, 68, 74, 79estimate 14, 79estimation 7, 50, 95excitement characteristics 83extreme programming 9
Ffacilitating 19facilitation 7, 8, 66, 68, 69, 102feasibility analysis 50feasibility studies 35feature driven development 9feature groups 66feature injection 101feature sets 39, 71feature teams 43features 37, 39, 40, 43, 44, 60, 64, 97, 101feedback 8fishbowl 104force field analysis 50functional decomposition 50functional form 83functional requirements 78future state value stream map 60
Gget real using examples 47, 49, 89grooming 22, 75
Hhealthy teams 53high-level requirements 30
IIDDs 94ideal developer days 94interface analysis 50interviews 50INVEST criteria 73iteration planning 14, 41iteration planning meetings 35iteration planning workshop 96, 100iteration review 22
Jjust-in-time 33, 39, 68just-in-time requirements 5, 7, 13
Kkanban 9, 22, 97, 99kano analysis 37, 38, 81
Llast responsible moment 100Lean 17, 107lessons learned process 50lightweight 39lightweight documentation 32, 40, 108long-lived 58low-fidelity 5, 22, 23
Mmaterial and information flow mapping 60metrics and key performance indicators 50minimal marketable feature 64, 67, 85minimal viable product 65, 67minimally marketable feature 17, 34, 65MMF 17, 34, 65, 66, 67, 79, 96, 97mock-up 31, 34, 69, 74modelling requirements 41models 31, 35, 101MoSCoW 38, 50, 84muda 107MVP 65, 67
Nnavigation flow 75negotiation 7, 8, 19non-functional requirements analysis 50
Oobservation 50operational readiness 21options expiry 100organization modeling 51organizational change 43organizational change management 68organizational readiness 43
Ppair programming 14parity quadrant 87partner quadrant 88performance characteristics 82personas 5, 27, 28, 30, 40, 59planning game 14planning poker 95planning workshop 26, 27, 28, 35, 38, 96principles 3problem or vision statement 51problem tracking 51process improvement 62process modeling 51product backlog 85product box 104product champion 97product demonstration 22product owner 6, 12, 14, 41, 44, 78, 80, 97progressive elaboration 30, 39project team 7, 9prototypes 31, 41, 64, 74prototyping 27, 51, 64, 75, 76pruning 75purpose alignment model 36, 37, 86
QQCD 9quality attribute stories 78queues 17
RRACI matrix 51real options 26, 37, 42, 98
Agile Extension to the BABOK® Guide 119
ComplimentaryMemberCopy.NotforRedistributionorResale.
real-time collaboration 9relative estimation 93relative points 94release backlogs 80release plan 97release planning 34, 35, 41, 55, 68, 70release planning workshop 96requirements documentation 51requirements for vendor selection 51requirements prioritization 13requirements workshops 51retrospectives 10, 11, 26, 29, 32, 41, 42, 44, 105risk 5, 9, 14, 19, 21, 27, 38, 39, 55, 56, 70, 78risk analysis 51risk management 40roadmap 8, 20, 21, 44, 56root cause analysis 51
Sscenarios 34, 40, 69, 76, 92scenarios and use cases 51scope modeling 51scrum 9, 15, 17, 18, 20, 22, 99scrum life-cycle 11scrum master 12see the whole 47, 49, 54sequence diagrams 51Service Level Agreements 18signoff 51SLA 18solution assessment and validation 13specification by example 92sprint planning 10sprint reviews 10sprints 21stakeholder Map 51stand up 10, 11stand-up 15state diagrams 51, 74stimulate collaboration and continuous improvement 47,
49, 102stories 33, 34, 40, 43, 60, 65, 66, 68, 94story decomposition 15, 16, 17, 33, 34, 37, 39, 43, 65,
79, 96story elaboration 15, 17, 68, 100story mapping 5, 17, 30, 33, 37, 39, 41, 70story maps 39story techniques 75storyboarding 40, 75strategic criteria 8structured walkthrough 51success criteria 21
survey/questionnaire 51SWOT analysis 51system goals 67systems thinking 54
Ttask definitions 69team capacity 93team velocity 97technical design 3technical writing 4test driven development 14, 90testing 3themes 34, 37, 40, 67Theory of Constraints 17think as a customer 47, 49, 54, 64threshold characteristics 82timeboxing/budgeting 51tracker 16transformation processes 62transition requirements 43
UUI design 3understand what is doable 47, 49, 93use cases 5, 34, 64, 66, 75, 78user acceptance tests 67, 72, 74user stories 11, 14, 15, 16, 20, 33, 34, 39, 52, 64, 65, 67,
70, 75, 78, 85, 97user story 30, 34, 40, 41, 44, 67, 72, 99
Vvalue 9, 43, 44, 53, 54, 56, 61, 64, 72, 80, 85, 97, 107,
108value stream mapping 29, 45, 60variance analysis 52velocity 93, 95vendor assessment 52voting 52
Wwho cares? quadrant 88whole team testing 14WIP 17, 97work in progress limit 17work items 64work queues 17work-in-progress 97
XXP 9, 17, 20
Agile Extension to the BABOK® Guide 121
ComplimentaryMemberCopy.NotforRedistributionorResale.
CappendixBibliography
ThefollowingworkswerereferencedbycontributorstotheAgileExtensiontotheBABOK®Guide.Incaseswheremultipleeditionsofaworkwereconsulted,onlythemostrecenteditionislisted.
Inadditiontotheworkslistedhere,manyothersourcesofinformationonbusinessanalysiswereconsultedbycontributorsandreviewersorotherwiseorinfluencedthedevelopmentofTheAgileExtensiontotheBABOK®Guide,includingarticles,whitepapers,websites,blogpostings,onlineforums,seminars,workshops,andconferences.
Withonlyaveryfewexceptions,theideasandconceptsfoundintheAgileExtensiontotheBABOK®Guidewerenotcreatedoriginallyforororiginaltoit.TheAgileExtensiontotheBABOK®Guideisasynthesisofyearsofresearchintohowagiledevelopmentmethodologiesareutilizedandmethodsthatcanbeusedtoidentifypotentialimprovements.Theworkslistedbelow,themselvesbuildonthethoughtsandresearchofmanyothers.
Adlin,TamaraandJohnPruitt.2010.TheEssentialPersonaLifecycle:YourGuidetoBuildingandUsingPersonas.MorganKaufmann.
Adzic,Gojko.2009.BridgingtheCommunicationGap:SpecificationbyExampleandAgileAcceptanceTesting.NeuriLimited.
Adzic,Gojko.2011.SpecificationbyExample:HowSuccessfulTeamsDelivertheRightSoftware.ManningPublications.
Ambler,Scott.IntroductiontoUserStories.AgileModelling.http://www.agilemodeling.com/artifacts/userStory.htm.
Anderson,David.2010.Kanban:SuccessfulEvolutionaryChangeforYourTechnologyBusiness.BlueHolePress.
Arthur,Jay.2006.LeanSixSigmaDemystified:ASelf‐TeachingGuide.McGraw‐HillProfessional.
Berenbach,Brian,DanielJ.Paulish,JuergenKazmeier,andArnoldRudorfer.2009.Software&SystemsRequirementsEngineering:InPractice.McGraw‐HillOsborneMedia.
122 Agile Extension to the BABOK® Guide
ComplimentaryMemberCopy.NotforRedistributionorResale.
Chelimsky,David,DaveAstels,BryanHelmkamp,andDanNorth.2010.TheRSpecBook:BehaviourDrivenDevelopmentwithRspec,Cucumber,andFriends.PragmaticBookshelf.
Cohn,Mike.2004.UserStoriesApplied:ForAgileSoftwareDevelopment.Addison‐WesleyProfessional.
Cohen,Mike.2006.AgileEstimatingandPlanning.PrenticeHall.
Cooper,Alan.2004.TheInmatesareRunningtheAsylum.Sams‐PearsonEducation.
Cottmeyer,MikeandV.LeeHenson.2009.TheAgileBusinessAnalyst.VersionOne,WhitePaper.http://www.agiledad.com/Documents/BAWhitepaperJune.pdf.
Courage,CatherineandKathyBaxter.2005.UnderstandingYourUsers:APracticalGuidetoUserRequirementsMethods,Tools,andTechniques.ElsevierScienceandTechnologyBooks,Inc.
Derby,EstherandDianaLarsen.2006.AgileRetrospectives:MakingGoodTeamsGreat.PragmaticBookshelf.
DSDMConsortium.2003.DSDM:BusinessFocusedDevelopment,SecondEdition.PearsonEducation.
Evers,Marc.September23,2009.WorkingwithUserStoryMapping.Dreamfeed:Marc’sWeblog.http://blog.piecemealgrowth.net/working‐with‐user‐story‐mapping/.
ExtremeProgramming.September28,2009.ExtremeProgramming:AGentleIntroduction.http://www.extremeprogramming.org/index.html.
Goldratt,Eliyahu.2004.TheGoal:AProcessofOngoingImprovement.NorthRiverPress.
Gottesdiener,EllenandMaryGorman.August2010.SlicingRequirementsforAgileSuccess.EbgConsulting.http://ebgconsulting.com/Pubs/Articles/SlicingRequirementsForAgileSuccess_Gottesdiener‐Gorman_August2010.pdf.
Gottesdiener,Ellen.February4,2009.TheAgileBusinessAnalyst:EyesforWaste.Modernanlyst.com.http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/811/The‐Agile‐Business‐Analyst‐Eyes‐for‐Waste.aspx.
Gottesdiener,Ellen.2005.SoftwareRequirementsMemoryJogger.GoalQPCInc.
Gray,Dave,SunniBrown,andJamesMacunafo.2010.Gamestorming:APlaybookforInnovators,Rulebreakers,andChangemakers.O'ReillyMedia.
Highsmith,Jim.2009.AgileProjectManagement:CreatingInnovativeProducts(2ndEdition).Addison‐WesleyProfessional.
Hohmann,Luke.2006.InnovationGames:CreatingBreakthroughProductsThroughCollaborativePlay.Addison‐WesleyProfessional.
Agile Extension to the BABOK® Guide 123
ComplimentaryMemberCopy.NotforRedistributionorResale.
IIBA(2009).AGuidetotheBusinessAnalysisBodyofKnowledge®(BABOK®
Guide),Version2.InternationalInstituteofBusinessAnalysis.
Jonasson,Hans.2008.DeterminingProjectRequirements.CRCPress.
Karol,RobinandBeebeNelson.2007.NewProductDevelopmentforDummies.JohnWiley&Sons.
Kent,Stuart.June30,2004.Storyboarding.MSDNBlogsStuartKent’sBlog.http://blogs.msdn.com/b/stuart_kent/archive/2004/06/30/169599.aspx.
Kerth,Norman.2001.ProjectRetrospectives:AHandbookforTeamReviews.DorsetHouse.
Kim,W.ChanandReneeMauborgne.2005.BlueOceanStrategy.HarvardBusinessPress.
King,James.December28,2010.Estimationtoolkit:Someusefultechniques.InfoQ.com.http://www.infoq.com/articles/estimation‐toolkit.
LeanEnterpriseInstitute.PrinciplesofLean.http://www.lean.org/whatslean/principles.cfm.
Leffingwell,Dean.2011.AgileSoftwareRequirements:LeanRequirementsPracticesforTeams,Programs,andtheEnterprise.Addison‐WesleyProfessional.
LencionimPatrick.2006.Silos,PoliticsandTurfWars:ALeadershipFableAboutDestroyingtheBarriersThatTurnColleaguesIntoCompetitors.Jossey‐Bass.
Maassen,OlavandChrisMatts.June2008.RealOptionsunderlieAgilePractices.InfoQ.com.http://www.infoq.com/articles/real‐options‐enhance‐agility.
Matts,Chris.October29,2003.ZeroDocumentation.TheAgileBusinessCoach.http://abc.truemesh.com/archives/000103.html.
Matts,Chris.2009.RealOptionsatAgile2009.R.O.S.E.Comics.http://www.lulu.com/product/paperback/real‐options‐at‐agile‐2009/5949485.
ManifestoforAgileSoftwareDevelopment.http://agilemanifesto.org.
Merrifield,Ric,JackCalhoun,DennisStevens.2008.TheNextRevolutioninProductivity.HarvardBusinessReview.
Middleton,PeterandJamesSutton.2005.LeanSoftwareStrategies:ProvenTechniquesforManagersandDevelopers.ProductivityPress.
North,Dan.March2006.IntroducingBDD.DanNorth.net.http://dannorth.net/introducing‐bdd/.
Patton,Jeff.BuildingBetterProductsbyUsingUserStoryMapping.http://www.slideshare.net/nashjain/user‐story‐mapping.
124 Agile Extension to the BABOK® Guide
ComplimentaryMemberCopy.NotforRedistributionorResale.
Patton,Jeff.October8,2008.Thenewuserstorybacklogisamap.AgileProductDesign.com.http://agileproductdesign.com/blog/the_new_backlog.html.
Patten,Jeff.February26,2010.UserCentredDesignandStoryMapping.InfoQ.com.http://www.infoq.com/interviews/patton‐story‐map.
Pixton,Pollyanna,NielNickolaisen,ToddLittle,andKentMcDonald.2009.StandBackandDeliver:AcceleratingBusinessAgility.Addison‐WesleyProfessional.
Pols,AndyandChrisMatts.2004FiveBusinessValueCommandments.AgileProjectManagementAdvisoryServiceExecutiveUpdate.Vol.5,No.18.CutterConsortium.http://cdn.pols.co.uk/papers/cutterbusinessvaluearticle.pdf.
Pyzdek,Thomas.2003.TheSixSigmaHandbook,RevisedandExpanded.McGraw‐Hill.
Rosenberg,DougandMattStephens.2007.UseCaseDrivenObjectModelingwithUML:TheoryandPractice.Apress.
Rother,MikeandJohnShook.1999.LearningtoSee:Value‐StreamMappingtoCreateValueandEliminateMUDA.TheLeanEnterpriseInstitute,Inc.
Sayer,NatalieJ.andBruceWilliams.2007.LeanForDummies.JohnWiley&Sons.
Schwaber,Ken.2007.AgileProjectManagementwithScrum.MicrosoftPress.
Schwaber,Ken;Sutherland,Jeff.2010.ScrumGuide.Scrum.org.http://www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf.
Shore,James.2007.TheArtofAgileDevelopment.O'ReillyMedia.
Sims,Chris.March23,2009.StoryMappingGivesContexttoUserStories.InfoQ.com.http://www.infoq.com/news/2009/03/story‐map.
Womack,andJamesP.,andDanielT.Jones.2003.LeanThinking:BanishWasteandCreateWealthinYourCorporation,RevisedandUpdate.FreePress.
Wells,Don.2009.IterationPlanning.XPProgramming.com.http://www.extremeprogramming.org/rules/iterationplanning.html.
Wynne,Matt,andAslakHellesøy.2011.TheCucumberBook:BehaviourDrivenDevelopmentforTestersandDevelopers.ThePragmaticBookshelf.
Agile Extension to the BABOK® Guide 125
Dappendix Contributors
IIBA®andTheAgileAlliance®wouldliketothankthefollowingcontributorstotheAgileExtensiontotheBABOK®Guide.WithouttheireffortsandcommitmenttheAgileExtensiontotheBABOK®Guidewouldnotbepossible.
Reviewers
IIBA®andTheAgileAlliance®wouldliketorecognizeandthankthemanypeoplewhoprovidedfeedbackthroughthepublicreviewofAgileExtensiontotheBABOK®Guide.YourfeedbackandguidancehelpedshapethisVersion1ofAgileExtensiontotheBABOK®Guide.
• KevinBrennan• SusanBlock• DavidC.Cook• PeterGordon• SteveErlank• EllenGottesdiener• ShaneHastie
• BrianHemker• MarshaHughes• ChrisMatts• AliMazer• DavidMorris• LuizClaudio
Parzianello• CarolScalice
• PaulStapleton,Editor
• DennisStevens• PascalVan
Cauwenberghe
ww.iiba.org
International Institute of Business
Analysis (IIBA)
InternationalInstituteofBusinessAnalysis(IIBA)isanindependentnon‐profitprofessionalassociationdedicatedtopromotingthebusinessanalysisprofessionworldwide.Astheglobalthoughtleaderforbusinessanalysis,IIBA®isdedicatedtothedevelopmentandmaintenanceofstandardsforthepracticeofbusinessanalysisandforthecertificationofpractitioners.OneofthemaingoalsoftheassociationistohelpBAsdeveloptheirskillsandadvancetheircareers.
IIBAhascreatedAGuidetotheBusinessAnalysisBodyofKnowledge®(BABOK®)Guide,thecollectionofknowledgewithintheBAprofession,reflectingthecurrentgenerallyacceptedpractices.
Membership in IIBAMembershipbenefitsinclude:
• TheBABOK®Guide,theinternationallyrecognizedstandardfortheBAprofession
• OnlineLibrarywithaccessto300businessbooks,areferencelibraryatyourfingertips
• BACompetencyModelandtheBACompetencyAssessmenttoevaluateyourBAskills
• Webinarsdeliveredbyindustryleaders,providingcurrent,relevantandactionableinformation
• DiscountedexamfeesfortheCertificationofCompetencyinBusinessAnalysis™
(CCBA®)andCertifiedBusinessAnalysisProfessional™(CBAP®)designations
• EligibilitytojoinalocalChapter• JobsearchcapabilitiesusingtheCareer
Centre
IIBA Certification
Certification of Competency in Business Analysis™ (CCBA®)
TheCCBA®designationisaprofessionalcertificationforBApractitionerswhowanttoberecognizedfortheirexpertiseandskillsbyearningformalrecognition.
Certified Business Analysis Professional™ (CBAP®)
TheCBAP®designationisaprofessionalcertificationforindividualswithextensivebusinessanalysisexperience,theelite,seniormembersoftheBAcommunity.
FormoreinformationvisitIIBA.org/Certification.
IIBA ChaptersOver100IIBAChaptersworldwideprovidenetworkingandprofessionaldevelopmentopportunitiestobusinessanalystsatthelocallevelthroughactivities,meetings,andeducationalprograms.VisitIIBA.org/Chapters.
ForcompleteinformationvisitIIBA.org.
ww.iiba.org
The Agile Alliance
TheAgileAllianceisanon‐profitorganizationwithglobalmembership,committedtoadvancingAgiledevelopmentprinciplesandpractices.AgileAlliancesupportsthosewhoexploreandapplyAgileprinciplesandpracticesinordertomakethesoftwareindustrymoreproductive,humaneandsustainable.Weshareourpassiontodeliversoftwarebettereveryday.
Agilemethodshaveproventheireffectivenessandaretransformingthesoftwareindustry.Asagilemethodsevolveandextend,AgileAlliancefostersacommunitywhereorganizationsandindividualsfindwaystotransitiontoandadvanceAgilepractices,regardlessofmethodology.
TheAgileAlliancewebsiteoffersaninformationhubwherememberscanaccessawidevarietyofresources—anarticlelibrary,videos,presentations,localusergrouplistingsandlinkstoadditionalagileresources.
AgileAllianceorganizesthelargest,mostdiverseandcomprehensiveagileconferenceseachyear.Conferenceparticipantslearnfromhundredsofsessionsspanningtheentireagileorganizationandlife‐cycle,makebusinessconnections,andconversewithagilethoughtleaders,practitioners,andauthors.
Inadditiontothesemajorconferences,AgileAllianceprovidesfinancialandorganizationalsupporttoscoresoflocal,regionalandspecialinterestconferencesandusergroupsworldwide.
TheAgileAllianceoperatesontheprinciplesoftheAgileManifesto.http://www.agilemanifesto.org
TheAgileAlliancewebsiteis:www.agilealliance.org.