the agile extension
DESCRIPTION
This book is about agile methodologiesTRANSCRIPT
IIBA®
TheAgileExtensionInternationalInstitu
November2011
International Institute of Business AnalysisTM
The Agile Extension to the BABOK®Guide
totheBABOK®GuideisacollaborativeeffortbytheteofBusinessAnalysisandtheAgileAlliance.
DraftforPublicReview
Agile Extension to the BABOK® Guide
November 2011 Draft for Public Review
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.
NochallengetothestatusorownershipoftheseoranyothertrademarkedtermscontainedhereinisintendedbytheInternationalInstituteBusinessAnalysis.
ThisdraftoftheAgileExtensiontotheBABOK®Guideisprovidedtothecommunityforreviewandfeedbackandmaynotbeusedforanyotherpurpose.Inordertoprovidefeedback,pleaseenteryourcommentsonourfeedbackwebform.
Table of Contents
Chapter 1: Introduction to the Agile Extension 1
What is the Agile Extension to the BABOK® Guide? ................................. 1 What does Agile Mean for Business Analysis? ........................................... 2 What does Agile Mean for Business Analysts?........................................... 4 What makes a Business Analyst Successful on an Agile Team?............... 6
Chapter 2: Business Analysis in Agile Life-cycles 7
Scrum .............................................................................................................. 7Backlogs ........................................................................................................................... 8Sprint Planning and Execution ...................................................................................... 8Roles and Responsibilities .............................................................................................. 9Business Analysis in Scrum ............................................................................................ 9Techniques .................................................................................................................... 11
Extreme Programming (XP) ........................................................................ 11User Stories................................................................................................................... 11Release Planning and Execution ................................................................................ 12Roles and Responsibilities ........................................................................................... 13Business Analysis in XP................................................................................................ 13Techniques .................................................................................................................... 14
Kanban.......................................................................................................... 14Queues .......................................................................................................................... 15The Kanban Board ....................................................................................................... 15Roles & Responsibilities ............................................................................................... 16Business Analysis in Kanban....................................................................................... 16
Comparison of Agile Life-cycles ................................................................. 18Selecting an Agile Methodology or Framework......................................................... 19
Agile Levels of Planning .............................................................................. 20Agile Levels of Planning ............................................................................................... 20
Chapter 3: Knowledge Areas 25
Mapping Techniques to Knowledge Areas ............................................... 25
November2011DraftforPublicReview i
Business Analysis Planning and Monitoring ............................................................. 25Elicitation ...................................................................................................................... 28Requirements Management and Communication................................................... 30Enterprise Analysis....................................................................................................... 32Requirements Analysis ................................................................................................ 34Solution Assessment and Validation ......................................................................... 36Business Analysis Techniques Mapped to Agile Business Analysis Guidelines ...... 39
Chapter 4: Techniques 43
A Context for Agile Business Analysis ....................................................... 43 Guidelines for Agile Business Analysis ..................................................... 44 A Note on Agile Extension Techniques ..................................................... 44 See The Whole ............................................................................................. 45
Business Capability Analysis....................................................................................... 46Personas ....................................................................................................................... 49Value Stream Mapping................................................................................................ 51
Think as a Customer ................................................................................... 55Story Decomposition ................................................................................................... 56Story Elaboration ......................................................................................................... 59Story Mapping.............................................................................................................. 61User Story ..................................................................................................................... 64Storyboarding............................................................................................................... 67
Analyze to Determine What is Valuable.................................................... 70Backlog Management.................................................................................................. 70Business Value Definition............................................................................................ 73Kano Analysis ............................................................................................................... 74MoSCoW Prioritization ................................................................................................ 77Purpose Alignment Model........................................................................................... 79
Get Real Using Examples ............................................................................ 81Behaviour Driven Development ................................................................................. 82
Understand What is Doable ....................................................................... 84Estimation..................................................................................................................... 85Planning Workshop ..................................................................................................... 87Real Options ................................................................................................................. 89
Stimulate Collaboration & Continuous Improvement............................ 93Collaborative Games ................................................................................................... 94Retrospectives............................................................................................................... 96
Avoid Waste.................................................................................................. 98Lightweight Documentation........................................................................................ 99
ii The Agile Extension to the BABOK® Guide
appendix A Glossary 103
appendix B Bibliography 111
appendix C Contributors 115
November2011DraftforPublicReview iii
iv The Agile Extension to the BABOK® Guide
chapter 1
Introduction to the Agile Extension
®
1.1 What is the Agile Extension to the BABOK Guide?TheAgileExtensiontotheBABOK®Guidedescribesbusinessanalysisareasofknowledge,theirassociatedactivitiesandtasks,andtheskillsnecessarytobeeffectiveintheirexecutionwithintheframeworkofagilesoftwaredevelopment.
ThepurposeoftheAgileExtensionistoactasabusinessanalysisprimerforagilesoftwaredevelopmentmethodologiesandprovidebusinessanalysispractitionerswith:
• anintroductiontoagilepracticesforbusinessanalysis,• anoverviewofbusinessanalysistechniquesforagile
practitioners,• asetofdefinitionsoftypicalworkingpracticesusedbybusiness
analystsworkingonagileprojects,and• anoverviewofthenewandchangedroles,skills,and
competenciesforbusinessanalysis.
TheAgileExtensionisofvaluetobusinessanalystsnewtoagile,aswellasthoseexperiencedinagilemethodologies.Bothgroups,andallthoseinbetween,willfindhelpfulinformationsuchasanintroductiontothepracticeofbusinessanalysisinanagilecontext,themappingofexistingbusinessanalysistechniquestoagilepractices,andinclusionoftechniquesthatarespecifictothepracticeofbusinessanalysisintheagileworld.
AstheAgileExtensionhighlights,anymemberofanagileteammayengageintheprocessofbusinessanalysis.Tothatend,eachpersononanagileteamwillbenefitfromhavingasetofpracticesandtoolsinwhichtheycanselectfromwhileworkinginanyoneofthedifferentflavorsofagile.
IntheAgileExtension,wehavecalledparticularattentiontothemind‐setabusinessanalysispractitionermusthaveinordertoeffectivelycontributetodeliveryofongoingvaluetostakeholders.Wehavealso
November2011DraftforPublicReview 1
What does Agile Mean for Business Analysis? Introduction to the Agile Extension
describedanumberoftechniquesnotfoundintheexistingBABOK®
Guide,andexpandedonothersthatneededtobedescribedingreaterdetail.Manyoftheapproachesdescribedhere,andthemind‐setwedescribe,willprovevaluabletobusinessanalysisinanymethodologyandenvironment.Businessanalystsshouldalwaysworktoensurethatrequirementsarealignedwithorganizationalgoalsandobjectivesandthatallstakeholdershaveasharedunderstandingofthosegoals,objectives,andrequirements.Theymustalsoworktomanagerisksandvalidatethattherequirements,ifdelivered,willcreaterealvalueforstakeholders.Agilemethodologiescanhelpusfindnewwaystodothesethingsthatsupportcontinuousdeliveryofworkingsoftware,buttheresponsibilitytodothesethingsisinherenttotheprofessionofbusinessanalysis.
1.2 What does Agile Mean for Business Analysis?
Muchlikeothermethodologies,businessanalysisiscentraltothesuccessofagileprojects.Businessanalysisisnecessarytoenableadiversegroupofcustomerstospeakwithasinglevoice.Thisworkmaybedonebyoneofmoremembersofanagileteam.
Intheagileworld,softwarerequirementsaredevelopedthroughcontinualexplorationofthebusinessneed.Requirementsaregatheredandrefinedthroughaniterativeprocessofplanning,definingacceptancecriteria,prioritizing,developing,andreviewingtheresults.Throughouttheiterativeplanningandanalysisofrequirements,businessanalysispractitionersmustconstantlyensurethatthefeaturesrequestedbytheusersalignwiththeproduct’sbusinessgoals,especiallyasthebusinessgoalsevolveandchangeovertime.
Agilebusinessanalysisisprimarilyaboutincreasingthedeliveringofbusinessvaluetothesponsorsandcustomersoftheproject/productbeingdeveloped.AgilebusinessanalysisalignswiththevaluesandprinciplesoftheAgileManifesto(www.agilemanifesto.org):
• Wevalueindividualsandinteractionsoverprocessesandtools.• Ourhighestpriorityistosatisfyourcustomerthroughearly
andcontinuousdeliveryofvaluablesoftware.• Workingsoftwareistheprimarymeasureofprogress.
Agilebusinessanalysisisaboutensuringtherightinformationisavailabletothedevelopmentteamintherightlevelofdetailattherighttimesotheycanbuildtherightproduct.
2 The Agile Extension to the BABOK® Guide
Introduction to the Agile Extension What does Agile Mean for Business Analysis?
Thetechniquesofbusinessanalysisdonotchangedramaticallyintheagileenvironment.However,thetimingandhowtheyareuseddochange.Artifactssuchaspersonas,datamodels,storymaps,andbusinessrulescontinuetobeemployed,butarekeptaslight‐weightaspossible.Low‐fidelityartifacts,suchasdiagrams,maps,andlists,providemorevaluetoanagileprojectthanlong,textualrequirementdescriptionsorspecifications.Low‐fidelityartifactsaredevelopedforthesolepurposeofbuildingthesoftwareforaspecificiterationandonlyneedtobeintelligibletotheteamduringthecourseoftheiteration.Long‐livedartifacts,ontheotherhand,areintendedtobeutilizedbeyondthescopeofdevelopment.Long‐livedartifactsmayincludethebusinesscase,charter,anddocumentationthatisusedtocommunicatewhatthesoftwaredoesandwhyitdoesit.
Agileofferstheopportunityforbusinessanalysistobenefitfromthefrequentfeedbackprovidedbythebusiness.Byreviewingtheresultsofsuccessiveiterationswiththebusinessstakeholders,analystshavetheopportunityto
• refinetheproduct’srequirementstoensuretheymaintaincohesionwiththebusinessneedsfortheproduct,and
• identifyandmitigateriskearlyintheproject.
Forthemostpart,inagileprojects,highriskitemsareaddressedinearlyiterations.Thisallowstheteamtomitigateissuesandthepossiblereworkrequiredifriskitemsarenotaddresseduntillaterintheproject.Facilitatingriskdiscoveryandassistingtheteaminretainingfocusedoneffectiveriskmitigationiscentraltotheanalyst’sroleonanagileteam.
Iterativedevelopmentprocessesprovideopportunitiesforincreasedefficienciesintheworkofbusinessanalysis.Inwaterfallprojects,requirementsaredevelopedintheirentiretypriortothedevelopmentphase.Asriskelementsareuncoveredandbusinessneedsevolve,certainrequirementsmaychangeorbeeliminatedoutright;makingtheworkeffortputintothoserequirementswasted.Byprovidingjust‐in‐timerequirements,thereislessreworkofrequirementsbecauseonlytherequirementsrequiredforthecurrentreleasearedefinedindetailanddeveloped.
November2011DraftforPublicReview 3
What does Agile Mean for Business Analysts? Introduction to the Agile Extension
1.3 What does Agile Mean for Business Analysts?
Theearlystagesofagile’sevolutionfrequentlyreliedonasingleindividualbeingabletomakeallthedecisionsregardingthedevelopmentofthesoftware.Asagileprojectsgrowinsizeandbreadth,andbecomeadoptedbylargerandmorediverseorganizations,theroleofbusinessanalysthasbecomeavitalcontributor.Theanalystplaysadefiningroleincreatingasinglevisionfortheproductoutofadiversesetofneedsandwishesfrommultiplestakeholders.
TheAgileManifestousestheterm“developers”todescribetheteamwhoworkonbuildingtheproduct.Thisisacross‐functionalteamofskilledindividualswhobringavarietyofexpertisetobearontheprocessofbuildingasoftwareproduct.Theskillsthatdevelopersrequiretodothisincludebusinessanalysis,technicaldesign,programminginvariouslanguagesandtools,testing,UIdesign,technicalwriting,architectureandwhateverelseisneededtoproduceworkingsoftware.Workingsoftwareisaproductwhichisintheproductionenvironmentdeliveringvalueforourcustomers.
ThereareavarietyofwaysabusinessanalystcanbeengagedonanAgileproject:
• Insomeprojectsadedicatedbusinessanalystroleisunnecessary.Thisisnottosaythatbusinessanalysisisnotconductedduringthecourseoftheproject,onlythatitmaybedonebyanymember,ormembers,oftheoveralldevelopmentteam.
• Inmorecomplexenvironmentstheanalystmightbethefacilitator,bringingdivergentbusinessstakeholderstogetherandhelpingthemspeakwithasinglevoicesotheprojectteamarenotconfusedbycontradictoryandconflictingperspectives.
• Theanalystmightactastheproductowner/customerrepresentativewheretheyareempoweredbythebusinesstomakedecisionsonproductfeaturesandpriority.
• Theanalystcouldactasasurrogateproductowner,insituationswherethebusinessproductownernotavailable.
• Theanalystmightactasthesecondincommandtoabusinessproductownerwithlimitedavailability.
• Ananalystcouldtaketheroleofbusinesscoachinanenvironmentwherethebusinessproductowneriscompetentandcommitted,buthaslimitedITprojectexperienceandtherestofthedevelopmentteamarelackingindomainknowledge.
4 The Agile Extension to the BABOK® Guide
Introduction to the Agile Extension What does Agile Mean for Business Analysts?
Irrespectiveofjobtitles,businessanalysisisaboutensuringtheprojectisabletodeliverthemaximumvalueforcustomersandadaptingtotheevolvingbusinessneeds.
Thetechniquesutilizedinagilemethodologiesdonotrepresentamajorshiftforbusinessanalysts.TheycontinuetoutilizemanyofthetoolsandtechniquesdefinedinAGuidetotheBusinessAnalysisBodyofKnowledge®(BABOK®Guide).Whathaschangedisthetimingandtheusageofthesetechniques.Therigorsanddemandsofagileprojectsalsorequirebusinessanalyststoutilizeanddevelopskillsthattheymaynothavepreviouslyexercisedatahighlevel.Inanagileenvironment,thesuccessofthebusinessanalystreliesincreasinglyonsuchinterpersonalskillsascommunication,facilitation,coachingandnegotiation.Theseskillsarecertainlycentraltothesuccessofananalystinanyenvironment;however,duetotheinter‐connectednessofagileteams,iftheseskillsarenotbeingeffectivelyutilized,thenumberofrequeststhatcanbeadequatelyunderstandandprioritizeddecreases,resultinginfeweritemsmakingitintothesolutionimplementationforagivenrelease.
Analystsarerequiredtoapproachrequirementsfroma360degreeperspective.Theyarerequiredtoworkwiththebusinesssponsoronastrategiclevel,anddefinehowtheproposedproductorfeaturealignswiththeorganizationsportfolioandstrategy.Theymustthenworkwiththebusinessandprojectteamtobreakthisvisiondownintorequirementsthatsupporteffectiveandaccurateestimation.Inanagileprojectthisisdoneforeachiterativerelease,asopposedtothesinglerequirementsphasethatexistsinplan‐drivenmethodologies.Theanalystdeliversjust‐in‐time,detailedrequirementstothedevelopmentteamsotheycanbuildonlywhatisrequiredforaspecificiteration.
Businessanalystsplayakeyroleinfacilitatingasharedunderstandingofthebusinessneedfortheprojectwithallstakeholders.Itistheroleofthebusinessanalysttoensurethereisashared,agreeduponvisionfortheproductacrosstheentiredeliveryteam.Intheagileenvironment,understandingandsynthesizingperspectivesalongsidetheabilitytoholdsuccessfulconversationsreplacetheneedforformal,detailed,longtermartifactssuchasrequirementdocuments.
Oneofthekeyelementsforabusinessanalystworkinginanagileenvironmentistheabilitytousefeedbacktodrivechange.Itisincumbentontheanalysttoconstantlyreviewrequirementswiththe
November2011DraftforPublicReview 5
What makes a Business Analyst Successful on an Agile Team? Introduction to the Agile Extension
businessstakeholdersandensurethatanyshiftsinbusinessneedsareaccuratelyreflectedinfutureiterationsoftheproduct.
1.4 What makes a Business Analyst Successful on an Agile Team?
Theverynatureofagilemethodologiesrequiresallteammemberstobeoperatingataveryhighlevelofcompetency,skill,andeffectiveness.Thisisespeciallytrueforbusinessanalysts.Tobeproductiveonanagileteam,businessanalystshavetobeontopoftheirgame.Onsuccessfulagileteams,thebusinessanalystisanintegralcomponentofthedeliveryteam.Theyareactiveparticipants,ifnottheactualfacilitatorsofplanning,analyzing,testing,anddemonstratingactivities.
Thebusinessanalystplaysacentralroleinensuringthattheproductroadmapclearlydefinestheproduct’sstrategicalignmenttothebusinessneed.Theanalystholdssharedresponsibilityindefiningthestrategiccriteriaforcompletionoftheproject.Thisrequirestheanalysttoexerciseanextremelyhighlevelofskillincommunication,facilitation,andnegotiation.Theyrequiretheabilitytolistentoandunderstandfeedbackfromallstakeholdersandusethisfeedbacktodrivethechangesrequiredtotherequirementsandprioritiesoftheproject.
6 The Agile Extension to the BABOK® Guide
chapter 2
Business Analysis in Agile Life-cycles
Agileisatermusedtodescribeanumberofiterativedevelopmentmethodologiesthathavedevelopedovertime.Commontraitsamongstagilemethodologiesincludefrequentproductreleases,highlevelsofreal‐timecollaborationwithintheprojectteamandwithcustomers,reducedtimeintensivedocumentation,andregular,recurringassessmentsofvalueandrisktoallowforchange.Itisimportanttonotethatthoughallagilemethodologiesareiterative,notalliterativemethodologiesareagile.Agilemethodologiesareasubsetofiterativesoftwaredevelopment.AfewexamplesofagilemethodologiesincludeScrum,ExtremeProgramming(XP),Kanban,Crystal,DynamicSystemsDevelopmentMethod(DSDM),FeatureDrivenDevelopment,andAdaptiveSoftwareDevelopment,tonameafew.Eachmethodologyhasitsownuniquesetofcharacteristicsthatallowteamstoselectacertainmethodologythatbestsuitstheprojectathand.Itiscommonforprojectteamstoblendcharacteristicsfrommorethanoneagilemethodologybasedonuniqueteamcomposition,skills,experience,operatingenvironment,andotherfactors.
Inordertoeffectivelymanage,elicit,analyze,document,communicate,andvalidaterequirements,businessanalystsmustbeabletounderstandthecharacteristicsofthespecificagilemethodologytheyareworkingwith.WhilewedescribeafewofthepredominantagilemethodologiesinthisAgileExtension,beforestartinganagileprojectitisimportanttospendsometimeresearchingthevariousmethodologiesandwhatisdifferentabouteach.
2.1 Scrum
Scrumisoneofthemostpredominantagileprocessframeworksinusetoday.IntheScrumframework,workonaprojectisperformedinaseriesofiterations,calledsprints,whichgenerallylastfrom2to4weeks.Attheendofeachsprint,theteammustproduceworkingsoftwareofahighenoughqualitythatitcouldpotentiallybeshippedorotherwisedeliveredtoacustomer.WithintheScrumframework
November2011DraftforPublicReview 7
Scrum Business Analysis in Agile Life-cycles
therearefourformalmeetings,knownasceremonies:sprintplanning,thedailyscrum,sprintreviews,andsprintretrospectives.
2.1.1 Backlogs
IntheScrumframeworkaproductbackloglistsalloftherequirementsforasolution,includingbothcustomerandtechnicalrequirements.Thebacklogservesasawishlistfortheproduct.Astheteamcollaborateswiththecustomerfortheproject,thebacklogispopulatedtokeeptrackofeachrequest.Thisbacklogisconstantlyprioritized,suchthatatanygiventimeitcanbeusedtoidentifyhighpriorityrequestsforthesolutionbeingdeveloped.Atthebeginningofeachsprint,inthesprintplanningceremony,theteamreviewstheprioritizedproductbacklogandidentifiesthehighest‐priorityitemsthatcanbecompletedwithinthesprintperiod.Theselecteditemsarethenplacedonasprintbacklog.Thesprintbacklogoutlinesthesprint'sgoalsandthesetoftasksrequiredtoachievethosegoals.
2.1.2 Sprint Planning and Execution
Duringthesprint,theteamrefinestheirunderstandingoftheselecteditemsandworkstoensurethattheyarecompletedwithindefinedtimelimitofthesprint.Assprintsareexecuted,theteammeetsonceperday(referredtoasthedailyscrummeeting)tobrieflydiscusswhattheyareworkingonandidentifyanyblockersthatmaypreventthemfromcompletingtheirwork.Attheendofthesprint,theteamdeliversworkingandtestedsoftwarethatfullyimplementstheselectedbacklogitems.Thesprintisthenclosedoffwithacustomer,orsprint,reviewandaretrospective.Duringthecustomerreview,ademonstrationofthesoftwareisprovidedandthecustomerprovidesfeedback.Duringtheretrospective,theteammeetsandcollaboratestofindwaystoimproveboththeproductandtheirprocessesusedtodelivertheproduct.Boththecustomerreviewandtheretrospectivemayidentifyadditionitemsthatfeedintotheproductbacklog.Theseitemsarethenusedtoreprioritizetheproductbacklogforthenextsprintplanningsession.
8 The Agile Extension to the BABOK® Guide
Business Analysis in Agile Life-cycles Scrum
Thefollowingillustrationdemonstratesatypicalscrumlife‐cycle.
FIGURE 2.1 ScrumLife‐cycle
2.1.3 Roles and Responsibilities
InScrum,therearethreeroles:
• ProductOwner.Theproductownerisresponsibleformaintainingthelistofworktobeperformedandperformingmostbusinessanalysisactivities.Itisimportanttonotethattheproductownerisnotnecessarilyabusinessanalyst,rathertheindividualontheteammostresponsibleforwhathasbeenconsideredtraditionalbusinessanalysisactivities.
• ScrumMaster.ThescrummasterisresponsibleformanagingtheScrumprocessandmanaginganyblockersthatmaypreventtheteamfromaccomplishingwork.
• TheTeam.Theteamisresponsiblefordevelopinganddeliveringtheproduct.
2.1.4 Business Analysis in Scrum
Scrumdoesnotaddressbusinessanalysisactivitiesindetailandmanyoftheseactivitiesoccurasimplicitstepsinthescrumframework.Thefollowingillustrationshowsthetypicalscrumlifecyclewithbusinessanalysistechniquessuperimposed.
November2011DraftforPublicReview 9
Scrum Business Analysis in Agile Life-cycles
FIGURE 2.2 BusinessAnalysisinScrum
Thebuildingandmaintenanceoftheproductbacklogisasignificantbusinessanalysisactivitythatfallsexplicitlyoutsidethescopeofthescrumframework(althoughothermethodologieshaveaddressedthis).Thebacklogisbuiltthroughacombinationofenterpriseanalysiswork(identifyinggapsandnewcapabilitiesrequiredtoaccomplishorganizationalgoals,anddefiningtheirvaluetotheorganization)andsolutionassessmentandvalidation(identifyingwaysinwhichtheexistingsolutioncanbeenhancedtobetterdeliverbusinessvalue).
Withinasprint,businessanalysisactivitiesfocusondefiningtherequirementsforthebacklogitemsbeingworkedonandtheacceptancecriteriaforthoseitems.Thismethodisfrequentlyreferredtoasjust‐in‐timerequirementsgathering;developingonlywhatisrequiredforthecurrentsprintandonlydonetothelevelofdetailrequiredtoenabletheteamtobuildtheproductandacceptancecriteria.Intraditionalmethods,requirementsdocumentationisfrequentlyusedasthedocumentationforthesolution.InScrum,asinmostotheragilemethods,documentationiscreatedaftertheproductisbuilttocapturetheteam’sknowledge,notdefineanexpectedordesiredoutcome.Mostfrequentlythebacklogdocumentationcreatedduringeachsprintservesassufficientdocumentationfortheproject.
10 The Agile Extension to the BABOK® Guide
Business Analysis in Agile Life-cycles Extreme Programming (XP)
2.1.5 Techniques
BacklogManagement:Backlogmanagementistheprimarymethodofhandlingbothrequirementsprioritizationandchangemanagementinmostagilemethods.Analternativetobacklogmanagementisakanbanboard(see“TheKanbanBoard”onpage15).
Retrospectives:Retrospectivesareacommonpracticeusedbyagileteamsseekingtoimprovetheirwaysofworking.Businessanalystsshouldlookforfeedbackontherequirementstheyprovidetotheteamandhowandwhenthoserequirementsareprovidedinordertofindwaystoimprovetheirprocesses.
2.2 Extreme Programming (XP)
ExtremePrograming(XP)beganbeingusedbydevelopmentteamsinthemid‐1990s.Likeotheragilemethodologies,XPisiterativeinnatureandprovidessmallreleasesattheendofeachiteration.XP’sprimaryfocusisonthetechnicalaspectsofagilesoftwaredevelopmentandisbasedon12practicesinfourcategories:
TABLE 2.1 Extreme Programming Categories
2.2.1 User Stories
XPusestheconceptofuserstoriesasacentralmechanismtodefinerequirements.UserstoriesaresimilartotheconceptoftheproductbacklogfoundinScrum.Theyarecreatedbyusersofthesystemtodefinefeaturesandfunctionalitytobeincludedinthesolution.Userstoriesdonotcontaingreatdetailandareusedto
• prioritizeworkintoiterations,• identifyriskassociatedwitharequest,• estimatetheeffortrequiredtodelivertherequest,and
Fine Scale Feedback Continuous ProcessShared Understanding Programmer Welfare
• 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
November2011DraftforPublicReview 11
Extreme Programming (XP) Business Analysis in Agile Life-cycles
• establishaconversationbetweentheteamandtheproductowneraroundthesubjectoftherealbusinessneed,inordertocreateacommonunderstandingofwhathastobedone
2.2.2 Release Planning and Execution
XPreliesonthreelevelsofplanning:
• releaseplanning,• iterationplanning,and• anddailyplanning.
Areleaseplanidentifiesthenextsetofusablefeaturethatcouldmakeuparelease.Thereareoftenseveraliterationsworthofworkbecausetheproductisrelease‐ready.Iterationplanningservestoplaneachincrementaliterationthatwillultimatelyresultinareleasableproduct.Finally,indailyplanningtheteamplansouteachday'sactivitiestoensuretheteamisonscheduleandidentifyrisksthatmayhavearisen.
InXP,releaseplansareusedtotrackanddescribewhatfeaturesorfunctionalityistobedeliveredineachproductrelease.Thereleaseplanissimilartotheconceptofthesprintbackloginthescrumframework.Iterationplanningmeetingsarethenusedasavehicleforteamcollaborationinplanningthecomingiteration.Astheteamworkstoscheduletherelease,theuserstoriesareorderedbasedonthemostimportantfeaturestothecustomer,ensuringthatthemostimportantfeaturesarealwaysdeliveredfirst.Onajust‐in‐timebasis,storiesaredecomposedintotheirgranularfunctionalrequirementsinatechniqueknownasstorydecomposition.Then,throughstoryelaboration,theteamidentifiesthedetaileddesignandacceptancecriteriaforthestory.
Whileaniterationisunderway,XPisalsosimilartoScruminthatitutilizesdailymeetingsasthekeycommunicationvehiclefortheteam,calledthedailystand‐up.Thisdailystand‐upmeetingisusedtofacilitatedailyplanningactivitiesandreviewprogresssincethepriorday'sstand‐up.Inpractice,teamsemployingtheXPmethodologyfrequentlycombinesuchelementsascadence,roles,andceremonies(suchassprintplanningandsprintreviews)fromthescrumframework.
12 The Agile Extension to the BABOK® Guide
Business Analysis in Agile Life-cycles Extreme Programming (XP)
ThefollowingdiagramprovidesanoverviewoftheXPmodel.
FIGURE 2.3 ExtremeProgrammingModel
2.2.3 Roles and Responsibilities
InExtremeProgramingtherearethreekeyroles.
• Customer.Thecustomercreatesandprioritizestheuserstoriesandpreformsriskanalysis.
• Developer.Thedevelopercommunicatesdirectlywiththecustomerandbuildsonlywhatisnecessarytodeliveroneachiteration.
• Tracker.Thetrackerkeepstrackofthescheduleandthemetrics.
2.2.4 Business Analysis in XP
WhileXPdoesfocusonvaluedrivendevelopment,itdoesnotexplicitlyaddressbusinessanalysisactivities.XPreliesonthefundamentalassumptionthatthecustomerroleisfilledbyasmallnumberofpeoplewhoknowwhatthemostvaluablefeatureswillbe.WhenXPisappliedatalargerscale,orwithcustomerswhodonothaveaclearvisionoftheincrementalvalueoffeatures,abusinessanalystaddssignificantvalueinfacilitatingandnegotiatingwithstakeholderstoreachasharedunderstandingofwhatthemostvaluabledeliverableswillbe.Abusinessanalystcanalsocontributebyfacilitatingstorymapping,atechniqueinwhichagraphicalrepresentationofstoriesalongatimecontinuumiscreated.Thestorymapisusedtoidentifyrisksanddependenciesamongstandbetween
November2011DraftforPublicReview 13
Kanban Business Analysis in Agile Life-cycles
theuserstoriestooptimizethevaluedeliveredbyeachincrementalstoryimplementation.
IntraditionalXP,theuserstoriesarecreatedandmanageddirectlybytheuser.Thiscanleadtounfilteredrequirementsthatareatriskforconstrainingasolutionwithoutconsiderationforrootcauseorapplicabilitytoothercustomergroups.Businessanalysisskillscanbeusedtoensureunderlyingproblemsarebeingaddressedinawaythatworksformost,ifnotall,ofthestakeholdersontheproject,aswellasensurethoroughacceptancecriteriahavebeencollectedforeachuserstory.Onprojectswherethereisadedicatedbusinessanalyst,thispersonmayactasabrokerorfilterfortheuserstoriesthataregeneratedbythecustomer,oftenperformingthestorydecompositionandelaborationactivities.
2.2.5 Techniques
UserStories:Userstoriesidentifywhichrolesthestoryprovidesvalueandthereforeidentifythestakeholderswhocanelaborateonthatvalue.
StoryMapping:Storymapsshowrelationshipsbetweenuserstoriesandlargeractivitiesthattheusermustbeabletoaccomplish.
StoryDecomposition:Epics,features,orminimallymarketablefeatures(MMF)tiegroupsofuserstoriestogetherintolargerpackagesthatcanbediscussedwithstakeholders.
StoryElaboration:Definesthedetaileddesignandacceptancecriteriaforauserstoryonajust‐in‐time/just‐enoughbasis.
2.3 KanbanScrumandXPareframeworksthatdefinesetsofroles,ceremonies,andpracticesforproducedelivery.Inthecontextofsoftwaredevelopment,Kanbanisamethodologyformanagingtheflowofworktoallowforevolutionarychange.WithrootsintheTheoryofConstraintsandleanproductdevelopment,Kanbanhasfourkeyprinciples:
• visualizethework,• limitworkinprocess,• focusonflow,and• continuallyimprove.
14 The Agile Extension to the BABOK® Guide
Business Analysis in Agile Life-cycles Kanban
Unliketheotheragileframeworksthatwehavediscussed,Kanbandevelopmentdoesnotrequirefixediterations.Workmovesthroughthedevelopmentprocessasacontinuousflowofactivity.AkeyfeatureofKanbanistolimittheamountofworkunderwayatanyonetime.Inthismethodologytheteamonlyworksonafixednumberofitemsatanyonetimeandworkmayonlybeginonanewitemwhenitisrequiredtomaintainflowdownstreamandafterthepreviousitemhasbeencompleted.
2.3.1 QueuesKanbanreliesontheuseofworkqueuestomanagetheflowofactivitiesthatmusttakeplacetodeliveraworkingproduct.Theformatandcontentforworkqueuesislessprescriptiveinthismethodologythanotherswehavelookedat,onlynotingthatitshoulddescribetheworktobecompletedorderedinrelativeprioritytodelivertheproduct.Forthisreason,theKanbanmethodologyisoftencombinedwithmethodssuchasScrum,wherethebacklogisusedastheimplementationforthequeue.Whenanewfeaturerequestisreceived,itisassessedforrelativepriorityandurgencyandthenplacedintothequeueinitsrelativeposition,maintainingtheorderbypriority.
AnalogoustotheScrumtechniqueofgroomingtheproductbacklog,Kanbandescribesatechniquecalledgroomingthequeue.Groomingthequeueisaperiodicexercisewheretheprojectteamscopesthefeatureswaitinginthequeuetoseeiftheyaretoolargeoroutofscopefortheupcomingrelease.Foritemsthataretoolargetobecompletedbeforeaplannedreleasedate,theprojectteamwillbreaktheitemdown(decomposesit)intosmallerchunksofwork,decidingwhichwillbeincludedinthereleaseandwhichwillnot.Theteamthenreassessesthepriorityoftheitemsinthequeueandreordersthemasneededtomaintainacontinuous,prioritizedflowofwork.
2.3.2 The Kanban BoardThetermkanbanactuallytranslatestosignboardorbillboard,anditreferstothekanbanboardusedbyteamstomanagetheirwork.Inkeepingwiththeprincipletovisualizethework,thekanbanboardisavisualdepictionoftheflowofworkthroughthesoftwaredevelopmentprocess.Thefollowingillustrationshowsanexampleofatypicalkanbanboard.
November2011DraftforPublicReview 15
Kanban Business Analysis in Agile Life-cycles
FIGURE 2.4 TypicalKanbanBoard
ThegoalofaKanbansystemistoallowworkloadstobedrivenbydemand,orpriority,tocreateacontinuousflowofworkthatavoidsbottlenecksatanyonepointintheprocess.Thismethodlimitstheamountofworkinprogressbyworkingononethingatatimeuntilitiscompletedbeforestartingthenexttask.Whenabottleneckoccurs,itisexpectedthattheentireteamwillcometogethertoremovetheblockagetohelpkeepworkmovingthroughtheflow.Thekanbanboardenablestheteamtomanagetheflowofwork,identifyingpotentialblockagesandensuringthatthenextiteminthequeueisalwaysreadyandwaitingtobeworkedon.Followingthismethodalsoexposesopportunitiesforprocessimprovementbymakingitpossibletoeasilyseewheredelaysareoccurringinthedevelopmentprocess.
2.3.3 Roles & ResponsibilitiesKanbandoesnotincludedefined,mandatedrolesorbusinessanalysismethods.Likeanyagilemethod,itdoesstrivetobreakdownworksuchthatindividualworkitemscanbeimplementedinarelativelyshortperiodoftime.TheKanbanmethodalsoattemptstobringtheprojectteamtogetherbyincreasingcommunicationandcollaboration,enablingtheteamtoworktogetherasacollectiveandcohesiveunit.
2.3.4 Business Analysis in KanbanBusinessanalysis,likeallactivitiesintheKanbanmethod,occursinaconstantandcontinuousflowthroughthelifeofaproject.Inordertomaintainaprioritizedqueueofwork,businessanalysistechniquesare
16 The Agile Extension to the BABOK® Guide
Business Analysis in Agile Life-cycles Kanban
usedtoelicitnewproductfeatures.Requirementsanalysismethodsarethenusedtoprioritizetherequirementsbasedonbusinessvalue,whilealsocontinuouslyusingstandardbusinessanalysistechniquesforscopingtheproductandmanagingthequeueofrequirements.
WhenplanningandmanagingtasksintheKanbanmethod,ServiceLevelAgreements(orSLA’s)areusedtomaintaintheestimatesforhowlongafeatureorchunkofworkwilltaketobecompleted.InKanban,thisestimateincludestheplanningandanalysisactivitiesthattakeplacebeforesoftwaredevelopmentbegins.Thismethodforcesabusinessanalysttofocusonplanningandmonitoringactivities,enablingconstantrevisionandrefinementofestimatesaseachnewrequestenterstheanalysisportionofthecycle.
InaKanbanproject,thebusinessanalystonlybeginstodefinerequirementsforanewworkitemwhenthequeuestepsforward.Atthatpointthedevelopmentteambeginstoworkononeofthecompletedrequirements,whilethebusinessanalysisbeginscollectingrequirementsforthenextiteminthequeue.Aparticularlyefficientbusinessanalystmaybeabletodefinerequirementsforasystemfarfasterthanthoserequirementscanbedevelopedandtested,whilealessefficientbusinessanalystwillnot.Byopenlyandvisiblymanagingtheworkoftheprojectteam,theseinefficiencieswillsurfaceasprocessimprovementopportunities.Thiswillhelptomitigatetheriskrelatedtothetimingofbusinessanalysisactivities,enablingthebusinessanalysttomanagetheriskearlyintheprocess.
November2011DraftforPublicReview 17
Comparison of Agile Life-cycles Business Analysis in Agile Life-cycles
2.4 Comparison of Agile Life-cyclesDespitepossessinguniquecharacteristicsanddifferentiators,agilemethodologiesandframeworksgenerallysharesomecommontraits.Thesecommoncharacteristicsareillustratedbelowinadepictionofagenericagilelifecycle.
FIGURE 2.5 GenericAgileLife‐cycle
Regardlessoftheagilemethodologyused,successfulagileprojectsfollowtheconsistentplanningrhythmorcadenceofStrategy,Release,Iteration,Daily,andContinuous(see“AgileLevelsofPlanning”onpage20).Thiscadenceiscombinedwiththenotionoffrequentandflexiblereleaseschedulesthatallowforhighcustomerinvolvementwithrapidfeedbackandfrequentproductassessments.
18 The Agile Extension to the BABOK® Guide
Business Analysis in Agile Life-cycles Comparison of Agile Life-cycles
Thefollowingtableprovidesasummarycomparisonoftwomajoragileframeworksthathavebeenoutlinedinthischapter,ScrumandXP.
TABLE 2.2 Comparison of Agile Life‐cycles
TheKanbanmethod,oftenusedtosupplementframeworkssuchasScrumorXP,describesitsownrhythmorcadenceofworkprogression.Kanbanfailstoprescriberolesandresponsibilitiesforprojectteammembersortorecommendspecificdocumentationneedsfortheprocess.ThismakesKanbanacommoncontenderforblendedmethodologies.Itisimportanttonotethatitisverycommonforprojectteamstoblendcharacteristicsoftwoormoreagileframeworksandmethodologiestocreateabestfitfortheirteamandorganizationalcontext.
2.4.1 Selecting an Agile Methodology or Framework
Withthevarietyofagilemethodologiesavailable,thequestionarises,howdoteamschoosewhichmethodologybestsuitestheirproject?Thefollowingquestionsareexamplesofhigh‐levelquestionsthatcanhelpguidethischoice.
• Fromhowmanystakeholdersdoyouneedtoelicitrequirements?
• Wherearethesestakeholderslocated?Willtheybeatthesamesiteastheprojectteam?
• Willyoursoftwareapplicationbeintegratedwithothersystems?Ifso,howmanyandhowsoon?
• Arethereanyculturalororganizationalconstraintsthatwilllimitthenumberorfrequencyofproductreleasestheteamcanmake?
Characteristic Scrum XP
TypesofProjects All <20People;Non‐Life‐CriticalFunctions
PrioritizationValues Customer‐Driven Customer‐Driven
LevelofDocumentation Anythingofvalue Aslittleaspossible
• Typical Management Docs BurndownChart Tasklist
• Typical Requirements Docs ProductBacklog,SprintBacklog
FeatureCards
• Typical Architecture Docs ArchitectureModelClass‐Responsibility‐Collaboration(CRC)Cards
• Typical Test Docs
Models/Architecture High‐LevelModelsPrototyping
SketchesClass‐Responsibility‐Collaboration(CRC)Cards
November2011DraftforPublicReview 19
Agile Levels of Planning Business Analysis in Agile Life-cycles
Theanswerstothesefundamentalquestionswillhelptoguidethechoiceofagilemethodologythatshouldbeused.Inturn,thechosenflavorofagilewilldrivethemanagementofstakeholders,thetempoofwork,thedurationofwork,documentation,analysis,andotheraspectsofthebusinessanalyst'sworkonaproject.
Whileweprovidesomeinsightintoseveralmethodswithinthischapter,therearemanyagilemethodologiesandframeworksavailabletochoosefrom.Westronglyrecommendthatyouresearchtheseagileframeworksandmanyotherstohelpyouunderstandhowtheyaredifferentandtheprosandconsofeachimplementation.Thiswillhelpyourteamtobestunderstandwhichwillfitprojectteamneedsmostappropriately.
2.5 Agile Levels of Planning
Duetothefluid,dynamicnatureofagilemethodologies,itisimportanttounderstandwhenandhowtoapplydifferentplanningtechniquesandtheappropriatelevelofdetailforeachlevelofplanning.Itisimportanttonotethatmanyofthetechniquesusedinanagileenvironmentaresimilartotraditionaltechniques,whatisdifferentishowandwhenanalystsapplythesetechniques.Just‐in‐timeandjustenoughrequirementsthatareconsistentlyvalidatedbythebusinessarecentraltotheanalyst'sroleinagilemethodologies.
Whenundergoingplanningexercisesintheagileworlditishelpfultoconsiderhowtheanalyst'srolediffersfromtraditionaldevelopmentmethodologies.Inagiletheroleoftheanalystiscentraltothevalueoftheproject.Theanalystholdsakeyroleinmaximizingvaluebyfacilitatingtheinteractionswithalltheprojectstakeholders.Exceptionallyhighcommunication,facilitation,andnegotiationskillsareanimportsetoftoolsforanalystsintheagileenvironment.
2.5.1 Agile Levels of Planning
Asmentionedintheprevioussection,ComparisonofAgileLife‐cycles(see“ComparisonofAgileLife‐cycles”onpage18),successfulagileprojectsfollowaconsistentplanningrhythmorcadenceofstrategy,release,iteration,daily,andcontinuous.Throughthecadence,therequirementsfortheprojectareprogressivelyelaboratedtoanappropriatelevelofdetail.Ateachstepstableconceptsarecaptured,contextiscaptured,andlearningopportunitiesareidentified.Oneofthekeystoagileistoperformasufficientlevelofanalysisateach
20 The Agile Extension to the BABOK® Guide
Business Analysis in Agile Life-cycles Agile Levels of Planning
planninglevel.Toomuchanalysisupfrontcanresultincreationofdocumentsthataresubjecttochange,requirethebusinessusertoexplaintheirneedsmultipletimes,andmaynotbenecessarytoachievethegoalsoftheproject.Toolittleanalysisupfrontcanresultinirresponsiblecommitments,rework,andalackoffocusoncustomervalue.
2.5.1.1 Strategy
Projectsandproductdevelopmenteffortsstartwithavisionofthebusinessdirectionorneed.Thevisionincludesthewhat,why,andsuccesscriteriafortheeffort.Thevisionisoftenassociatedwitharoadmap.Theroadmapincludesthehigh‐levelscopeandmayincludeaninitialarchitecture.Inadditiontoactivitiessuchasestablishingavision,scope,androadmap,thestrategyworkonanagileprojectincludestheinitialcreationofafeaturerequestlist.Forexample,inScrumthisentailsseedingtheinitialrequestsinaproductbacklogor,inXP,userstores.Thisisanalogoustopre‐projectelicitationofbasicstakeholderrequirementsthatareusedtofacilitatediscussionsonscopingandphasinginnon‐agileprojects.
Atastrategiclevel,thepersonwhoownstheproductorisleadingtheinitiativehelpsthedeliveryteamto
• understandthecontextofthesolutionneeded,• identifythestepstorealizethevision,• prioritizethework,• assessthetechnicalimpactontheroadmap,and• facilitateobtainingestimatesforthereleases.
Muchlikeanyproject,strongenterprisebusinessanalysisskillsarerequiredtoeffectivelyplanastrategyforanagileproject.Insomeways,youcouldarguethattheseskillsbecomemoreimportantinagilemethodologies.Thisisbecausewithoutdirectionbasedonbusinessvalueandaclearlydefinedscopeandaudience,agileprojectsareatriskfordeliveringincrementalfeaturesthatnevercometogethertocreateend‐to‐endvalueforanyonecustomergroup.Withoutaroadmapandsuccesscriteriafortheproduct,agileprojectscouldconceivablygoonforever,possiblywastingtime,money,andotherresourcesintheprocess.
November2011DraftforPublicReview 21
Agile Levels of Planning Business Analysis in Agile Life-cycles
2.5.1.2 Release
Releaseplanningisthephasewherethepersonwhoownstheproductgroupsactivitiesandallocatesthemtoteams.Teamsworkondefiningenoughdetailtoresponsiblycommittosomerangeofscopefortherelease.Teamsshouldreleasewhenthebenefitsofdeliveryoutweighthecostsassociatedwithrelease.Thereleaseisdefinedbyadate,strategictheme,andplannedfeatureset.Releasedatescanbelinkedtoevents,likeconferencesorcompliancerequirement.Inthereleaseplanningphasethescopeisfixedandtheprioritizedlistoffeaturerequests,suchasaproductbacklog,isusedasthebasisforplanning.
2.5.1.3 Iteration
Manyagileteamsworkinfixedtimewindowscalledsprintsoriterations.Aniterationplanningeventisheldatthestartofeachiteration.Priortothatiterationplanningmeeting,theitemsinthefeaturerequestlistthatarebeingconsideredfortheiterationneedtobesufficientlyunderstood,thusenablingtheteamtoresponsiblymakeacommitment.InScrumthisisknownasgroomingthebacklog.Incontinuousflowmodels,likeKanban,thefeaturerequestlistisstillgroomedbeforeitiscommitted,buttheplanningcadenceisbasedondemand,notonadefinedtimeperiod.Onsometeams,thecustomerorowneroftheproductcollaborateswiththedeliveryteamtogroomtherequestlistpriortoiterationplanning,whileotherteamsuselow‐fidelityspecificationsdevelopedduringspecificationworkshopsheldpriortoiterationplanning.Thisworkiscomprisedofrequirementcommunicationandanalysis,withadditionalelicitationanddocumentationasneeded.
Initerationplanning,theworkthatwillbeperformedinthesprintisidentified,estimated,reviewed,andcommittedto.Thedeliveryteammeetswiththecustomerortheowneroftheproducttounderstandtherequirementsandacceptancecriteria,andtogainclarityonspecifications.Thisisanalogoustotheworkatraditionalbusinessanalystperformstocommunicationrequirementstostakeholders.Duringiterationplanning,thedeliveryteammayalsoestimatetheeffortrequiredtodeliverthedesiredfeatures.Thisestimationisusedwhencommittingtotheiteration.Attheendofiterationplanning,thedeliveryteamcommitstodeliveringanincrementofworking,tested,deployablecode.
Afteraniterationhasbeencompleted,aniterationrevieworproductdemonstrationisheld.Theproductdemonstrationmeetingissimilar
22 The Agile Extension to the BABOK® Guide
Business Analysis in Agile Life-cycles Agile Levels of Planning
tolight‐weightuseracceptancetestingandisgenerallylimitedtoamaximumof4hours.
Duringtheproductdemonstration
• thedeliveryteamdemonstrateshowthecodethatwasdevelopedmeetstheacceptancecriteria,
• theowneroftheproductdetermineswhichitemsonthefeaturelisthavebeencompletedintheiteration,
• anynewrequeststhatarisefromthecustomerasaresultofviewingthelatestproductareadded,and
• theowneroftheproductanddeliveryteamreviewthestateofthebusiness,themarket,andthetechnology,andre‐prioritizethefeaturerequestlistforthenextiteration.
Aftertheiterationreviewmeeting,theprocessstartsupagain.Whileaworkingproductistheexpectedoutputofeachiteration,manyagileteamswillwaittoreleaseaproductuntilseveraliterationsworthofworkhavebeencompleted.Theteammustdeterminetheappropriatetrade‐offpointbetweenthecosttodeliverthelatestproductandtheamountofneworimprovedfunctionalitythatwillbedeliveredtothecustomerbase.Iterationsproceeduntilenoughfeatureshavebeendonetocompleteorreleaseaproduct.
2.5.1.4 Daily
Agileteamsperformdailyteammeetingstocoordinatethework.Thedailymeetingisusuallyafifteenminutemeetingdesignedtoclarifythestateofthework.
Duringthedailymeetingtheteam
• getsaglobalsnapshotoftheproject,• discoversanynewdependencies,• addressesanypersonalneedsofcommittedindividuals,and• adjuststheworkplantomeettheneedsofthedayandensure
theteamcandeliverontheIterationcommitment.
Frequentlythedialogueheldduringthesemeetinguncoversitemsthatlackofclarityorrequirefurtheranalysis.Theteamthenidentifiesaplanfordealingwiththeseimpedimentstotheproject.Thisoftenentailsassigningsomeonetodofurtherbusinessanalysisworkforelicitationandanalysisontheimpactedrequirements.
November2011DraftforPublicReview 23
Agile Levels of Planning Business Analysis in Agile Life-cycles
2.5.1.5 Continuous
Therearemanydynamicactivities,efforts,andchallengesthatariseduringtheplanningphasesofagileprojects.Herearesomeguidingprinciplesthatthoseconductingbusinessanalystmayfindhelpful,notonlyduringtheplanningphase,butthroughtheagileproject’slifecycle.
• Startwithvalueandkeeptheteamtruetovalue.Itisvitalthattheindividualholdingthebusinessanalysisroleispayingcloseattentiontotheproject’sbusinessvalue.
• Low‐fidelityartifactsserveasanenablerofbusinessvaluebycreatingcontextandgeneratingsharedunderstanding.However,theydonotreplace,oreventakeprecedenceovereffectivecollaborationandconversation.
• Businessanalysisisaboutfacilitatingdiscussionandunderstanding.Businessanalyststypicallydonotpossessthedepthofunderstandingaboutthebusinessasdoesthebusinesssponsor,orasmuchabouttechnologyasthetechnologyteam.
• Operateinthebestinterestofthebusinessovertime.Responsiblybalancevalueandcapacity.
• Identifyandcommunicatecompetingconcernsandgapsinunderstandingbetweenthebusinessandtechnology.Ensurethatcommonunderstandingisreached.
• Resourcesarelimitedandvaluable.Alwaysassistinmaximizingeffortovertime.
• Assisttheteamtoaction.Effectivelycommunicatewhatisrequiredwhentakingthenextsteps.Ensurethatfeedbackisclearlyunderstoodandactedonbytheteam.
• Deliverincrementallyanditeratively.Dothesmallest,simplestthingthatcouldpossiblywork.Iteratetoreachminimalvalue.Progressivelyelaborateinsmallpieceswhiletestingassumptionsandarticulatingclearacceptancecriteria.
• Producethesmallestamountofdocumentationthatmeetstheneedsoftheteamanddeliveritatthelatestresponsiblemoment.
24 The Agile Extension to the BABOK® Guide
chapter 3
Knowledge Areas
ThefollowingareasofknowledgerepresentaselectionofpopularagilebusinessanalysistechniquesidentifiedthroughthedevelopmentoftheAgileBABOK®Extension.ManyofthebusinessanalysistechniquesdescribedintheBABOK®Guidecontinuetobeusableinanagilecontext,aswell,andothertechniquesnotlistedheremayprovetobeusefulandapplicableinaparticularsituation.
3.1 Mapping Techniques to Knowledge Areas
3.1.1 Business Analysis Planning and Monitoring
BusinessAnalysisPlanningandMonitoring(Chapter2oftheBABOK®
Guide)describestheworkrequiredforabusinessanalysttodeterminetheactivitiesthatwillberequiredtoperformbusinessanalysisthroughthelifecycleofaproject.Inagiledevelopment,mostplanningisdeferreduntilworkonanactivityisreadytobegin,butsomedegreeofup‐frontplanningisusuallyrequired.
.1 Plan Business Analysis Approach (2.1)
Agilemethodologiesfallintothegeneralcategoryofchange‐drivenapproaches,asdescribedintheBABOK®Guide.Somebusinessanalysisworkwillgenerallybeperformedupfronttodefineavisionfortheproject,butdetailedanalysiswillbeperformedas‐needed.Ifitisunclearwhatproblemsthesoftwareissupposedtosolve,orthereareseveralstakeholdergroupswithconflictinginterests,itmaybenecessarytodobusinessanalysisworkpriortothebeginningofaprojecttoreachagreementonthevisionfortheproduct.
Techniques
Backlog Management:Backlogmanagementistheprimarymethodofhandlingbothrequirementsprioritizationandchangemanagementin
November2011DraftforPublicReview 25
Mapping Techniques to Knowledge Areas Knowledge Areas
mostagilemethods.Analternativetobacklogmanagementisakanbanboard(describedunder“Kanban”onpage11).
Planning Workshop:Businessanalystsparticipateinplanningworkshopstodeterminethebusinessanalysiseffortandactivitiestosupportateamobjective.
Real Options:Realoptionanalysismayhelpdeterminewhenbusinessanalysisneedstobeconductedtoinvestigateaparticularbusinessissue.
Retrospectives:Thefeedbackfrompriorretrospectivesshouldbeconsideredwhenselectingtheapproach.
.2 Conduct Stakeholder Analysis (2.2)
Stakeholdersmaybechallengedbytherapid,iterativedevelopmentfoundinanagileprojectandtheneedtobeoncallwheneverinformationisneededbytheteam.Whatistheimpactoftheagilecadenceonthestakeholder?Howdoesprogressiveelaborationimpacttheexpectationsofthestakeholder?Canthestakeholderparticipateinupdatingtheprocesses,interactions,andproductsspecificationsduringthecourseoftheproject?
Techniques
Collaborative Games:Manycollaborativegamescanbeusedtounderstandtheperspectivesofvariousstakeholdergroups.
Personas:Personascanhelptheanalystordevelopmentteambyenablingthemtobettervisualizetheneedsofgroupswhodonothavearepresentativepresent.
.3 Plan Business Analysis Activities (2.3)
Businessanalysisactivitiesareplannedasneeded,usuallyatthestartofeachiterationorwhenanewworkitemisreadyforanalysis.Thereislessofafocusonformaldocumentation(althoughitstillcanberequiredtomeetstatutoryorregulatoryrequirements,ortocaptureknowledgedevelopedduringtheanalysisanddevelopmentprocess)andmorefocusonprogressiveelaborationofdocumentationthroughoutthelifeoftheproject.Also,muchoftheelaborationisreplacedbyinteractionsandceremonysotheseoutcomesneedtobeaccomplishedwithactivitiesaddressedinthecommunicationplan.
26 The Agile Extension to the BABOK® Guide
Knowledge Areas Mapping Techniques to Knowledge Areas
Techniques
Planning Workshop:Decisionsregardingbusinessanalysisactivitieswillusuallybemadeduringaplanningworkshop.
.4 Plan Business Analysis Communication (2.4)
Duringdevelopment,formalcommunicationofrequirementsisgenerallyreplacedwithad‐hocinformaldiscussionsandmodelling.Somedeliverablesarereplacedbyspecificinteractionsorceremonies.Bydefinition,theseinteractionsandceremoniesrequirereal‐timeparticipationbythebusinessanalyst.Formaldocumentationmaybedevelopedfollowingdevelopmentofthesoftwaretoensureknowledgeretentionbytheorganizationortomeetregulatoryrequirements.
Techniques
Personas:Thesemayproveusefulinassessingthelikelycommunicationneedsofspecificstakeholdergroups.
.5 Plan Requirements Management Process (2.5)
Inagilemethods,requirementsmanagementisfocusedonensuringthattheintakeofnewworkbytheteammatchestheprioritiesofthestakeholdersand/orsponsor,anddeliversvaluetothebusiness.Agileapproachesstresstheimportanceofwelcomingchangingrequirements.Thismeansthattheorderingofworkitemsthatarereadyfordevelopmentmaybechangedatanytime.
Techniques
Backlog Management:Mostagilemethodsusebacklogmanagementtodeterminewhichrequirementsarereadytobeworkedonbythedevelopmentteam.
.6 Manage Business Analysis Performance (2.6)
Thisactivitywillbeperformedonanongoingbasisasthebusinessanalystlearnstoworkeffectivelywithstakeholdersandthedevelopmentteam.Aseveryoneinvolvedbetterunderstandshowtoworktogethertodelivervalue,thebusinessanalysisprocess,methods,ortechniquesinusemayneedtochange.Effectivebusinessanalysis
November2011DraftforPublicReview 27
Mapping Techniques to Knowledge Areas Knowledge Areas
performancewillresultinlimitedreworkoftherequirementsdocumentation,effectiveprioritizationandscopingofrequirements,andclearcommunicationofneedtothedevelopmentteam.
Techniques
Retrospectives:Retrospectivesareacommonpracticeusedbyagileteamsseekingtoimprovetheirwaysofworking.Businessanalystsshouldlookforfeedbackontherequirementstheyprovidetotheteamandhowandwhenthoserequirementsareprovidedinordertofindwaystoimprovetheirprocesses.
Value Stream Mapping:Valuestreammappingcanbeusefulinassessinghowbusinessanalysisactivitiesarecontributingtothedeliveryofvaluetothecustomerandidentifyingactivitiesthatmaynotbeaddingvalue.
3.1.2 Elicitation
Elicitation(Chapter3oftheBABOK®Guide)describeshowbusinessanalystsworkwithstakeholderstoidentifyandunderstandtheirneedsandconcerns,andunderstandtheenvironmentinwhichtheywork.Effectiveelicitationensuresthatthestakeholders’actualunderlyingneedsareunderstood,ratherthanstatedorsuperficialdesires.Elicitationisongoingthroughouttheprojectandperformedinconjunctionwithanalysisactivities(ascomparedtotraditionalapproaches,whereitispossibletoperformelicitationasadistinctactivityorphase).
.1 Prepare for Elicitation (3.1)
Preparingforelicitationchangesduringthelifeoftheproject.Earlyon,itisdonebythebusinessanalysttocoordinatesupportingmaterialsandscheduleresourcestodefinethehigh‐levelrequirements.Astheprojectprogresses,workiscoordinatedbyprioritizationofthebacklog.Stakeholdersworkdirectlywiththedevelopers,whenpossible,toelaboraterequirements.Wherethisisnotpossible,thebusinessanalystmustactasaproxy.Thistaskrequirestheschedulingofresourcesandthecoordinationofinputstoalignwiththeprogressiveelaborationofthebacklog.
28 The Agile Extension to the BABOK® Guide
Knowledge Areas Mapping Techniques to Knowledge Areas
Techniques
Personas:Personasmayprovideinsightintotheparticularneedsofastakeholderorthetechniquesthatwillbemosteffectiveinunderstandingthoseneeds.
User Story:Auserstorywillidentifytheroleforwhomthestoryprovidesvalue(andthereforeidentifythestakeholderswhocanelaborateonthatvalue).
.2 Conduct Elicitation Activity (3.2)
Elicitationactivitiesareconductedonafrequentbasisthroughouttheproject,possiblyevendaily.Earlyon,elicitationisperformedtodefinehigh‐levelrequirementsoravisionfortheproduct.Astheprojectprogress,stakeholdersinteractwiththedevelopmentteamdirectlyduringiterationplanninganddevelopment.Theintentofallelicitationactivitiesistogeneratejustenoughdetailtoensurethattheworkathandisperformedcorrectly.
Techniques
Behaviour Driven Development:Stakeholdersmayfinditeasiertoarticulatetheirneedsbyprovidingexamplesratherthanthroughabstractmodels.
Collaborative Games:Collaborativegamesencourageparticipantsinanelicitationactivitytocollaborateinbuildingajointunderstandingofaproblemorasolution.
Note:Asmentionedabove,analysisisusuallyperformedduringelicitationsessions.MostofthetechniquesfoundintheAgileExtension,aswellasmanyofthetechniquesintheBABOK®Guide,aresuitableforthispurpose.
.3 Document Elicitation Results (3.3)
Amajorvalueofdocumentationisthatitcanbeusedforlong‐termknowledgeretention.Agilemethodsaimtominimizethetimebetweenthedevelopmentofrequirementsandtheirimplementationinsoftware,reducingtheoverallvalueofthatdocumentationtotheteam.Recordsofelicitationactivitiesshouldbekepttoensurethatkeydecisionscanbeunderstoodatalaterdate,ortoensurethatregulatoryorgovernancerequirementsaremet.
November2011DraftforPublicReview 29
Mapping Techniques to Knowledge Areas Knowledge Areas
Techniques
Lightweight Documentation:Seethissectionforguidelinesondevelopingdocumentation.Inmostcases,therewillnotbeseparatedocumentationoftheelicitationandanalysiswork.
.4 Confirm Elicitation Results (3.4)
Thiswillbeperformedbytheteamduringiterationplanning,duringthedevelopmentiteration,andatcustomeracceptance.Thecustomermaychangetheirmindaboutsomespecificelementofastoryafterseeingtheresult.Thisfeedbackbecomesaninputintotheconductelicitationactivity.
Techniques
AcceptanceandEvaluationCriteriaDefinition:Elicitationoutcomeswillfrequentlybecapturedintheformofacceptancecriteriathatwillbeusedbytheteamtoverifythatthesoftwaremeetsstakeholderneeds.
3.1.3 Requirements Management and Communication
RequirementsManagementandCommunication(Chapter4oftheBABOK®Guide)describeshowbusinessanalystsmanageconflicts,issues,andchangesinordertoensurethatstakeholdersandtheprojectteamremaininagreementonthesolutionscope,howrequirementsarecommunicatedtostakeholders,andhowknowledgegainedbythebusinessanalystismaintainedforfutureuse.
.1 Manage Solution Scope and Requirements (4.1)
Asagileprojectsunfold,thescopeisdefinedwithincreasingspecificity.Thespecificdetailsofthescopecanbefoundinthesolutionbacklog.Basedonthelevelofelaboration,thesolutionbacklogitselfmayvaryinitsownlevelofdetail.Itshouldalsobeconsideredthatthesponsormaydecidetoterminatetheprojectshouldtheydecidethatfurthereffortswillnotprovideanacceptablereturnofbusinessvalue.
Techniques
Backlog Management:Mostagileteamsusetheproductbacklogtomanagebothsolutionscopeandrequirements.
30 The Agile Extension to the BABOK® Guide
Knowledge Areas Mapping Techniques to Knowledge Areas
.2 Manage Requirements Traceability (4.2)
Onagileprojects,everythingisconnectedbacktothestrategicthemes,epics,andstoriesthatareusedtodefinetheproject.Thisismaintainedbytheproductownerorthebusinessanalyst.
Techniques
Story Mapping:Storymapsshowrelationshipsbetweenuserstoriesandlargeractivitiesthattheusermustbeabletoaccomplish.
.3 Maintain Requirements for Reuse (4.3)
Inmatureagileorganizations,thishappensmuchthesamewayasitdoesintraditionalefforts.Thedifferenceisinthewaythatrequirementsaredocumentedattheendoftheproject.Often,thesourcecodeitselfiswrittentobeself‐documenting.
Techniques
AcceptanceandEvaluationCriteriaDefinition:Theacceptancetestsandcriteriadevelopedduringtheprojectaremaintainedtovalidateanyfuturechangestothesoftware.
.4 Prepare Requirements Package (4.4)
Thisishandledthroughscenarios,usecases,acceptancetests,andmock‐upsandmodelsassociatedwiththethemes,epics,andstoriesusedtodefinetheproject.Thisisanongoingactivitythroughthelifeofthedevelopmentofthesolution.Thespecifictechniquesusedwilldependupontheapproachchosenatthebeginningoftheproject,andwillchangebasedontheemergentunderstandingofwhatworksbestinthecontextoftheproject.
Story Decomposition:Epics,features,orminimallymarketablefeatures(MMF)tiegroupsofuserstoriestogetherintolargerpackagesthatcanbediscussedwithstakeholders.
.5 Communicate Requirements (4.5)
Requirementsarecommunicatedtodevelopersinreleaseplanningmeetingswherethemesandstoriesarereviewedandselectedforrelease.Theyarediscussedinmoredetailiniterationplanning
November2011DraftforPublicReview 31
Mapping Techniques to Knowledge Areas Knowledge Areas
meetingswherethemodelsandspecificationsareselectedanddiscussedamongtheteamandtheproductowner.Intheseiterationplanningmeetings,risksarealsoreviewedanddiscussed.
Planning Workshop:Seethistechniqueforfurtherdetails.
3.1.4 Enterprise Analysis
EnterpriseAnalysis(Chapter5intheBABOK®Guide)describeshowbusinessanalystsidentifyabusinessneed,refineandclarifythedefinitionofthatneed,anddefineasolutionscopethatcanfeasiblybeimplementedbythebusiness.Thisknowledgeareadescribesproblemdefinitionandanalysis,businesscasedevelopment,feasibilitystudies,andthedefinitionofsolutionscope.Enterpriseanalysisisaboutidentifyingthebusinessneed,opportunityorproblemtobesolvedanddecidingontheappropriateapproachtoaddressingtheneed.
.1 Define Business Need (5.1)
Nosignificantchanges.
Techniques
Business Capability Analysis:Abusinessneedwillusuallycorrespondtothedevelopmentofanewcapabilityortheenhancementofanexistingcapability.
Collaborative Games:Somecollaborativegamescanbeusefulinexposingunmetbusinessneeds.
.2 Assess Capability Gaps (5.2)
Nosignificantchanges.
Techniques
Business Capability Analysis:Thiscanbeusedtounderstandwhatshortcomingsexistinanexistingcapability.
.3 Determine Solution Approach (5.3)
Agiledevelopmentisasolutionapproach.Itmaybeselectedinordertoprovideafasterdeliveryofvaluethantraditionalmethods,or
32 The Agile Extension to the BABOK® Guide
Knowledge Areas Mapping Techniques to Knowledge Areas
becausetheproblemareaneedstobeexplored.Italsosupportsincrementaldeliverysothesolutionapproachcanbeevolvedoverthecourseoftheproject.Thisapproachallowsadifferentbargaintobestruckwiththebusinessregardingdeterminingthesolution.
Techniques
Purpose Alignment Model:Thepurposealignmentmodelcanprovideguidanceregardingthebestsolutionapproachtotakeforagivenbusinessneed.
.4 Define Solution Scope (5.4)
Thescopeofagileprojectsevolvesduringthecourseoftheprojectastheteamlearnsmoreaboutwaystosolvetheproblemandthecustomerpreferencesforasolution.Thescopeisdefinedinhigher‐levelabstractions(suchasthemesandepics)andisdetailedastheprojectevolves.
Business Capability Analysis:Thescopeoftheprojectshouldberelatedtothebusinesscapabilitiesitiscreatingorenhancing.
Story Decomposition:Epicsandfeaturescanserveasthebasisfordefiningthescope.
Story Mapping:Astorymapcanbeusedtoseetherelationshipbetweenthevariousstoriesdeliveredbytheproject.
.5 Define Business Case (5.5)
Thebusinesscaseforagileprojectsistypicallybasedonachievingaspecificbusinessoutcomewithinaspecifiedcostandtime.Thebusinesscaseisrevisitedfrequentlyastheteamlearnswhatitcandeliver,howwellitmeetsthereal(notperceived)needs,andwhetherthebusinessoutcomecanbeachievedwithinthespecifiedcostandtime.
Business Capability Analysis:Definesthecustomerandorganizationalvalueassociatedwithabusinesscase.
Kano Analysis:Identifieswhichproductfeaturesarelikelytohavethegreatestmarketimpact.
November2011DraftforPublicReview 33
Mapping Techniques to Knowledge Areas Knowledge Areas
Purpose Alignment Model:Identifieswhatkindofinvestmentislikelytogeneratethegreatestvaluefortheorganization.
Real Options:Allowsassessmentofwheninvestmentneedstobemadeinordertoensurevalueisobtained.
3.1.5 Requirements Analysis
RequirementsAnalysis(Chapter6intheBABOK®Guide)describeshowbusinessanalystsprioritizeandprogressivelyelaboratestakeholderandsolutionrequirementsinordertoenabletheprojectteamtoimplementasolutionthatwillmeettheneedsofthesponsoringorganizationandstakeholders.Itinvolvesanalyzingstakeholderneedstodefinesolutionsthatmeetthoseneeds,assessingthecurrentstateofthebusinesstoidentifyandrecommendimprovements,andtheverificationandvalidationoftheresultingrequirements.
.1 Prioritize Requirements (6.1)
Inagile,requirementsareprogressivelyelaborated.Throughouttheelicitationtask,elicitationresultsareprogressivelybrokendownandelaborated.Ateachpointofelaborationtheconstituentpartsneedtobeevaluatedandprioritizedbasedonbusinessvaluecontributionandriskburn‐down.Inagile,thisisnotaone‐timeupfrontactivity.Thishappensthroughoutthelifeoftheprojectonallremainingworkandnewworkbroughtinfromlearningabouttheproduct.
Techniques
Backlog Management:Backlogmanagementisthestandardmethodofprioritizingrequirementsinmanyagilemethodologies.Thebacklogcanbere‐prioritizedwheneverbusinessneedschangeorarebetterunderstood.
Kano Analysis:Kanoanalysiscanprovideinsightintotherelativeimportanceoffeaturestoausergroup.
Planning Workshop:Prioritizationnormallytakesplaceduringaplanningworkshop.
Note:alsoseetheexpandedtreatmentofMoSCoW Prioritization.
34 The Agile Extension to the BABOK® Guide
Knowledge Areas Mapping Techniques to Knowledge Areas
.2 Organize Requirements (6.2)
Inagile,itisimportanttoorganizerequirementstominimizedependenciesbetweenfeaturesets.Thisreducescomplexityandriskandimprovestestabilityatthebusinesslevelvalue.Sincerequirementsareprogressivelyelaborated,thisbigblockarchitectureresultsinthesolutionarchitecturefromabusinessstandpoint.Requirementsshouldbeorganizedaroundbusinessvalueandnottechnicalimplementations.Onlywithincomponentteams,wherethebusinessvaluearisesfromdeliveringenablingtechnology,isitappropriatetodepicttechnicalrequirements.Eventhen,theserequirementsneedtobeprioritizedandfilteredbasedonriskburndownandbusinessvaluecontribution.Storymapswithinepicsareamethodofimplementingorganizerequirements.
Techniques
Story Decomposition:Individualstoriesmaybeorganizedaroundanepicorfeature.
Story Mapping:Storymappingalsoshowshowindividualstoriesarerelatedtoorsupportoneanother.
.3 Specify and Model Requirements (6.3)
Atdifferentlevelsofelaborationtherearedifferentmethodsforspecifyingandmodellingrequirements.Theapproachshouldsupportprogressiveelaboration,beadaptabletochangebasedonlearning,andnotcausetheteamtoselectsolutionstooearly.Itshouldalsoensurethatintentandintendedbusinessvalueiscommunicatedconsistentlythroughtheelaboration.Agileteamstendtousestoriesandtasksatthelowestlevelofdecomposition.Thesestoriesandtaskscanbesupportedbydetaileddocumentationandusecases.Itisbecomingincreasinglycommonforacceptanceteststobeproducedaspartofspecifyingandmodellingtherequirements.
Techniques
Behaviour Driven Development:Concreteexamplesoffunctionalitymayhelpstakeholdersbetterspecifyandunderstandtheirneeds,ordealwithspecificscenariosthatareofgreatervalue.
Storyboarding:Usedtodescribeuserinterface(UI)functionalityandbehaviour.
November2011DraftforPublicReview 35
Mapping Techniques to Knowledge Areas Knowledge Areas
Note:alsoseetheexpandedtreatmentofUser Storyinthisextension.
.4 Define Assumptions and Constraints (6.4)
Onagileprojects,thisishandledthroughariskmanagementapproachthattreatsrisksasstorieswithinthemes.Riskmitigationactivitiesarere‐prioritizedalongwithstoriesandburneddownandre‐prioritizedastheystoriesareperformed.Thisistypicallyproducedbythebusinessanalystandprojectmanageralongwiththeteam,prioritizedbytheproductowner,andperformedbytheteam.
User Story:Userstoriescanalsobeusedtotrackassumptionsorconstraints(particularlythelatter),althoughitneedstobecleartotheteamandstakeholdersthattheseareseparatefromthestoriesplannedfordevelopment.
.5 Verify Requirements (6.5)
Requirementsareverifiedbytheteamduringtheproject.Throughretrospectivesandoperationsreviews,theteammaydecidetomodifythelevelofdetailtorequirementsorthemethodofspecifyingandmodellingrequirementstoimprovetheperformanceoftheteam.Verificationofrequirementsusuallyisdonethroughdirectstakeholderinteractionwiththeteamasthesoftwareisdeveloped.
.6 Validate Requirements (6.6)
Requirementsareverifiedthroughoutthedevelopmentanddeliveryofthesolutionthroughcontinualinvolvementoftheproductownerandcustomer.Thishappensatreleaseplanning,iterationplanning,duringdevelopment,andatcustomeracceptance.
3.1.6 Solution Assessment and Validation
SolutionAssessmentandValidation(Chapter7oftheBABOK®Guide)describeshowbusinessanalystsassessproposedsolutionstodeterminewhichsolutionbestfitsthebusinessneed,identifygapsandshortcomingsinsolutions,anddeterminenecessarywork‐a‐roundsorchangestothesolution.Italsodescribeshowbusinessanalystsassessdeployedsolutionstoseehowwelltheymettheoriginalneedsothatthesponsoringorganizationcanassesstheperformanceandeffectivenessofthesolution.
36 The Agile Extension to the BABOK® Guide
Knowledge Areas Mapping Techniques to Knowledge Areas
.1 Assess Proposed Solution (7.1)
Inagileprojects,thistaskislikelytobeperformedrepeatedlyasthesolutionisbuilt.Oneofthebenefitsofagileisthatthesolutioncanbeassessedovertime.Somesolutiondecisionsmustbemadeupfront.Agilefacilitatestheconceptofrealoptionswheredesigndecisionscanbedeferreduntilthelastresponsiblemoments.Detailedunderstandingofthebusinessneedisunfoldingatthesametimeastheteam’sunderstandingofhowtosolvetheproblemisdeveloping.Witheffectiveagilearchitectureanddesign,thecostofredoingthingsthathavealreadybeendevelopedisrelativelylow.Assessingtheproposedsolutiondoesn’tbecomeacheckpointontheprojectbutanongoingassessmentagainstthebusinesscaseandcurrentstatusoftheproject.
Techniques
Real Options:Allowsforassessmentofaspectsofthesolutiontodeterminewhendecisionshavetobemaderegardingaparticularproposal.
.2 Allocate Requirements (7.2)
Onagileprojects,thisisdonebyallocatingrequirementsintofeaturethemesandcomponents.Agileteamsaresmallteamsandthisallocationshapesthedesignofthedeliveryorganizationitself.Featureteamsformaroundthefeaturethemesandcomponentteamssupportingcross‐featurethemerequirements.
Techniques
Story Decomposition:Breaksdownhigh‐levelepicsandfeaturesintosmallersupportingstories,whichcanbeallocatedtodifferentcomponents(includingprocessororganizationalchanges).
.3 Assess Organizational Readiness (7.3)
Theorganizationalreadinessassessmentoccursonagileprojectsinmuchthesamewayasitdoesintraditionalprojects.Thedifferenceisthatthereleasecadencecanbemorefrequent.Asignificantareatodefineinagileprojectsishowoftentheorganizationcanabsorbreleases.Organizationalreadinessshouldincludenotjusttheend‐user/customerofthereleasebutthesupportingorganizationaswell(forexample,support,training,sales,marketing,andaccounting).
November2011DraftforPublicReview 37
Mapping Techniques to Knowledge Areas Knowledge Areas
.4 Define Transition Requirements (7.4)
Thedeterminationoftransitionrequirementsoccursinanagileprojectmuchasitdoesinatraditionalproject.Theabilitytodelivervalueincrementallyopensupnewpossibilitiesfortransition.Unlikeamonolithicrelease,theorganizationalimpactcanbesmallerbutmorefrequent.Sincethecostofdevelopmentperunitislower,temporaryintegrationintoexistingsystemscanbedevelopedandmaketheneedforrunningparallelsystemslesssignificant.
Techniques
User Story:Userstoriescanbeusedfortheplanningoftransitionrequirementsandareprioritizedand/ororderedinthesamefashionasotherstories.
.5 Validate Solution (7.5)
Validationofasolutionhappensasanongoingeffortinanagileproject.Withineachiteration,thecustomerisprovideddetailedfeedbackonthecurrentrequirements.Atthecompletionofeachiterationcycle,theproductownerfacilitatesalignmentwiththecustomerneedandcontinuedalignmentwiththebusinesscase.
.6 Evaluate Solution Performance (7.6)
Uponrelease,theproductownerfacilitatesunderstandinghowwellthesolutionmeetstheneedsofthecustomerandidentifiesnewopportunitiesforimprovementandtocreateadditionalvalueforthebusiness.Theincrementalnatureofthebacklogallowsnew,highervalueitemsdiscoveredduringthisevaluationtoenterintotheexistingbacklogaheadofexistingitems.Thisisanadditionalwaythatagileshortenstimetovalue.
Techniques
Business Capability Analysis:Allowsbusinessanalystsandstakeholderstounderstandtheimportanceandrelativeperformanceofabusinesscapability.
Value Stream Mapping:Usedtoidentifythoseaspectsofthesolutionthataddvalueforcustomersandthosewhicharenon‐valueadded.Thisassessmentbecomesthebasisforongoingimprovementefforts.
38 The Agile Extension to the BABOK® Guide
Knowledge Areas Mapping Techniques to Knowledge Areas
3.1.7 Business Analysis Techniques Mapped to Agile Business Analysis Guidelines
ThefollowingtablemapstechniquesasdescribedintheBABOK®
Guidetotheguidelinesforagilebusinessanalysispresentedinthisdocument.
TABLE 3.3 Business Analysis Techniques Mapped to Agile Business Analysis Guidelines
Business Analysis Technique
BABOK v.2 Chapter
See the Whole
Think as a Customer
Get Real with Examples
Analyze to Determine What is Valuable
Understand What is Doable
Stimulate Collaboration & 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
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
November2011DraftforPublicReview 39
Mapping Techniques to Knowledge Areas Knowledge Areas
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
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
Business Analysis Technique
BABOK v.2 Chapter
See the Whole
Think as a Customer
Get Real with Examples
Analyze to Determine What is Valuable
Understand What is Doable
Stimulate Collaboration & Improvement
Avoid Waste
40 The Agile Extension to the BABOK® Guide
Knowledge Areas Mapping Techniques to Knowledge Areas
State Diagrams 9.29
Structured Walkthrough 9.30
Survey/Questionnaire 9.31
SWOT Analysis 9.32
Timeboxing/Budgeting 6.1.5.3
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
Get Real with Examples
Analyze to Determine What is Valuable
Understand What is Doable
Stimulate Collaboration & Improvement
Avoid Waste
November2011DraftforPublicReview 41
Mapping Techniques to Knowledge Areas Knowledge Areas
42 The Agile Extension to the BABOK® Guide
chapter 4
Techniques
4.1 A Context for Agile Business Analysis
ThischapteroftheAgileExtensiontotheBABOK®Guideprovidesanalystswithskillsandtoolsthatwillassisttheminexcellingintheagileworld.Inorderforthetechniquesandskillspresentedinthissectiontobeappliedwithsuccess,therearesomefoundationalprinciplesthatarerequiredtobeunderstood.Theseprinciplesbreakdownintoanumberofpracticaltechniquesthatcanbeusedbypractitionerswhentheyundertakebusinessanalysisonagileprojects.
Theprinciplesthatguidesuccessfulbusinessanalysiscanbecategorizedintotwodistinctframeworks:discoveryanddelivery.
Thediscoveryframeworkdealswiththewhat’sandthewhy’softheproduct.Effectivediscoveryisformulatedbythreeunderlyingprinciples:
• See The Whole,• Think as a Customer,and• Analyze to Determine What is Valuable.
Thedeliveryframeworkdealswiththehow’sandthewhen’softheproduct.Effectivedeliveryisformulatedbyfourunderlyingprinciples:
• Get Real Using Examples,• Understand What is Doable,• Stimulate Collaboration & Continuous Improvement,and• Avoid Waste.
Thefollowingsection,AgileExtensionTechniques,exploreseachprincipleindepthandprovidestechniquestosupporttheapplicationoftheseprinciples.
November2011DraftforPublicReview 43
Guidelines for Agile Business Analysis Techniques
4.1 Guidelines for Agile Business Analysis
Thefollowing7guidelinesforpracticingbusinessanalysisinsideanagilecontext,arebasedonthevaluesandprinciplesoftheAgileManifestoandtheprinciplesofLean.Together,theseguidelinesembodythedisciplineofagilebusinessanalysis.Theseguidelinesprovidevaluablecontextwhenapplyingthevarioustechniquesdescribedinthischapter.
• Inanagilecontext,businessanalysisviewstheentiresystemofpeople,process,andtechnologytofindwheretruevalueliesandtohelporganizationsmaximizesthelikelihoodofdeliveringavaluableandvaluedsolution.
• Agileanalysispaysspecialattentiontothevoiceofthecustomertounderstandtheirvaluesandexpectations.
• Toconfirmwhatisvaluable,itiscommontouseconcreteexamplestobothelicitandvalidateproductneeds.
• Technologystakeholdersareempoweredbyeffectivelyanalyzedneeds.Ithelpsthemdeterminehowmuchworktheycandeliveratanygivenpointintime,identifyproductrequirementsoptions,andproviderecommendationstobusinesspartnersonsolutions.
• Facilitativetechniquesenableefficientandeffectivecollaborationandaccelerateateam'sabilitytodefineanddeliverproducts.Trustandsafetyareintegraltohealthyteam'sandallowsthemtotransparentlyidentifyimprovementopportunities.Improvingbothproductandprocessisimperative;thereforeagileteamscontinuallyseektoalwaysgetbetter.
• Alwaysbeonthelookoutfor,andavoid,anythingwasteful.
Adoptingtheseguidelinesrequiresleveraging,extending,andadaptingfoundationalbusinessanalysistechniques.“BusinessAnalysisTechniquesMappedtoAgileBusinessAnalysisGuidelines”onpage39foramatrixofbusinessanalysistechniquesthatmayapplyinanagilecontext.
4.1 A Note on Agile Extension Techniques
Agilebusinessanalysisisstillinarelativelyearlyphaseofdevelopment.Assuch,thetechniquesusedbybusinessanalyststosupportagileteamsarealsoinastateofflux.Webelievethatthe
44 The Agile Extension to the BABOK® Guide
Techniques See The Whole
techniquesdescribedherehaveprovenvalueinsupportingagilebusinessanalysis,butwedonotclaimthatthislistisall‐inclusiveorinanywaycanonical.Thetechniquesherewereselectedbasedontheexperiencesoftheteammembers,andrepresentbothexpansionstoexistingcontentintheBABOK®Guideandnewtechniquesnotdescribedinthecurrentversion.FutureversionsoftheAgileExtensionwilllikelyincludenewtechniques,anditisalsopossiblethatsomeofthetechniqueslistedherewillberemoved.
Inaddition,manyofthetechniqueslistedheremayproveusefultobusinessanalysispractitionerswhoarenotworkingonagileteams.
4.1 See The Whole
SeetheWholeisaconceptthatdescribestheneedtolookataproblemoropportunityinthecontextofthebigpicture,focusingonthebusinesscontextandwhyaprojectisbeingundertaken.Itdescribesnotjustwhatasystemis,buthowitwillbeused.Itisimportanttoassesshowthesolutionachievessomethingofvalueforitsrecipients.Thevaluecontextforthesolutioniscreatedbyunderstandingboththesolutionandthestakeholders,andthenarticulatingwhotheyareandhowtheywillfindvalueinthesolution.
Onagileprojectsthereisahighriskofgettingmiredinthedetailsoneachiteration.Whendevelopingthebusinesscaseforasolutionandperformingiterationandreleaseplanningactivities,itisimportanttomaintainthefidelityofthecontext.Bydoingso,thecontextguidesthenextlevelofelaboration.Bythinkingaboutthestrategicoutcomeforthesolution,thedeliveryteammovesfromordertakerstoagroupthatdeliversbusinessvaluewithlesscodebloat,scopecreep,andnever‐endingprojecttimelines.Seeingthewholecreatessituation,appropriatecontextandasharedunderstandingofthebusinessproblemthatneedstobesolved,whichinturnwillguidedecisionmaking.
Thefollowingsectionsdescribecommonlyusedtechniques.
• Business Capability Analysis• Personas• Value Stream Mapping
November2011DraftforPublicReview 45
See The Whole Techniques
4.1.1 Business Capability Analysis
.1 Purpose
Provideaframeworkforproductscopingandreleaseplanningby:generatingasharedunderstandingoftheoutcomesofabusinessorproduct,identifyingalignmentwithastrategyandspecificperformancegaps,andprovidingascopeandprioritizationfilterthatisstableandlowfrictiontomaintainovertime.
.2 Description
Businesscapabilitiesdescribetheabilityofabusinesstoactonortransformsomethingthathelpsachieveabusinessgoalorobjective.Manyproductdevelopmenteffortsareanattempttoimprovetheperformanceofabusinesscapabilityortodeliveranewbusinesscapability.Businesscapabilityanalysisistheanalysisoftheperformanceandriskassociatedwithasetofbusinesscapabilitiestoidentifyspecificperformancegapsandtoprioritizethesebasedonbusinessvalueandrisk.
.3 Elements
Capabilities
Capabilitiesaretheabilitiesinabusinesstoperformortransformsomething.Capabilitiesshoulddescribethepurposeoroutcomeoftheperformanceortransformation,nothowtheperformanceortransformationisperformed.Itdescribesthewhat,asopposedtothehow.Forexample,sendingafaxisnotacapability;notifyingthecustomeristhecapability.
Using Capabilities
AmodelofBusinessandCustomerValue:Businessvalueissomethingthatincreasesorprotectsrevenue,reducesorpreventscost,improvesservice,achievescompliance,orpositionsthecompanyforthefutureinalignmentwiththebusinessstrategy.Notallcapabilitieshavethesamelevelofvalue.Forexample,whiledistributingpayrolltoemployeesisimportanttoacompany,itislikelyneitherofhighbusinessnorcustomervalue.Inotherwords,thismaynotbeacapabilitythataddsvalueforthecompanytobuildandmaintaininternally.Therearevarioustoolsthatcanbeusedtomake
46 The Agile Extension to the BABOK® Guide
Techniques See The Whole
businessandcustomervalueexplicitinacapabilityassessment.Inadditiontothesetools,balancedscorecardscanbeusedasamodelofbusinessvalue.
Performance Expectations
Sincecapabilitiesidentifytheabilitiesrequiredtoperformortransformsomething,capabilitiescanbeassessedtoidentifyexplicitperformanceexpectations.Whenacapabilityistargetedforimprovement,aspecificperformancegapcanbeidentified.Whiletheperformanceofeverycapabilitycanbeimproved,theperformancegapisthedifferencebetweenthecurrentperformanceandthedesiredperformancegiventhebusinessstrategy.
Risk Model
Risksintheperformanceofthecapabilityfallintothefollowingcategories:
• businessrisk,• technologyrisk,• organizationalrisk,and• marketrisk.
Strategic Planning
Businesscapabilitiesforthecurrentstateandfuturestateofanorganizationcanbeusedtodeterminewherethatorganizationneedstogoinordertoaccomplishtheirbusinessstrategyandimperatives.Asaresultofperformingabusinesscapabilityassessment,thereisgenerallyasetofrecommendationsorproposalsforsolutionsthatneedtobeputinplace.Thisinformationformsthebasisofaproductroadmapandservesasaguideforreleaseplanning.
Capability Maps
Frequently,organizationsusecapabilitymapstoprovideagraphicviewofelementsinvolvedinbusinesscapabilityanalysis.Thefollowingillustrationdemonstratesoneelementofacapabilitymapthatwouldbepartofalargercapabilitiesgrid.
November2011DraftforPublicReview 47
See The Whole Techniques
FIGURE 4.6 SampleCapabilityMap
.4 Usage Considerations
Capabilityanalysisisusefulwhenanorganizationchangesitsbusinessfocusorstrategy,orthereismoredemandforchangethanthereiscapacitytodeliver.Whenthedemandoutweighsthecapacitytodeliver,alargeundifferentiatedbacklogofchangesorimprovementrequestscanresult.Capabilityanalysishelpstoidentifythoseimprovementrequeststhatwilladvancethestrategicgoalsofthebusiness.Uponcompletionofaprojecteffort,thecapabilityanalysiscanbeupdatedtoreflectimprovementsinperformanceandtoidentifythenextmostimportantcapabilityperformancegaptofocuson.
Theoutcomesofacapabilityanalysisserveaslong‐livedartifactsthatrepresentacommonviewofthebusiness.Thiscanbeusedtogeneratesharedunderstandingandalignefforts.Whenthebusinessstrategychangesorcustomerdesiresevolve,thismodelcanbeusedtorapidlyre‐prioritizethelistofwantsforasolution(forexample,re‐prioritizingthebacklog).
48 The Agile Extension to the BABOK® Guide
Techniques See The Whole
Advantages• Theadvantagesofcapabilityanalysisarethattheyresultina
sharedarticulationofoutcomes,strategy,andperformance.Thesehelpcreateveryfocusedandalignedinitiatives.Themodelworksverywellwithagileteamsbutitalsohelpsidentifyopportunitiesthatarenottechnologybased,includingprocess,talent,anddataimprovements.
• Thecapabilityanalysishelpsaligntheseinitiativesacrossmultipleaspectsoftheorganization.
Disadvantages• Thismodelrequiresanorganizationtoagreetocollaborateon
thismodel.• Whenthismodeliscreatedunilaterallyorinavacuumitfailsto
deliveronthegoalsofalignmentandsharedunderstanding.• Themodelalsorequiresabroad,cross‐functionalcollaboration
indefiningthecapabilitymodelandthevalueframework.
Implications for Agile
Agilemethodologiescreateaframeworkthatfacilitatesfrequentre‐assessmentofbusinessneedsandvalue.Thedirectionofthebusinessandthegapsrequiredforthebusinesstomeetitsobjectivesmustberevisitedforeachreleaseplanningsession,whichgenerallyoccursevery2‐4weeksinmostagilelifecycles.Thismeansthatanagileprojectteammustmaintainaconstantviewofthebusinesscapabilitiesthatarerequiredforthebusinesstobesuccessful,particularlythosethatareinscopefortheproductbeingdelivered.
BusinessValue:SeeKano,PurposeAlignment,BalancedScorecard,Moscow.
4.1.2 Personas
.1 Purpose
Usercentereddesignpracticesoftenusepersonasasapowerfulandsimpletooltohelpdesignsoftwarethatuserswillenjoyandbenefitfrom.
November2011DraftforPublicReview 49
See The Whole Techniques
.2 Description
Personasarefictionalcharactersorarchetypesthatexemplifythewaythattypicalusersinteractwithaproduct.Theyareoftenusedinagilemethodstounderstandvaluefromtheperspectiveofaparticularcustomerandallowateamthatmaynothavedirectaccesstoacustomerrepresentativetobetterunderstandtheirneeds.Workcanthenfocusonthefeaturesofgreatestvaluetoaparticularpersona.
.3 Elements
Apersonashouldbedescribedasthoughtheyarearealperson.Personasmayprovideaname,personality,family,workbackground,skilllevel,preferences,behaviorpatterns,andpersonalattitudes.Itisalsoagoodpracticetoincludeapictureandwriteashort“dayinthelife”narrativethathelpstheteamvisualizetheuser.
.4 Usage Considerations
Usepersonaswhenyouwanttogetadeeperunderstandingofkeystakeholdersthanonegenerallygetsfromatraditionalroleoractordescription.Personashelpdriveproductsthatarefitforpurposeandhighlyusable,becausetheyarepatternedafterthesubtlequalitiesofrealpeoplethatwillinteractwiththesystemsandhowtheydotheirjob.
Ifthedataisavailable,usingdemographic(oranthropomorphic)dataabouttheintendeduserpopulationisagoodwaytostartbuildingpersonas.Howeverinsomecasesitisnecessarytobecreativeandinventpersonasbasedonlittlemorethanafewdryfactsabouttheintendedendusers.Ineithercase,arepresentativepoolofpersonasshouldbeidentified.Dependingonthesizeoftheprospectiveuserbaseanddiversityofthatpopulation,thepersonasidentifiedmayrangefromasmallhandfultoadozenormore.
Personasarethenrankedtoidentifyafewkeytargetsthatwillrealizethemostbenefitfromthesystemdesign.Whendesignconsiderationsaremade,theimpacttheywillhaveonthetargetedpersonasshouldbetakenintoconsideration.
“Afrequentmistakeistodesignforsomeonewhoisclosetotheproductbutisnottheactualuser…theITmanagerwhopurchasedtheproductwillrarelybetheonetoactuallyuseit.”(Cooper,1999)
50 The Agile Extension to the BABOK® Guide
Techniques See The Whole
Advantages• Personashelpteammembersshareaspecific,consistent
understandingofvariousaudiencegroups.Dataaboutthegroupscanbeputinapropercontextandcanbeunderstoodandrememberedincoherentstories.
• Proposedsolutionscanbeguidedbyhowwelltheymeettheneedsofindividualuserpersonas.Featurescanbeprioritizedbasedonhowwelltheyaddresstheneedsofoneormorepersonas.
• Provideahuman“face”soastofocusempathyonthepersonsrepresentedbythedemographics.
Disadvantages
• Personasarefictionalsothereisoftenatendencytocreatepersonasthatembodytraitsthatarecommontomostusers,butindoingsocreatingagenericuserthatisnotdistinctorrealistic.Thiscanleadtosoftwarethatisdesignedtobeeverythingtoeveryone.
• Personasmaynotbeagoodsubstituteforarealuser,iftheyareavailable.Personascandistanceateamfromausercommunity.
4.1.3 Value Stream Mapping
.1 Purpose
Valuestreammapping(alsoknownasmaterialandinformationflowmapping)providesacomplete,fact‐based,time‐seriesrepresentationofthestreamofactivitiesrequiredtodeliveraproductorservicetothecustomer(internalorexternal).Itisusedtoidentifyareasofpotentialimprovementinanend‐to‐endprocess.
.2 Description
Valuestreamrepresentstheflowofmaterialandinformationrequiredtobringaproductand/orservicefromrawmaterialtothecustomer.Valuestreammap(VSM)isagraphicalrepresentationthatcapturesasnapshotofthevaluestream.
Thetwomaintypesofvaluestreammapthatarewidelyusedare:
• CurrentStateValueStreamMap:Depictsavaluestreamasitisappliedbythosewhoareresponsibleforcarryingit.Itis
November2011DraftforPublicReview 51
See The Whole Techniques
usuallyusedasastartingpointforanalysisofanexistingprocesstoidentifyimprovementopportunities.
• FutureStateValueStreamMap:Derivedfromthecurrentstateanditshowswhatthevaluestreamwilllooklikeaftertheimplementationoftheimprovements.
Inanagileenvironment,thisdiagramisusuallysimpleanddrawnonawhiteboard.Itcanbeusedtohelpre‐engineerbusinessprocessestooptimizeuseofsoftware.Itcanalsobeusedtore‐engineerandtunethesoftwaredevelopmentprocessitself,forexample,toreduceleadtimefromproductdiscovertorelease.
.3 Elements
Thefollowingisabroaddescriptionforoneapproachtobuildingavaluestreammap.
Prepare• Gathercross‐functionalteam.Intheagileworldthisshould
includepeoplewithbusinessdomainknowledgeandtechnicalteammembers(suchasdevelopers,testers,andarchitects).Oftensomeoneactingasthebusinessanalystwillfacilitatethesession.
• Assignavaluestreammapowner.Ideallythisissomeonewhohasadeepunderstandingofthecurrentprocess.
• Selectaproduct,aproductfamily,oraservice,anddefinethescopeofthevaluestreammap.
• Inthecontextofagileprojects,valuestreammappinglooksattheflowofinformationneededtocompleteabusinessprocessfromend‐to‐endandthehand‐offsbetweenrolesand/ororganizationalunitsinthatprocess.
Create Current State
Thecurrentvaluestreammapcanbecapturedfollowingthesesteps:
• Observeorsimulatevaluestream.Followaproduct(orproductfamily)pathbystartingattheendclosesttothecustomerandrecordtheprocessworkingyourwaybackwardstothebeginning.Simulatingthevaluestreamcanbedoneindifferentways.Teammembersmightstartwiththestepstheyareresponsiblefor,oritcanbeachievedinagroupworkshopwiththecrossfunctionalteam.
52 The Agile Extension to the BABOK® Guide
Techniques See The Whole
• Drawthevaluestreammap.• Capturetheinformationflow.Theinformationthatisvitalfor
thevaluestreamtofunction.Informationflowincludes(butnotlimitedto)thingssuchasorders,schedules,inventorytime,changeovertime,cycletime,andnumberofoperatorsinvolved.
• Buildamodelthatshowseachstepintheflowwithhand‐offsandsequence.Toassistintheanalysisneededtoidentifyopportunitiesforimprovementintheprocess,ensurethatyouincludetime/costvaluesontothestepsintheprocess.Thesetimevaluesmaybeestimated,ifneeded.Themoredetailsavailable,theeasieritistoidentifyimprovementopportunities.
• Validatethevaluestreammap.Theinitialdraftofthecurrentvaluestreammapmustbevalidatedbeforeproceedingtotheimprovementphase.Teammemberscanusedirectobservationoftheworkplaceforthispurpose.
Analyze Current State
ThecurrentvaluestreammapcanbeanalyzedasdescribedinRootCauseanalysisoftheBABOK®Guide(9.25RootCauseAnalysis)toidentifyvalueaddedsteps(suchastransformationprocesses)fromthosethatarenon‐valueadded(suchasexcessiveinventories).
Thenon‐valueaddedstepscanbeanalyzedfurthertodeterminewhichonesarenecessary(suchasmeetingregulatoryrequirements)andwhichonesareunnecessary(suchasexcessivepaperwork).
Create Future State
Thefuturestatevaluestreammapcanbedrawnasfollows:
• Identifyimprovementareas.Unnecessarynon‐valueaddedstepsarethesourceofwasteand,assuch,theycanbeeliminated.Teammemberscanmarktheseareas(suchasreducingleadtime)onthecurrentvaluestreammap.
• Capturethefuturestatevaluestreammap.Drawthevaluestreammapthatshowswhatthevaluestreamwilllooklikeafteryouhaveeliminatedthewaste(unnecessarywaittime,excessiveadministrativepaperwork,highinventories).
Oncethefuturestateiscaptureditwillbeusedasthetargetstateoftheimprovementinitiative.
November2011DraftforPublicReview 53
See The Whole Techniques
Implement Process Improvement • Identifysupportingmaterialrequiredforimplementingthe
improvementsuchastrainingandchangeover.• Implementtheimprovementfollowingoneofthewell‐known
businessprocessmethodologiessuchas,butnotlimitedto,LeanorSixSigma.
Inanagileproject,valuestreammappingwillbemostutilizedwhenimplementingprocessimprovement.Oftenthechangestobemadeinthebusinessprocesswillrequirechangestoorimplementationofsupportingsoftwareproducts.Therequirementsforthesechangesorenhancementsbecomebacklogitemsthatfeedintoanagileinitiative.
Oncetheimprovementismade,thefuturestatebecomesthecurrentvaluestreammapanditcanbeusedasastartingpointforanotherimprovementcycle.
Thefollowingisanexampleofavaluestreammap.
FIGURE 4.7 ValueStreamMap
54 The Agile Extension to the BABOK® Guide
Techniques Think as a Customer
.4 Usage Considerations
Advantages• Morecomprehensivethanaprocessflowdiagram.• Providesablueprintforimplementingimprovement.• Establishesasharedunderstandingofprocesswastesand
bottlenecks.• Providesacommonvisuallanguagefordiversestakeholders.
Disadvantages• Noteasytoconstructincomparisonwithothervisualmodeling
techniques.• Canlookdauntingbecauseofalltheinformationcaptured.• Mappingparalysis.Itiseasytogetcaughtmakingthevalue
streammapcompleteandperfectinsteadofproceedingtotheimprovementstage.
• Doesn’tworkwellinknowledgebasedornon‐linearwork.• Leadstodisruptiveor“re‐engineering”approach.Doesn’twork
wellwithongoingimprovementefforts.
4.1 Think as a Customer
Thinkinglikeacustomerisakeycomponentofagilebusinessanalysis.Thecustomeristhepersonwhogetsvaluefromtheproductwearebuilding.Westartwithahighlevelviewofcustomergoalsandprogressivelydecomposetheseintoamoreandmoredetailedunderstandingofthespecificneedsthattheproductmustmeet.
Agileprocessesincorporatefeedbackloopstocontinuouslyvalidatethisunderstanding.Asproductdeliveryprogresses,thecustomerandteamunderstandingoftheneedswillevolve,itisimportantthatthesechangesinfluenceanddefinetheworkoftheteamgoingforward.
Agileanalysisslicesthedeliveryintothesmallestpracticalincrementsthatdeliverbusinessvalueoverthelifeoftheproject.
Itisimportantthatagileanalysisstartwithaholisticperspective,inordertohelptheteamunderstandtheoverallproductthatneedstobedelivered.Theteamcollaborateswiththecustomertoconsidertheuserexperienceexpected.
November2011DraftforPublicReview 55
Think as a Customer Techniques
Agoalofanalysistoensurethevoiceofthecustomer,especiallytheend‐user,iselicitedandexpressedintheproduct.
Backlogitemsrepresentworktobedoneandconveycustomerthinking,andcanberepresentedthroughprototypes,userstories,usecases,minimalmarketablefeatures,features,epics,orworkitems.
Thefollowingsectionsdescribecommonlyusedtechniques.
Thetechniqueslistedbelowarebasedonuserstories:
• Story Decomposition• Story Elaboration• Story Mapping• User Story
Atechniqueforprototypingauserinterfaceandusingthattodefinedetailedrequirementsis
• Storyboarding
4.1.1 Story Decomposition
.1 Purpose
Storydecompositionisaderivationofexistingrequirementsanalysistechniquessuchasfunctionaldecomposition.Inanagilecontext,storiesareoftenusedtorepresenttheworkoftheteamandtherequirements(oracceptancecriteria)ofthatwork.Storydecompositionensuresthattherequirementsforaproductarerepresentedattheappropriatelevelofdetailandarederivedfromavaluablebusinessobjective.
Thistechniqueprovidesastructurefordefiningthevariouselementsofrequirementsatprogressivelysmallerlevelsofgranularity,startingwiththebroadsystemcontextanddrillingdowninmultiplelevelstoeventuallydefinethedetailedacceptancecriteriaforindividualuserstories.
.2 Description
Themostcommonagileapproachtostorydecompositioncanbedescribedas“breadth‐before‐depth”:startwithaveryhighlevelpictureofwhatbusinessgoalsneedtobeachieved,decomposethose
56 The Agile Extension to the BABOK® Guide
Techniques Think as a Customer
intosmallercomponentsthatprovideincrementsofvaluablefunctionality(sometimescalledminimallymarketablefeaturesetsorMMFs),splitthecomponentsintouserstories,andeventuallyelaboratetheuserstorieswithacceptancecriteria,see“StoryElaboration”onpage59.Astorythatistoolargeorinsufficientlyunderstoodtoelaborate,estimate,ordeliverasastoryissometimescalledanepic.Epics,whenused,arelaterdecomposedintosmallerstories.
FIGURE 4.8 StoryDecomposition
Differentteamsapplythistechniqueindifferentways.Forexample,someteamsfollowthemodellinearly,asshownintheabovediagram,whileotherteamsutilizetechniquesthatworkbestintheirenvironment.Forexample,onceateamhasdevelopedtheMMF(sometimesreferredtoasfeaturegroups),theymayemployusecasesinsteadofstories.Theanalyst’srolehereistofocusondynamiccollaboration,facilitation,andcommunicationingettingacceptanceforjustwhatisrequiredtodevelopanddelivertheproduct.
November2011DraftforPublicReview 57
Think as a Customer Techniques
Thefollowingtabledescribesthedifferentlevelsofstorydecomposition.
TABLE 4.4 Story Decomposition
.3 Usage Considerations
StoryDecompositionisundertakenprogressively.Oneofthemostsignificantdifferencesbetweenagileprojectsandwaterfallprojectsisinthedefinitionofdetailedrequirements.Inagileprojects,theinitialanalysisactivitieswillidentifythegoals,MMFs,andmostoftheepics.Theinitialsetofuserstories(probablyforthefirstreleaseoftheproduct)willbedoneintheprojectinitiationactivities.Thereisaclearunderstandingthatthesestoriesarelikelytochangeandthattheteams’understandingoftherequirementswillevolveovertime.Therefore,decomposingtothelowestlevelofdetailislikelytobeawastefulactivityearlyintheproject.
Advantages• Thisdecompositiontechniquehelpsavoidthecommon
problemofgettinglostinthedetailoftheuserstoriesandlosingthebig‐picturecontext.
• Itisimportantthatteammemberskeeptheproject’sgoalsandobjectivesinmind,andwhileusingthedecompositionapproachtheyareabletotraceimplementedorrequestedfunctionalitybacktothedrivingbusinessobjectives.
Level Description System Goals The system 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 Minimum Marketable Feature. 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.
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. User stories are defined in detail in the Technique chapter.
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.
58 The Agile Extension to the BABOK® Guide
Techniques Think as a Customer
• BreakingtheproductintoMMFsandepicshelpswithrelease‐levelplanning,providesvisibilityintothedevelopmentproject,andhelpscoordinateexternalprogramactivitiessuchasorganizationalchangemanagementandusertraining.
Disadvantages
• Acommonanti‐patternisthetemptationtotreatstorydecompositionasawayofrevertingtodetailedrequirementsup‐front.Ensuringthecontinuedemphasisonjust‐enoughandjust‐in‐time,meansknowingwhentostopdecomposing.
4.1.2 Story Elaboration
.1 Purpose
Storyelaborationisatechniqueusedtodefinethedetaileddesignandacceptancecriteriaforauserstoryonajust‐in‐time/just‐enoughbasis.Storyelaborationisanongoingactivitythatispartofthedevelopmentprocess.
.2 Description
Storyelaborationisthelowestlevelofstorydecompositionandtheprocessbywhichthestorysentenceisintobrokendownintopiecesofwork.Thisisoftendonebysomeoneontheteamwhohasstrongbusinessanalysisskills,particularlywithfacilitationandcommunication.Storyelaborationisthetechniquethroughwhichdetailedrequirementsareelicitedandcommunicatedtotheprojectteam.
Duringeachrelease(iteration/sprint),theteamthatworksonastoryschedulestimetoexpandonthestorytounderstandthedetail.Often(butnotalways)thisiscompletedinashortworkshopwiththeprogrammerswhowillworkonthestory,thebusinessSME/customerwhoneedsthestory,thepersonwhowilltestthestory,andsomeoneactingasabusinessanalysttofacilitateandchallengethestory.Typically,storyelaborationisundertakenafewdaysaheadofthedevelopmentofthestory.
Storyelaborationisacommunicationtechniquethathelpsensurethecorrectproductisbuilt.Inanagileproject,thedetailedrequirementsareproducedbystoryelaboration.However,asopposedtowaterfallapproaches,andconsistentwiththejust‐in‐timephilosophyofagile,
November2011DraftforPublicReview 59
Think as a Customer Techniques
thedetailedrequirementsdefinedduringstoryelaborationcontainonlytherequirementdetailsforthepieceofworkthatistobecompletedinthecomingrelease.
.3 Elements
Theresultofstoryelaborationisasharedunderstandingamongtheparticipantsofwhatthestorymeansandwhatshouldbedeliveredtoachievethe“Done”stateforthisstory.Theroleofthebusinessanalystindevelopingandcommunicatingdynamicrequirementsnecessitatesahighdegreeofskillinbothfacilitationandcommunication.
Theoutputsofeffectivestoryelaborationdescribeand/ordocumentthetasksthatenabletheteamtosuccessfuldelivertheupcomingiteration.Theseoutputsmayinclude
• detailedrequirementsfortheupcomingrelease,• taskdefinitionsandbreakdowns,• examplesandscenariosthatexplainthecustomer'sintentfor
thestory,• low‐fidelitymodelsthatclarifythetechnicalorprocessdesign
(forexample,datamodels,dataflowdiagrams),• screenorreportmock‐ups,• acceptancecriteria(testdesignspecifications)toclarifyhow
thestorywillbetested,ofteninthe<given><when><then>formatofbehaviordrivendevelopment,and
• otherartifactsthatwillbeusefulinthedevelopmentandtestingofthisstory.
.4 Usage Considerations
Advantages• Themajoradvantageofstoryelaborationisthatitavoids
wastefulrequirementselicitation,andpotentiallydocumentationaswell.Byelaboratingonrequirementsonlyastheyareneeded,theteamavoidstheworkofelicitingrequirementsforfeaturesthatmayneverbebuiltorthatwillneedtobechangedbythetimetheyarereadyforimplementation.
60 The Agile Extension to the BABOK® Guide
Techniques Think as a Customer
Disadvantages• Forthosewhoarerelativelynewtoagilemethodologies,itcan
bedifficulttodeterminethebesttimingforconductastoryelaboration.Ifconductedtooearly,theinformationmaynolongerbecorrectforthegivenreleaseandwillneedtobere‐elicited.However,whencollectedtoolate,itcandelayprojectteamprogressiontodevelopment.
• Anotherchallengetoimplementingstoryelaborationistheabilitytoelicittheappropriatelevelofdetailsuchthattherequirementscanbedeveloped,tested,andcomparedtoacceptancecriteria.
Timing
Storyelaborationshouldbedoneonanas‐needed,just‐in‐timebasisforstoriesthathavebeendeterminedtobeinscopefortheupcomingrelease.Theprojectteamshouldnotinvestigatestoriesforfurtherelaborationiftheyhavenotbeenplannedforthereleaseinquestion,astheinformationcollectedmaybestaleandoutofdate.
4.1.3 Story Mapping
.1 Purpose
Storymappingprovidesavisualandphysicalviewofthesequenceofactivitiestobesupportedbyasolution.Itusesatwo‐dimensionalgridstructuretoshowsequenceandgroupingsofkeyaspectsoftheproductonthehorizontaldimension,withdetailandpriorityofstoriesontheverticaldimension.
.2 Description
Astorymapisatooltoassistincreatingunderstandingofproductfunctionality,theflowofusage,andtoassistwithprioritizingproductdelivery(suchasreleaseplanning).Itisadecompositiontechniquethatallowsfortheevolutionaryunderstandingofaproductstartingwithanend‐to‐endviewanddrillingdowntothedetaileduserstories.
Astorymapisdesignedtobeaninformationradiator,usedtovisualizeaproduct'srequestsinthecontextofusageandpriority.Thestorymapisoftenplacedondisplayfortheprojectteamduringreleaseplanningsessions.Byanalyzingthestorymap,theteamcanmorereadilyidentifydependenciesgeneratedasaresultofthe
November2011DraftforPublicReview 61
Think as a Customer Techniques
intendedflowthroughtheuserstories.Themapcanalsobeusedforriskassessmentandmanagementbyexamininghowthestorieswillneedtoworktogetherinthecontextofdeliveringbusinessvalue.
Thefollowingillustrationisanexampleofastorymap.
FIGURE 4.9 StoryMap
.3 Elements
Thestorymaphasacentralbackboneofelementsthatwillmakeuptheproduct.Abovethisbackbonearethelargefeaturesets(activities)thatneedtobedeliveredoverthelifeoftheproject.Thebackboneisasequentialsetofoperator/customertasksthatneedtobeenabledbythesoftware.Belowthebackbonearethedetailedstoriesthatimplementthespecificpiecesoffunctionalitytoenablethetaskstobeaccomplished.
Process
Theprocessofbuildingastorymapcanbedescribedasaseriesofsteps.
1. Identifythekeyactivitiestheproductmustsupport,writingeachactivityonaseparatecardoradhesivenote.Useonecolorfortheactivitycards.
62 The Agile Extension to the BABOK® Guide
Techniques Think as a Customer
2. Sequencetheseinorderofusage,fromlefttoright.Whilethesequenceinwhichactivitieswillbeperformedwillvary,therewillbeacommon“day‐in‐the‐life‐of”sequencewhichcanbeused.Theseactivitieswillnormallybetoolargetoimplementinasingledevelopmentiteration.
3. Oncetheactivitiesareinalogicalorder,definetheindividualtasksthatmakeuptheactivities.Thesetasksshouldbeadiscretepieceofworkforsomeoneoperatingtheproduct.Writeeachtaskonasepa‐ratecardoradhesivenote,usingadifferentcolorfromtheactivities.
4. Placethetasksonasinglerowinlogical,sequentialorderunder‐neaththeactivities.Again,therewilloftennotbeastrictsequencewhichmustbefollowedeverytime,buttherewillbeacommonlog‐icalorderinwhichtasksaredone.Thisisthesequenceofthetasksonthemap.
5. Validatetheactivitiesandtaskswithdomainexpertsandotherstakeholders.Askthequestion:dotheyconstituteacompletepic‐tureofwhattheproductneedstodeliver?Updateandamendtheactivitiesandtasksasneeded.
6. Addsub‐tasksbelowthetasks,againusingadifferentcolorcardoradhesivenote.Thesewilloftencoverthealternativewaysofunder‐takingataskordealwithexceptionsorpotentialproblemswhenperformingatask.Addthesebelowthetaskinatop‐to‐bottomlogi‐calorderbasedonuserpriority.Thesesub‐tasksareattheleveloftheuserstoryandtherewillbemanyofthem.Viewingthetoprowofsub‐tasksacrossthemapprovidesaviewofthelikelyminimumviableproduct,thesetoffeatureswhichmustbedeliveredfortheproducttohaveanyvalueatalltothebusiness.Thishorizontalviewoftheuserstoriesprovidesalogicalstartingpointforreleaseanditerationplanning,asthevertIcalpositionofauserstoryshowsitsrelativepriorityintheoverallpicture.
7. Validatethestorymapwithstakeholdersandupdateitasneeded.8. Keepthestorymaptogethertoprovideabig‐pictureviewofthecompleteproduct.Indicatewhenstoriesarecompletedonthestorymapsooverallprogressisclearlyvisible.
.4 Usage Considerations
Advantages• Whenthelargercontextofaproductisnotaccountedfor,agile
projectscanbesubjecttogettingmiredinthedetailswithaninabilitytoeffectivelystringcomponentstogethertocreateend‐to‐endbusinessvalue.Storymappinghelpsavoidthe
November2011DraftforPublicReview 63
Think as a Customer Techniques
commonproblemofgettinglostinthedetailoftheuserstoriesandtheriskoflosingthebig‐picturecontext.
Disadvantages• Storymappingcanbecomecumbersomewheretheproductis
verylargeandmayrequirebuildinganumberofstorymapsthatcoveralargeprogramofwork.Whilestorymapsillustrateaflow,theydonotanalyzeorillustratedependenciesbetweenrequirements(thoughtheycanbeusedtohelpfacilitatethatanalysis).
4.1.4 User Story
UserStoriesaredescribedindetailintheBABOK®Guide(9.33UserStories).Thisinformationfoundherereflectsandexpandsonthatinformationinthecontextofagiledevelopmentmethodologies.
.1 Purpose
Auserstoryrepresentsasmall,concisestatementoffunctionalityneededtodelivervaluetoaspecificstakeholder.
Userstoriescanbeused:
• tocaptureandprioritizeuserneeds,• asabasisofestimatingandplanningproductdelivery,• asabasisforgeneratinguseracceptancetests,• asametricformeasuringthedeliveryofvalue,• asaunitfortracingrelatedrequirements,• asabasisforadditionalanalysis,and• asaunitofprojectmanagementandreporting.
.2 Description
Userstoriesareaplanningtechniquethatenablesagileteamstotrackfeaturesofvaluetoacustomerorenduser,andareusedasabasisforestimatingwork.Typically,theyareoneormoresentenceswrittenbythecustomers,productowners,orbusinessanalyststhatdescribesomethingofvaluetoastakeholder.Userstoriesprovideamechanismfortheproductownertoscope,coordinate,andprioritizetheincrementsofuservaluefordevelopment.Astoryshouldbeshortenoughtobewrittenonasmallpapernotecard,usuallya3×5inch
64 The Agile Extension to the BABOK® Guide
Techniques Think as a Customer
indexcardorstickynote.Storiesmayalsoberecordedinanelectronicsystem.
Userstoriescapturestakeholderneedsusingshort,simpledocumentationandinviteexplorationoftherequirementsthroughconversations,tests,and/orsupplementalrequirementsrepresentations,asneeded.Theyareconciseandeasytochangeasstakeholderneedsarebetterunderstoodorasthoseneedsevolve.
Someteamsmakeuseofothertypesofstoriestocatalogue,estimate,plan,andtrackotherworkneededtobuildtheproduct.Thesestoriestypicallydefineworkneededtoenableproductdevelopment,deployment,andsupport.
.3 Elements
Title (optional)
Thetitleofthestorydescribesanactivitythattheuserwantstocarryoutwiththesystem.Typically,itisanactive‐verbgoalphrase,similartothewayusecasesaretitled.
Description
Thereisnomandatorystructureforuserstories,however,themostpopularformatincludesthreecomponents:
• auserroleorpersona[WHO],• anecessaryaction,behaviour,orfeature[WHAT],and• thebenefitorbusinessvaluereceivedbytheuserwhenthe
storyisimplemented[WHY].
Usageexample:
“Asa<role>,Ineedto<behavior>sothat<businessvalue>”
Analternativeformat,preferredbythosewhopracticebusinessanalysisinAgiledevelopmentis:
“Inorderto<businessvalue>,asa<role>,Ineedto<behavior>
Thiscanonicalformatcanalsobeusedforstoriesprovidedfromotherproductorprojectconstituents.Forexample:
November2011DraftforPublicReview 65
Think as a Customer Techniques
“AsaSecurityOfficer,IneedtoonlyallowauthorizeduserstoaccessthexyzfunctionalitysoIcaninsureweenforceabcsecuritydirective”.
Conversation
Userstoriesserveasareminderthattheteamneedstoexploreandunderstandthefeaturedescribedinthestoryandthevaluethatitwilldelivertothecustomer.Thestoryitselfdoesn'tcaptureeverythingthereistoknowaboutthecustomerneed,andtheinformationinthestorywillbesupplementedbyfurthermodelingasthestoryisdelivered.
Acceptance Criteria
Whenauserstoryiswelldefinedandunderstood,itisaccompaniedbyacceptancecriteria.Acceptancecriteriadefinetheboundariesofauserstoryandhelpproductowners,customers,orbusinessanalyststoanswerwhattheyneedtoprovidevaluewiththeproduct.
Acceptancecriteriahelpdevelopersidentifywhentostopaddingmorefunctionalityandtoderivetestsforverificationandvalidationpurposes.Acceptancecriteriaaretypicallyaddedjustbeforeplanningorjustintimeduringdevelopment.Theycanalsobedevelopedasastorybecomeswellunderstoodtoenablethedevelopmentteamtoverifythatthesolutionwillmeettheuser’sneeds.
Acceptancecriteriaareoftenbuiltshortlypriortoorinparallelwiththeimplementationoftheuserstory.
.4 Usage Considerations
Advantages• Tiedtosmall,implementable,andtestableslicesof
functionalityfacilitatingrapiddeliveryandfrequentcustomerfeedback.
• Easilyunderstandablebystakeholders.• Canbedevelopedthroughavarietyofelicitationtechniques,
includingbutnotlimitedtofacilitatedworkshops,contextualinquiry,andotherethnographicelicitationtechniques.
• Userstoriesaresimpleenoughthatpeoplecanlearntowritetheminafewminutes,beingcarefulaboutalwaysdeliverbusinessvalue.
66 The Agile Extension to the BABOK® Guide
Techniques Think as a Customer
• Theprocessofcollaboratingondefiningandexploringstoriesbuildsteamcommitmentandsharedunderstandingofthebusinessdomain.
• Storiesinviteconversationforfurtherdecompositionandexploration.
Disadvantages• Thisconversationalapproachcanchallengetheteam,since
theydonothavealltheanswersanddetailedspecificationsupfront.
• Tofacilitateestimating,planning,anddelivery,manyagileteamssupplementstorieswithanalysismodels(suchasadatamodel,businessrules,useracceptancetests,screenmock‐upsorprototypes,contextdiagram,andstatediagram)
• Large,chunkystories(epics)canbevagueanddifficulttousewithoutbreakingthemdownintosmallstories.
• Storiesspawnmorestoriesviadecompositionsotheinformationmustbeorganizedtoensureitiscurrentandrelevant(calledpruningorgrooming).
• Thecollectionofstoriesneedstobemanaged(forexample,withbacklogmanagement).
• Storiesrequirecontextorline‐of‐sight.Iftheteamdoesn’ttracestoriesback(throughvalidation)orsupplementthemwithhigher‐levelanalysisandvisionartifacts,thentheteamcanlosesightofthebigpicture.
• Somepractitionerscanbeconfusedamongstuserstories,usecase,andstoriestechniques.
4.1.5 Storyboarding
.1 Purpose
Storyboardingisusedinconjunctionwithothertechniquessuchasusecases,userstories,andprototypingtodetailvisuallyandtextuallythekeyeventssummingupdifferentinteractionsofuserswiththesystemorbusiness.
Storyboardingserves
• toelicit,elaborate,organizeandvalidatetherequirements,• tocommunicatetodeveloperswhatneedstobebuilt,
November2011DraftforPublicReview 67
Think as a Customer Techniques
• toshowdifferentvariationsoftheproposedsolution,and• asaninputtotests.
.2 Description
Storyboards(alsoknownasdialogmap,dialoghierarchy,ornavigationflow)userepresentativeimagesandtexttodescribeatask,ascenario,orastory.Itcanalsobeusedwithprototypingtechniquetorepresentpartsofthesystemthatarewellunderstoodorexpensiveandunnecessarytoproduceviaformalprototypes.
Whenusedtodescribetheinteractionwiththesystem,thestoryboardshowshowscreenswilllookandhowtheywillflowfromonetoanother.Whenusedtodescribebusinessorganization,thestoryboardshowstheinteractionwithabusinessprocesssuchasbackoffice.
Storyboardscanbedevelopedusingwhite‐boardsandstickynotesorusingCASEtools.
Storyboardsarecommoninmanyanalysisanddevelopmentmethodologies,andareaformofprototyping(seetheBABOKGuide,9.22Prototyping).However,asagilemethodsfavourthedevelopmentofworking,usablesoftwareoverthrowawayprototypes,storyboardingisausefultoolforunderstandinghowpeoplewillactuallyusethesystem.
.3 Elements
Storyboardscanbecreatedinaworkshopenvironmentwithrelevantstakeholders.
Preparation
1.Identifymainscenarioswithinthescopeoftheproject.Thiscanbedrivenfromusecasesoruserstoriesorcanbeidentifiedinacustomervisitoraninformation‐gatheringsessionwithexperts.
2.Selectthescenariosthatneedtohaveastoryboarddeveloped.Whilesomescenariosneedtobedetailedinastoryboard,othersareobviousandcanbeomittedsuchasalternatescenariosandexceptions.
3.Identifyparticipantsandschedulethesession.
68 The Agile Extension to the BABOK® Guide
Techniques Think as a Customer
4.Arrangeroomandequipmentsuchasflipcharts,markers,glue,scissors,rulers,printers,andaccesstotheInternet.
Session
1.Haveattendeescreateillustrationsforthestoryboardsoftheselectedscenarios.
2.Enhancestoryboardillustrationswithtextualinformationsuchasoptionalinteractions,unavailableinteractions,furtherstakeholderrequestsnotassociatedwiththeprimaryscenario,andgeneralnotesassociatedwithaspecificstep.
3.Makesureeachstoryboardstandsonitsownbyaddingrequiredexplanationsastext.
Wrap up• Attheendofthesession,thebusinessanalystreaches
consensusonthehighlevelflowofthedevelopedstoryboards.
Aftertheworkshop,thebusinessanalystmightusecompanytemplatestoformallydocumenttheoutcomeofthesession,addingadditionalelementstothestoryboardssuchasstoryboardidentification,description,user,trigger,input,output,andissues.ThebusinessanalystmayalsouseCASEtoolstocreaterepresentativescreensthatwillbeusedforlatervalidation.
.4 Usage Considerations
Advantages• Intheearlystagesoftherequirementsgatheringprocess,
storyboardingcansignificantlyreduceabstractnessbroughtbyothertechniquessuchasusecasesanduserstories.
• Storyboardscanbeproducedquicklyandataverylowcostcomparedtoothertechniquessuchasprototypes.
• Theintuitivenatureofthestoryboardencouragesstakeholderparticipation.
Disadvantages• Differentlookandfeelthanthefinalproduct.• Easytogetboggeddownonhow,ratherthanwhy.
November2011DraftforPublicReview 69
Analyze to Determine What is Valuable Techniques
4.1 Analyze to Determine What is Valuable
Theagileapproachisdistinctinthatvalueiscontinuouslyassessedandprioritizedtoensurethatthemostvaluableworkisdeliveredatanypointintime,alwaysusingtheendcustomerperspective.Itisalsoimperativetoquestionthepurposebehindrequirements,challengingthoserequirementsthatdonotsupportthebusinessgoals.Agilepracticesenabletheartofmaximizingtheamountofworknotdone,somethingessentialtodelivervaluablesoftwareearlyandcontinuously.Thetechniquesoutlinedinthissectionfacilitatethevaluationofproductneedsonanon‐goingbasis.
Thefollowingsectionsdescribecommonlyusedtechniques.
• Backlog Management• Business Value Definition• Kano Analysis• MoSCoW Prioritization• Purpose Alignment Model
4.1.1 Backlog Management
.1 Purpose
Thebacklogisawishlistofrequestsforfeaturestobeincludedinaproduct,andisthemainmechanismformanagingrequirementsonanagileproject.
.2 Description
Theproductbacklog,whichderivedfromtheScrumframeworkisleveragedinmanyblendedagilemethodologies,isestablishedatthebeginningofaproject.Thebacklogisafluiddocumentthatevolvesoverthecourseoftheprojectasmoreislearnedabouttheproductanditscustomers.Theproductownerisresponsiblefororderingtheitemsonthebacklogbasedonbusinessvalue,featureimportance,orotherrelevantcriteria.Whenmanagingabacklog,itemsshouldbeorderedsuchthatthemostimportantitemsoccuratthetopofthelistandareorderedbasedondescendingpriority.InXP,thebacklogoffeaturerequestsmaybemanagedasalogofuserstories.Abusinessanalystmayactastheproductownerorsupporttheproductownerrole.
70 The Agile Extension to the BABOK® Guide
Techniques Analyze to Determine What is Valuable
Duringthereleaseplanningsessions,itemsareselectedfromthebacklogbasedonfactorssuchaspriority,risk,valuetotheproductorcustomer,andabilitytodeliverthefeaturewithinthegivenrelease.Attheendofeachrelease,feedbackonwhatwasdevelopedmayresultinnewitemsbeingaddedtothebacklog,changedpriorities,orremoveditems.
Thebacklogissometimesreferredtoasaportfolioofoptionsthatthebusinesscaninvestin.Othertermsusedaremasterstorylistandprioritizedfeaturelist.
.3 Elements
Items in the Backlog
Thebacklogcancontainuserstories,usecases,features,functionalrequirements,aswellasitemsthathavebeenaddedbytheteamtosupportdevelopmentoftherequirements,suchastechnicalinfrastructure.Toaidinorderingthebacklog,itemsshouldbeexpressedinsuchawaythatthebusinessvalueoftheitemsisclear.Productriskmitigationitemsmayalsogetaddedtothebacklogasstoriesorpiecesofworktobedone.
Appropriate level of detail
Itemswithhighorderinthebacklogwillbedevelopedinnear‐termreleases,sotheyneedtobedetailedenoughtoallowthedevelopmentteamtoestimatethemwithaccuracyandbeabletodecomposethemintothetasksneededtodevelopthem.Itemswithlowerprioritycanremainhigh‐levelandlesspreciseuntiltheyriseintheorderandneedtobespecifiedinmoredetail.Largeitemsinthebacklogaresometimesreferredtoasepicsorbusinessvalueincrements,andmaybebrokendownintomultiple,moregranularitemsasthebacklogiselaboratedviastorydecomposition.Someaspectsofthestorymaybeimportantnear‐termandotherslessimportant.Thisabilitytobreakstoriesdowninthebackloghelpsprotecttherateofvaluedelivery.Forexample,addinganewfeaturemayhaveinvolvedhard‐codingsomethingupfrontandaddinganewstorytothebacklogtoaddsomedynamicconfigurationabilitytotheproductlater.
Estimation Accuracy
Itemswithhighorderinthebacklogneedtobeestimatedwithenoughaccuracytousethemforplanningreleases.Itemsinlowerorderalso
November2011DraftforPublicReview 71
Analyze to Determine What is Valuable Techniques
needtobeestimated,butwithlessaccuracysincetheyareoftenlessdetailed.Estimatesfortimetocompleteitemsisoftenmaintainwithinthebacklogitself.
Prioritization
Itemsinthebacklogareorderedrelativetoeachother.Orderingcanbeestablishedusingnumbering,valuepoints,high/medium/low,oranyotherprioritizationtechnique.Theorderofitemsonthebacklogislikelytochangeoverthecourseoftheproject,especiallyastheproductevolvesandtheteamreceivesfeedbackfromthestakeholdersandcustomers.Itisimportanttonotethatorderingneartermitemsisimportant,butputtingalotofeffortintoorderingthebacklogfarintothefuturecanbeawastefulactivitybecausethefartheroutbacklogitemsaresubjecttochange.
Managing Changes to the Product Backlog
Thebacklogisthemainmechanismforbothmanagingchangetotherequirementsonanagileprojectandforcontrollingscope.Whenneworchangedrequirementsareidentified,theyareaddedtothebacklogandorderedrelativetotheotheritems.Thebacklogisalsousedtotrackandmanagereporteddefectsorbugs.Orderingtheentirebacklogcanbedoneupfrontusingrelativeimportancedesignations(basedonbusinessvalue),whichallowshigh‐levelprioritizationwithouttoomuchgettingintotheweeds.Sincereleasesanditerationsaretime‐boxedonagileprojects,theitemsloweronthebacklogareoftennotincludedinagivenrelease.Rigorousorderingofthebacklogallowstheteamtocontrolthescopeoftheprojectandreleases.
Whenanitemisdevelopedandacceptedbytheproductowner,theitemisremovedfromthebacklogandmovedtoanotherdocumentsuchasthereleaseplanorsprintbacklog.Theproductownerroleisresponsibleformanagingthebacklog,addingandorderingneworchangeditems,removingcompleteditems,andrevisingtheorderonanongoingbasis.Thisprocessissometimesreferredtoaspruningorgroomingthebacklog.
.4 Usage Considerations
Advantages
• Sincetherequirementsonthebacklogareorderedinimportance,theteamknowsthatwhattheyareworkingonina
72 The Agile Extension to the BABOK® Guide
Techniques Analyze to Determine What is Valuable
giveniterationishighpriorityandwillcontributebusinessvaluetotheproduct.Thepersonontheteamresponsiblefordetailingtherequirementscanreviewthebackloganddetermineiftheitemsthatwillbedevelopedinanupcomingreleaserequirefurtheranalysisinordertoreadythemfordevelopment.Thisprocessisreferredtoasbuildingtherequirementsrunway.
• Sinceeachreleasetypicallyimplementsasmallsetofrequirements,requirementsareanalyzedindetailonajust‐in‐timebasis.Whattheteamandthestakeholderslearnabouttherequirementsdevelopedduringareleasecaninformtheanalysisofotherrequirementsinupcomingiterations.
Disadvantages• Largebacklogsmaybecomecumbersomeanddifficultto
manage.Breakingtheoverallproductbacklogintobacklogsforreleases(calledreleasebacklogs)canhelpaddressthisdisadvantage.Also,alackofdetailinthestoriesinthebacklogcanresultinlostinformationovertime.
Timing
Thebacklogisdevelopedatthebeginningofanagileproject,butitdoesnotneedtobecompleteatthistimesinceitwillcontinuetoevolvethroughouttheproject.
4.1.2 Business Value Definition
Inorderforaprojecttodelivervalue,theymustfirstbeabletoidentifywhetherarequestisactuallyvaluabletotheorganization.Withoutaclearunderstandingofbusinessvalue,itispossiblefortheprojecttodeliversomethingthatsoundsvaluablebutisactuallynot.
Aprojectcreatesbusinessvaluewhenitdeliversanythingthatcontributestoanorganization'sstatedprimarygoals,forexample
• increasingorprotectingrevenue,• reducingoravoidingcosts,• improvingservice,• meetingregulatoryorsocialobligations,• implementingamarketingstrategy,and• developingstaff.
November2011DraftforPublicReview 73
Analyze to Determine What is Valuable Techniques
Oftenprojectscreateoptionsforthebusinesstoexploit.Forexample,theoptiontosell1000itemsofaproductaday.
Businessvalueshouldbeexpressedintheformofamodelratherthananabsoluteamount.Theevolutionofthebusinessvaluemodelwilldevelopunderstandingofwhytheprojectisneeded.Themostimportantaspectofdevelopingabusinessvaluemodelistheconversationthatgeneratesthesharedunderstanding,ratherthanthemodelandthenumbersthatthemodelproduces.
Examplesofbadbusinessvaluestatementsare:
• Thisenablesstraightthroughprocessing.• Thiswillmake1milliondollars.• Thiswillsave1milliondollars.• Mr.Bigneedsthisproduct.
Noneoftheseshowalignmentwiththegoalsoftheorganization.
Anexampleofagoodbusinessvaluestatementis:
Thisprojectwillgenerateanadditional$20millioninprofit.Themodelisbasedonthefollowingassumptions:
• Wemaintain25%ofthesalesofexistingproductXYZ($150millionayear).
• Thetotalcostofdesigning,producing,andmarketingtheproductis$7.5million.
• Ourproductisfirsttomarket.• Weareabletoreleasetheproductinthespring.
Thisstatement,inmodelform,conveysunderstandingofwhytheprojectisneededandwouldlikelypromotevaluableconversationthatgeneratesasharedunderstandingoftheproject.
4.1.3 Kano Analysis
.1 Purpose
Kanoanalysishelpsanagileteamunderstandwhichproductcharacteristicsorqualitieswillprovetobeasignificantdifferentiatorinthemarketplaceandhelptodrivecustomersatisfaction.
74 The Agile Extension to the BABOK® Guide
Techniques Analyze to Determine What is Valuable
.2 Description
Kanoanalysisismostusefulinhelpingtosupportagiledevelopmentforcommercialproducts.Itassistsinidentifyingfeaturesthatwillhavethegreatestimpactoncustomersatisfaction,eitherbecausetheyareexceptionallyimportantorbecausetheirabsencewillcauseintensedissatisfaction.Thishelpstheteamdeterminewhichfeaturesaremostimportanttoimplementbeforereleasingaproducttomarket.
Kanoanalysisratesproductcharacteristicsontwoaxes:
• theextenttowhichthefeatureisimplementedintheproduct,and
• thelevelofcustomersatisfactionthatwillresultfromanygivenimplementationlevel.
Theresultinggraphisplottedona2×2matrix.Basedontheresultingprofile,theproductcharacteristicshouldfallintooneofthreecategories:
• thresholdcharacteristics,• performancecharacteristics,and• excitementcharacteristics.
Thisanalysiscanthenbeusedtotryandidentifycharacteristicsthatwillgivetheproductauniquepositioninthemarketplace.
.3 Elements
Threshold Characteristics
Thresholdcharacteristicsarethosethatareabsolutelynecessaryforstakeholderstoconsideradoptingaproduct.Theirabsencewillcauseintensedissatisfactionbut,astheyrepresentminimumacceptancecriteria,theirpresencewillnotincreasecustomersatisfactionbeyondacertainlowlevel.Thechallengewithelicitingrequirementsforthesefeaturesisthatpeopleexpectthemtobepresentandsotendnottothinkaboutthemunlessexplicitlyasked.
Performance Characteristics
Performancecharacteristicsarethoseforwhichincreasesinthedeliveryofthecharacteristicproduceafairlylinearincreasein
November2011DraftforPublicReview 75
Analyze to Determine What is Valuable Techniques
satisfaction.Theyrepresentthefeaturesthatcustomersexpecttoseeinaproduct(speed,easeofuse,etc).Requirementsforthesetypesoffeaturesarelikelytomostreadilycometomindforthemajorityofstakeholders.
Excitement Characteristics
Excitementcharacteristicsarethosethatsignificantlyexceedcustomerexpectationsorrepresentthingsthatthecustomerdidnotrecognizewerepossible.Theirpresencewilldramaticallyincreasecustomersatisfactionovertime.Asthesecharacteristicsarenotmetbyanythingcurrentlyonthemarket,stakeholderswillnottendtothinkaboutrequirementsthatdescribethem.
.4 Usage Considerations
Inordertodeterminethecategorytowhichacharacteristicorfeaturebelongs,customerscanbesurveyedusingtwoformsofaquestionaboutthefeature:thefunctionalformandthedysfunctionalform.
Functionalform:Howdoyoufeelifthisfeatureorcharacteristicispresentintheproduct?
Dysfunctionalform:Howdoyoufeelifthisfeatureorcharacteristicisabsentintheproduct?
Possibleanswerstoeachquestionformare:
• Ilikeitthatway.• Iexpectittobethatway.• Iamneutral.• Icanlivewithitthatway.• Idislikeitthatway.
Determiningthecategoryisbasedonmappingtheanswerstobothformsofthequestiontothefollowinggrid.Thetoprowrepresentstheanswerstothedysfunctionalformofthequestion.Theleftcolumnrepresentstheanswerstothefunctionalformofthequestion.
76 The Agile Extension to the BABOK® Guide
Techniques Analyze to Determine What is Valuable
TABLE 4.5 Kano Analysis Questions Grid
E=Exciters
P=Performance
T=Threshold
I=Indifferent(Doesnotfitintooneofthe3categories)
QorR=QuestionableorReversed(theanswerdoesn'tmakesense)
Thisapproachismostapplicableforconsumerproductsorgoodsthatwillberesold,asitfocusesonidentifyingrequirementsthatwillencouragewidespreaduseoradoptionofaproduct.Thecategorizationofaparticularcharacteristictendstoshiftovertime,ascustomersgrowtoexpectfeaturesorcharacteristicstobepresentinaproduct.Exciterseventuallybecomeastandardexpectationandthresholdcharacteristic(thinkofthenoveltyofATMswhentheywerefirstintroduced,nowcustomersassumetheirbankwillhaveATMs).
4.1.4 MoSCoW Prioritization
.1 Purpose
Toidentifythemostcriticalsetoffeaturesorstoriesthatwilldeliverbusinessvalue.
.2 Description
MoSCoWisamethodtoprioritizestoriesinincrementalanditerativemethodsandisdescribedintheBABOK®Guide(6.1PrioritizeRequirements).MoSCoWprovidesawaytoreachacommonunderstandingonrelativeimportanceofdeliveringastory.Allstories
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
November2011DraftforPublicReview 77
Analyze to Determine What is Valuable Techniques
inthebacklogarevaluable,butoftennotallofthemcanbedeliveredatthesametime.MoSCoWprovidesamechanismforprioritizingstoriesinabacklogacrossmultiplereleases.Prioritizationisimportantforanysoftwaredevelopmentmethod,butagilemethodscannotsucceedwithoutconstantandfrequentprioritizationofwork.
MoSCoWgetsitsnamefromanacronymformedbythefollowingclassificationsofpriority:Musthave,Shouldhave,Couldhave,andWouldlike.Theletteroisaddedtomaketheacronympronounceable.Theclassificationsareasfollows:
• MustHave.Thesearestoriesthatmustbedeliveredforthecurrentbusinessproblemtobeaddressed.Mustcansarethoughtofasaminimalusablesubset.
• ShouldHave.Thesearestoriesthatarecriticaltothesuccessoftherelease.ShouldstoriesareasimportantasMuststoriesbutmaynotbetime‐criticalormayhaveaworkaround.
• CouldHave.Thesearestoriesthatlesscritical.• WouldLike.Thesestorieswilllikelynotbeincluded,butmight
eventually.
.3 Elements• ProductBacklog:Acollectionofuserstoriesdescribingthe
desiredfunctionalityofaproduct.• Strategy:Anunderstandingoftheoutcomesforaninitiative.• CustomerPreference:Clarityonwhatismostimportanttothe
customer.
.4 Usage Considerations
MoSCoWisusefulwhentryingtoprioritizeabacklog.Unlikesomeprioritizationmethods,thismodelhelpsdifferentiatebetweenasetofusefuluserstoriestothosespecificallyfocusedonanoutcome.
Advantages• MoSCoWiseasytodescribeandtypicallyispowerfulin
prioritizingbacklogs.
Disadvantages
• MoSCoWcanbesubjective.Ifthereisnoteffectivecollaborationwiththebusiness,thismethodofprioritizationcanbeinaccurate.
78 The Agile Extension to the BABOK® Guide
Techniques Analyze to Determine What is Valuable
• Onaprojectwhereabusinessvalueincrementsapproach(MinimumMarketableFeatures)isused,theteamshouldonlydeliverMustHavesintheincrement.MoSCoWisthereforeinappropriate.
4.1.5 Purpose Alignment Model
.1 Purpose
Thepurposealignmentmodelisusedtoassessideasinthecontextofcustomerandbusinessvalue.Fromanagileperspective,themodelaidsinmakingprioritizationdecisionsandfocusinginvestmentonthosefeaturesorcapabilitiesthatareofgreatestvaluetotheorganization.
.2 Description
Thepurposealignmentmodelisusedtorateactivities,processes,products,orcapabilitiesintwodimensions,andthenrecommendthebestactionstotaketoimprovethembasedonthoseratings.Thefirstdimensioniswhetherornottheactivitycreatesmarketdifferentiation,theseconddimensioniswhetherornottheactivityiscriticalforthecontinuedfunctioningoftheorganization.
Thefollowingillustrationisanexampleofanpurposealignmentmodel.
FIGURE 4.10 PurposeAlignmentModel
November2011DraftforPublicReview 79
Analyze to Determine What is Valuable Techniques
.3 Elements
Differentiating Quadrant
Features,products,orservicesthatbothservetodifferentiatetheorganizationinthemarketplaceandarecriticaltothefunctioningofthecompanyarepartofthedifferentiatingquadrant.Thesearethethingsinwhichtheorganizationshouldbepreparedtoinvesttooffersomethingthatisdistinctfromcompetitorofferings.Adifferentiatingactivityisonethatmightbeusedtoadvertisethecompany,thatisdifficultforcompetitorstomatch,orotherwisehassignificantstrategicvalue,andauniqueapproachtotheseactivitiesislikelytobeneeded.
Parity Quadrant
Thingswhicharemissioncritical,butnotmarketdifferentiating,fallintotheparityquadrant.Thatmeansthatitisusuallysufficienttobeoperatingonparwithotherfirmsinyourindustry.Manystandardfunctions,suchasfinance,HR,payroll,andothersfallintothisquadrantformostorganizations.Activitiesinthisquadrantareimportantbuttheywillnotprovideanadvantagetothefirminrelationtocompetitorsandsoadoptionofbestpracticesisgenerallysufficient.
Partner Quadrant
Activitiesthatmayhaveuniquevaluetocustomers,butwhicharenotcriticaltothefunctioningoftheorganization,fallintothepartnerquadrant.Eventhoughtheseactivitiesareimportanttocustomersorotherstakeholders,theorganizationdoesn’tneedtoperformthemtosurvive.Thatmeansthattheorganizationisunlikelytohavetheresourcestoexcelattheseactivities(asmoremission‐criticaloperationswilltakeprecedence),whileapartnermayperformthemmoreeffectively.
Who Cares? Quadrant
Finally,activitieswhichareneithermission‐criticalorhelptodifferentiatetheorganizationinthemarketplacefallintothewhocaresquadrant.Astheseactivitiesdonotaddcustomervalue,andtheorganizationcanfunctionwithoutperformingthem,theyareprimecandidatestobeeliminatedandtheresourcesreallocatedtosupportmoreusefulwork.
80 The Agile Extension to the BABOK® Guide
Techniques Get Real Using Examples
.4 Usage Considerations
Thepurposealignmentmodelisdesignedforusebyfor‐profitorganizationsthatfacecompetitioninthemarketplace.Governmentalorganizationsandno‐profitsmayfindthatmarketdifferentiationisnotasignificantdriverfortheirdecisions.Stakeholderormembervalue,oralignmentwiththeorganizationalmissionmayserveasanalternative.
Secondly,themodelprovidesguidanceonwhethersomethingshouldbeanareaofstrategicconcernbutdoesnotprovideanyguidanceonwhatstrategiesordecisionsmightbethecorrectones.
Advantages• Oneofthekeyadvantagesofthismodelisitssimplicity.Itcan
betaughttobusinesssponsorsandusersinacoupleofminutessothattheycancriticallyassessanideathemselvesratherthanthebusinessanalystdotheanalysisthatmaythenbechallenged.
• Themodeliseasytouseinafacilitatedcollaborativeenvironment.
• Itcanbeappliedallthewayupanddowntheinvestmentdecisionprocess.Fromstrategicinvestmentdowntoanindividualfeatureinasystem.
• Itisfastandentirebacklogcanbeanalyzedinlessthananhour.
Disadvantages• Itassumespositiveintentinthebusinessstrategy.Itdoesnot
incorporate“spoiler”behaviourbycorporations.
4.1 Get Real Using Examples
Inagilemethodologies,inordertoelicitandvalidateproductneedsbusinessanalysispractitionersuserealcustomerexamplestocommunicatewiththeteam,includingthecustomer.Realexamplesservetobridgeunderstandingofthecustomer'sbusinessandhowtheyseetheproductservingafuturestateneed.Analysismodelscanbeconcurrentlydevelopedandelaboratedusingthesesameexamples.Modelsmaybeusefulfortheteambutexamplesaremoreconcreteforthecustomer.Thetechniquesareusediterativelybyalternatingbetweenexamplesandanalysismodelstoexploremultiple
November2011DraftforPublicReview 81
Get Real Using Examples Techniques
dimensions(forexample,userrole,useractions,data,businessrules)ofaproductneed.Thisisacontinuouspracticethatbuildsasharedteamunderstandingofproductneedsusefulforbothplanninganddelivery.Thesetechniquesengagecustomersinrequirementselicitation,analysis,andvalidation.
Examplesandmodelsshouldbeatalevelofgranularitythatisappropriatefortheoutcomeyouseek.Whenplanningtheproduct,modelsareusedtosetcontextandhelptheteamandcustomeridentifyscope.Thesemodelsaremoreabstractandprovideabroadperspectiveoftheproblemdomain.Whendeliveringtheproduct,thesamemodelcanbeprogressivelyelaboratedandrelatedexamplesareelicitedandspecifiedtolaunchintoadeeperdiscussionofthedimensions.Theexamplescanbeusedtoderiveacceptancecriteria,helpthedeveloperdesignthesolution,andprovideafoundationforfunctionaltesting.
Thefollowingsectionsdescribecommonlyusedtechniques.
• Behaviour Driven Development
4.1.1 Behaviour Driven Development
.1 Purpose
Anapproachthatenhancesthecommunicationbetweenbusinessusersandthedevelopmentteam.
.2 Description
Traditionalbusinessanalysistechniquesofteninvolvecreatinganalysismodels,forexampleusingUMLmodels.Inadditiontoanalysismodels,agiletechniquesfavourcommunicationusingexampleswhicharemoreconcreteforthecustomer.Manypeopleareuncomfortablewithabstractionsandprefertoworkwithrealexamples.
Examplestendtobeadditiveandcanformaspecification.Theycanbeusedduringagileplanninganddeliverywork.Asmodelschange,examplescanberefinedbybuildingonpreviousexamples.Inagile,itishelpfultoiteratebetweenusingexamplesandanalysismodelsencouragingthemtofeedoffofeachother.Progressiveelaborationleadstoricherexplorationofmultipledimensions(forexample,userrole,useractions,data,businessrules)relatedtotheexample.
82 The Agile Extension to the BABOK® Guide
Techniques Get Real Using Examples
Supplementingproductneeddiscussionswithexamplescreatesamuchmorestablesetofrequirementsthanusingamodelalone.
Forexample,ratherthan“acompanywhichsupportsmultiplebrandsfordifferentdemographicsegments”,consider“DisneyCorporationwhichhasDisneyfilmsforfamilyentertainment,Miramaxformoreadultaudiences,andMarvelforsuperheropictures.”
Inaddition,examplesfeedsmoothlyintoabehaviour/testdrivendevelopmentapproach.
.3 Elements
Examples
Examplesmayalsobeknownasscenarios.Examplesshouldnotbeartificialormadeup.Theyshouldbereallifebusinessscenariosprovidedbythebusinessusers.Businessanalysisactivitieshelptofacilitatethediscoveryoftheexamplesandensurethatthesetofexamplesiscomprehensive.Notallexamplesidentifiedwillnecessarilybewithinthescopeofadevelopmenteffort.
Behaviour Driven Development
Behaviourdrivendevelopmentprovidesasimplegrammarformatthatallowsrealscenariostobefilledin.Thistakestheform
• GIVEN<acontext>• WHEN<anevent>• THEN<anoutcome>
Forexample,anATM
• GIVEN:I'mincredit• WHEN:Irequest$20• THEN:Ireceive$20• AND:myaccountbalanceisreducedby$20• AND:mycardisreturned• GIVEN:I'minoverdrawn• WHEN:Irequest$20• THEN:Ireceivenomoney• AND:mycardisreturned
November2011DraftforPublicReview 83
Understand What is Doable Techniques
Scenariosthatarewritteninabehaviourdrivendevelopmentformatspecifyingevents,conditions,andactionsareverifiable.Theycanserveasacceptancecriteriaforstories[see“StoryElaboration”onpage52]andserveastestsinsupportofAcceptanceTestDrivenDevelopment(ATDD)thatdriveacommonunderstandingofrequirementsandfutureproductneeds.
Testing
Therearenowanumberofsoftwareproductsthatwilltakeexamplesinthisformatandallowthemtobeeasilyconvertedintoautomatedtests,thusenablingmoreagiledelivery.Withacomprehensivesetofexamplesthatcanbeexecutedasautomatedtests,businessanalysisandtestingactivitiescanbemoretightlycoupled.
4.1 Understand What is Doable
Asanagileprojectteamplansfordelivery,itisimportanttothinkaboutwhatispragmaticanddoable.Theteammustbalancecapacityanddemandwhentheyestimatetheworktobedonetodelivertheproduct.Agileprojectteamscontinuallyreviewmeasures,suchasteamcapacity,priordeliverycyclecommitmentsandactuals,andvelocitytrendstoadjustcommitmentsonanon‐goingbasis.Thisenablestheteamquestionwhatcanbedeliveredgiventheirknowledgeofthework‐setandtosetappropriateexpectationsandmakebetterestimates.Understandingwhatisdoableoccursthroughoutanyagiledeliverycycle,suchasreleaseplanning,work‐aheadanalysis,orwheneverateamispullingnewbacklogitemsforconsiderationinaproductdeliverycycle.
Theentireteamusesthefollowingtechniquesasmethodstoidentifyandestimateunitsofworkthataredecomposedwithbusinessvalueinmind.
Thefollowingsectionsdescribecommonlyusedtechniques.
• Estimation• Planning Workshop• Real Options
84 The Agile Extension to the BABOK® Guide
Techniques Understand What is Doable
4.1.1 Estimation
.1 Purpose
Accurateestimationiscriticaltoanagileteam’sproductivity,reliability,andreputation.Bybeingabletodevelopaccurateestimatesofcost,time,andeffort,theagiledevelopmentteamhastheabilitytofaithfullycommittoaprojectorworkeffort.
Estimationisateamactivity,andbusinessanalysismakesanimportantcontributionbyhelpingtheteamtobetterunderstandthecomponents,characteristicsandcomplexityofthework.
Althoughestimatesarenotvisibleinthefinalproduct,theydoaddsignificantvaluetoanagileproject.Providingcredibleestimatesallowstheprojectteamto:
• determinecostandeffort,• establishtheprioritiesoftheproject,and• commitmenttoaschedule.
.2 Description
EstimationisdiscussedatlengthintheBABOK®Guide(9.10Estimation).Here,webuildontheinformationintheBABOK®Guideandsummarizetherelativeestimationtechniquesthatcanbeappliedintheagiledevelopmentenvironment.
Uniquetotheagileenvironment,estimatingisprogressiveandoccursinalignmentwithiterations.Nooneexpectsearlyestimatestobeasaccurateaslatterestimates.Improvementoccursovertimeastheteamsbuildconfidenceintheircapacityandcapabilities.
Inadditiontothebasicapproachofestimatingbasedonhistoricalknowledge,agileestimatorsfrequentlyapplyarelativeestimatingmodelinwhichteamsdevelopnarratives(stories)thatdefineuserneedsandbenefits.Thesestoriesareanalyzedbytheteamandnumericvaluesareappliedtoeachstory(storypoints).Storypointscanbeabstractmeasurementsthatprovideanumericvaluetoastory,orstorypointscanbedescribedasidealdeveloperdays(IDDs).
Astorypointisanumberassignedtoeachstorythatdefinestheestimatedeffortateamwillhavetoapplytothestory.Storypointsare
November2011DraftforPublicReview 85
Understand What is Doable Techniques
usuallybasedonwhattheteamknowsaboutthestoryinfourkeyareas:
• Knowledge:Howmuchinformationdoestheteamhave?• Complexity:Howdifficultistheimplementationlikelytobe?• Volume:Howbigisthestory?Howlongwillittake?• Uncertainty:Whatvariablesandunknownfactorsmightimpact
thestory?
Thetotalnumberofstorypointswithinanygiveniterationisconsideredtobetheteam’svelocity,orhowmuchateamcanaccomplishwithintheiteration.Afterseveraliterationsteamswillhaveabetterunderstandingoftheiractualvelocity.Thiswillallowthemtomakebetterinformedestimatesandcommitmentsinsubsequentiterations.
Thereareseveralwaystogetstartedwithstorypointestimation.Theagileestimatorcanbeginwith
• aWAG(wideangleguess),• agivensetofresourcesandafixediteration,or• anestimationofthetimerequiredforasinglestorypoint,and
thenextrapolatefromtheirtoestimatetheworkthatcanbedoneinaniteration.
.3 Usage Consideration
Advantages• Relativeestimationisasimple,reliablemethodologythatfits
wellwithagilepractices.Itishighlyadaptiveandislikelytobecomeincreasinglyaccuratethroughoutsuccessiveiterations.
• Theplanningpokertechniqueisahighlycollaborativeprocessthatisbasedonconsensusandwilllikelyhaveapositiveimpactondevelopmentteams.Itbuildsuponthewisecounselto“asktheteam.”
Disadvantages• Relativeestimatesarebasedonhistoricaldataandaccuracyis
dependentuponthesimilarityofnewstoriestostoriespreviouslydelivered.Ifnewstoriesdifferradicallyfrompreviousstories,itispossiblethattheaccuracyoftheestimatemaydecrease.
86 The Agile Extension to the BABOK® Guide
Techniques Understand What is Doable
• Theaccuracyofvelocityisdependentontheknowledgeandexperienceofthedevelopmentteam.Anychangestoteamcompositionwillimpactvelocityandthereforeestimates.
4.1.2 Planning Workshop
.1 Purpose
Toenabletheteamtodeterminewhatworktoperformduringaniterationortodeliveraminimummarketablefeature(MMF).
.2 Description
Aplanningworkshopisexecutedwhentheteamneedstoarriveatacommitmenttosomesetoffunctionalitythattheyfeelreasonablyconfidenttheycancompleteinthenearfuture.Inmostagilemethods,thisisperformedatthebeginningofeachiteration,butmayalsooccurwhenevertheteamisneartocompletingtheirbacklogofworkorthatbacklogneedstobeordered.InKanban,theamountofworkbeingperformedbytheteamislimitedbyrestrictingthenumberofworkitemsthatcanbeinanyworkflowstate,notbasedoniterations.Businessanalystscanprovidevaluetotheteambyhelpingtounderstandandfocusontheiterationobjectives,thevalueassociatedwithaparticularMMF,businessissues,storydecomposition,andbringingtheteamtogethertodeliveranacceptableoutcome.Priortotheworkshop,thereisusuallyapre‐planningstagethatinvolvesanalysistogetareasonablegaugeofthesize,scope,andcomplexityofeachbacklogitemthatwillbebroughttotheiterationplanningworkshop.
Inagiledevelopment,planningworkshopsneedtobeperformedonafrequentandregularbasis,astheorderinwhichworkismeanttobeperformedisregularlyalteredandupdated.Thisallowstheteamandcustomerstochangetheprioritiesofoutstandingworktoincorporatefeedbackorchangingbusinessneeds.
.3 Elements
Estimated and Ordered Product Backlog
Typicallybasedonuserstories,itisthemaininputfortheplanningmeeting.
November2011DraftforPublicReview 87
Understand What is Doable Techniques
Team Velocity
Priorvelocity(throughputcapacityofbacklogitems)iscriticaltoenablingtheteamtoschedulearealisticamountofwork.WhenusingKanban,work‐in‐progress(WIP)limitswillbeusedtomanagethisworkloadinstead.
Iteration Goal or MMF Set
Manyteamssetanoverallgoalfortheiterationtohelpguidetheselectionoffeatures.Thisisasubsetofthereleasegoal.Itisanobjectivethatwillbemetthroughtheimplementationoftheproductbacklog.
Requirement Selection
Atthebeginningofthemeeting,basedonbusinessvalue,iterationgoal,andteamvelocity,thehighestpriorityfeaturesaretypicallyselectedfromthereleaseplanbytheproductowner,productchampion,oracustomergivendecisionmakingauthority.
Non-Feature Selection
Thebacklogcanalsobecomposedbynon‐featureitems(elementsnotrelatedtoaproductincrement)identifiedasnecessarytoachievetheiterationgoalordeliveranMMF.Forexample,therecanbebugstobefixed,systemorenvironmentsetup,researchinitiatives,managementworkitems,oranyotheractivitythataddvaluetotheproject.
Task Planning
Theteamwillbreakthefeatureandnon‐featureitemsdownintotasks.Taskstypicallyrangeinsizefrom4hoursto2days,withmosttaskscapableofbeingdeliveredwithinaday.Taskseffortcanbeestimatedinhoursforfurtherstatisticalcontrol.
.4 Usage Considerations
Advantages• Customer,productowner,anddevelopmentteamcan
communicateandcollaboratefrequentlyaboutproductvisionandevolution.
88 The Agile Extension to the BABOK® Guide
Techniques Understand What is Doable
• Customerandproductownercanguidetheprojectnotjustatthestartbutdaybyday.
• It’seasiertounderstand,estimate,andplanthescopeofsmalliterationsinsteadofthescopeofbigreleases.
• Planscanbechangedinadvancebasedonfeedbackfromincrementaldeliveryofworkingsoftware.
• Iterationplanningcanguaranteevisibilityofthewholeprojectandsynchronizationbetweenmultipleteams.
Disadvantages• Itisnecessarytogetallpeopletogetherinordertoavoid
interruptionsandrework,especiallywhenworkingwithdistributedorconcurrentteams.
• Ifthewholeprojectisnotwellunderstoodduringtheiterationplanningworkshop,it’spossibletoresultinasuboptimalplan.
• Someapproachesconsideranalysis,design,andplanningsomeactivitiestobeexecutediniterationplanningworkshops,whichcanbeverytimeconsumingforlongiterations(3or4weeks),generatingcomplaintsfromteammemberseveniftheeventisproductive.
4.1.3 Real Options
.1 Purpose
Anapproachtohelppeopleknowwhentomakedecisionsratherthanhow.Theapproachhelpsyouunderstandwhetheryouhaveacommitmentoranoption.
.2 Description
Thecoreconceptbehindrealoptionsisthatyoushoulddelaymakingadecisionoracommitmentinaprojectuntilthelastresponsiblemoment,whenthedecisionreallyneedstobemade.Therealoptionapproachhasthreesimplerules:
• optionshavevalue,• optionsexpire,and• nevercommitearlyunlessyouknowwhy.
Thefirstandthirdruletellyoutoavoidcommitmentsandkeepyouroptionsopen.Thesecondruletellsyoutounderstandwhenanoption
November2011DraftforPublicReview 89
Understand What is Doable Techniques
expiressothatyoucanactivelymanagewhetheryouchosethatoptionorletitlapse.Asthereisvalueinoptions,youshouldseektoextendthematurityoftheoptions.
Realoptionsaddresspeople'saversiontouncertaintybyprovidingtheconditionswhenacommitmentshouldbemade(theoptionexpiry)ratherthansimplysuggestingthattheywait.
Themostcommonusageofrealoptionswithinagileprojectsisthewayinwhichbusinessinvestorschosewhichitemtoinvestinnext.Traditionally,investorswouldprioritizetheirrequirementsforanextendedperiodoftime.Withrealoptions,theywouldonlyprioritizeuntilthenextinvestmentdecisionpoint.OnScrumprojectsthiswouldbethenextsprintplanningsession.InKanban,itwouldbethenexttimecapacitybecomesavailabletoworkonsomethingnew.
Realoptionssupportagilebusinessanalysisbyallowingustoreducethenumberofdecisionswehavetoconsideratanyonetime.
.3 Elements
Options and Commitments• Realoptionsforcesyoutoidentifywhetheryouhaveoptionsor
not,andalsoforcesyoutoidentifythecommitmentsyouaremaking.
• Therealoptionsmaterialtendstofocusonnon‐ITprojectrelatedexamples,tohelppeopleidentifytheminageneralsenseratherthanspecifyalistofcommonoptionswhicharelearnedbyrote.
Examplesofoptionsinclude:
• Ahotelreservation.Anoptiontostayatthehotel.Theoptionnormallyexpiresat6p.m.onthedayofthestayatwhichpointyouarecommittedtopayingforthehotelroom.
• Atickettoaconference,sportingevent,rockconcertortheatre.Theoptiontoattendtheeventexpiresattheendoftheevent,orsometimesearlier.
• Atravelcard.Theoptiontotravelonpublictransport.TheoptionexpiresinLondonataboutmidnight.
• Abusinesscard.Theoptiontocontactthepersonwhogivesyouthecard.Theoptionexpireswhenthepersonchangescontactdetails.
90 The Agile Extension to the BABOK® Guide
Techniques Understand What is Doable
Optionsarethingsyoucanchosetodoornotdo.Ifyouarecommittedtodoingsomethingandthereisonlyoneway,thenyoudonothaveoptions.
Someexamplesofcommitmentsinclude:
• Oftenthereisapenaltyassociatedwithfailingtomeetacommitment.
• Payingyourtaxes.Failuretomeetthiscommitmentmayresultinfinesorworse.
• Turninguptoworkontime.Failuretomeetthiscommitmentmayresultinterminationofyourcontractofemployment.
• Deliveringitemsyouhavecommittedtodelivertootherpeople.Failuretomeetthiscommitmentwillleadtoabadreputationandmayleadtoalawsuit.
Examplesofthingsthatarenotoptions.
• Thingsyoucannotdo.• Thingsyoucannotafford.• Thingsyoucannotdointime.• Thingsyoucannotbuyorsell.• Thingsyoudonothavethetoolsfor.
Options Expiry
Realoptionsforcesustounderstandwhenouroptionsexpireorwhenwenolongerhaveachoice.Wehaveanoptionuptotheexpirydatebutnotafterit.Infinancialoptions,theexpirydateoftheoptionisexplicitlystatedasaseriesofdate/times.Inrealoptions,theexpirydateisconditional.
Determinationofwhenanoptionexpiresisthemostimportantaspectofrealoptions.Withoutthisknowledge,youareblindinyourdecisionprocess.Youeithermakedecisionstosoonortoolateandyoudonotknowwhich.
Example
Youhavethechoicetoattendasportingeventat7p.m.
• Theoptiontoattenddependsonwhereyouare.Imagineyouareathomewhichis1houraway,thenyouroptiontoattendexpiresat6pm.Ifyouleaveafter6p.m.,youwillbelate.
November2011DraftforPublicReview 91
Understand What is Doable Techniques
• Imagineyouareatworkwhichis2hoursaway,thenyouroptiontoattendexpiresat5p.m.Ifyouleaveafter5p.m.,youwillbelate.
Asoptionshavevalue,pushingtheexpirydatebackaddsvaluetoyourprojectandallowsyoumoreflexibility.
Right / Wrong / Uncertain
Arationaldecisionprocesswouldorderourpreferenceasbeingright,thenuncertain,andfinallywrong.Observingpeople'sbehaviourthoughtheirpreferenceisright,wrong,andthenuncertain.
Ifyouasksomeonetomakeadecisionlaterortonottomakethedecisionnow,theyarefacedwithunboundeduncertaintyandasaresulttheyarelikelytomakeadecisionbasedontheinformationtheyhavenow.Thisemotionalcommitmentthenmakesithardertochangethedecisionasfurtherinformationarrives.
Realoptionssuggestsusingboundeduncertainty.“Makethedecisionwhen...”Specifytheconditionswhenthedecisionshouldbemade.
Specifyingtheconditionswhenacommitmentshouldbemadeallowsthedecisionprocesstobemanaged.Aseniormanagercanasktheirassistanttomonitortheconditionsonhisbehalf.
Anotherexampleofthisisthecheckoutatsupermarkets.Whendotheyopenanothercheckout?At6p.m.?At7p.m.?Theyopenacheckoutwhenthreepeoplearewaitinginthequeue.Theythenpublishthefactsothattheircustomerscanmanagetheprocessforthem.Theyreactwhencustomer'scomplainaboutthelengthofthequeueandopenupanothertill.Whenqueuelevelsdrop,theyclosetillsagainandredeploystafftoreplenishingtheshelves.
Feature Injection
Featureinjectionisacollectionoftraditionalbusinessanalysistechniquesthathavebeencombinedtoallowabusinessanalysttoperformanalysisinafastandeffectivemanner.Thisspeedthenallowsinvestmentcommitmentstobedeferredbecauseitreducethelengthoftimethatanalysistakes.
Thespeedoftheprocessisduetofollowingtherealoptionprocess.Theanalysisstartswiththeoutputandthenworksbackthroughthe
92 The Agile Extension to the BABOK® Guide
Techniques Stimulate Collaboration & Continuous Improvement
processtotheinputs.Itthenconsidershowdifferentexamplesaffecttheprocess.
Thethreestepsoftheprocessare
1.Identifythebusinessvaluewhichspecifiestheoutputs/outcomesrequiredfromthesystem/process.
2.Injectthefeaturesthatworkoutwhichprocessesandinputsarerequiredtoproducetheoutputs/outcomes.
3.Breakthemodelwhichusemodelsidentifiesalltheexamplesthatproduceadifferentbehaviourinthesystem/process.
.4 Usage Considerations
Advantages• Realoptionssimplifydecisionmakingbyprovidingasimpleset
ofprinciplestofollow.• Realoptionsmakedecisionmakingfastasyouonlyfocusonthe
immediatedecisionsanddeferprioritizationuntilalaterdatewhencomplexityisresolved.
• Realoptionsdonottellyouhowtomakedecisions,justwhenwhichmakesthembroadlyapplicableasanapproach.
• Realoptionshelpusoptimizeprocessbyforcingustoconsiderthedecisionpointsandtheinformationarrivalprocess(whendataarrivesandwhetheritarrivesbeforethedecision).
Disadvantages• Realoptionscanbecounter‐intuitiveastheyrequireusto
analyzesystemsfromtheoutputstotheinputs.• Realoptionsarenotasimpleprocesstobefollowedbyrote.
Theyareathinkingtoolthatrequirespracticeandstudy.
4.1 Stimulate Collaboration & Continuous Improvement
Agilepracticesemphasizetheimportantofcontinualcollaborationbetweenmembersoftheprojectcommunity.Weactivelycreateanenvironmentwhereallprojectstakeholderscancontributetotheoverallprojectvalue,ideallyinfacetofacefacilitatedworkshops.The
November2011DraftforPublicReview 93
Stimulate Collaboration & Continuous Improvement Techniques
realityformanyprojectsisthattheyaredistributedintermsofteam,timeandgeography.Facilitationskills,inconjunctionwiththetechniquesoutlinedinthissection,enablescollaborationforbothlocalanddistributedteams.Thetechniquesinthissectionentailworkingtogetheringroupstocreateasharedunderstanding.Thiscollaborativepointofviewpervadesanagileproject,andisnotlimitedtoanyspecifictechnique.
Oneofthefundamentalprinciplesofallagilemethodsistheneedforcontinuousimprovement,notjustoftheproductunderdevelopmentbutoftheprocessusedbytheteamtodelivertheproduct.Thisisachievedthroughbothstructuredandunstructuredfeedbackonacontinuousbasis.Forexample,theretrospectiveisanopportunityfortheteamtoexaminetheirprocessesandproducttoidentifyopportunitiesforimprovement.Healthycollaborativeteamshavethetrustandsafetynecessarytotransparentlyidentifyopportunitiesforimprovement.
Thefollowingsectionsdescribecommonlyusedtechniques.
• Collaborative Games• Retrospectives
4.1.1 Collaborative Games
.1 Purpose
Collaborativegamesarenotusedstrictlybyagileteams,althoughtheyareprevalentinagilepracticesbecausetheyemphasizetheconceptsofteamworkandcollaboration,whicharehighlyvaluedbyagilepractices.Collaborativegameshelpagroupofpeoplepromoteacommonunderstanding,gaininsightintoaproblem,orinspirenewideasaboutsolvingaproblem.
.2 Description
Collaborativegamesrefertomanydistinctstructuredtechniques,whichincluderulestokeepparticipantsfocusedonaspecificobjective.Thegamesareusedtohelptheparticipantssharetheirknowledgeandexperienceonagiventopic,identifyhiddenassumptions,andexplorethatknowledgeinwaysthatmaynotoccurduringthecourseofnormalinteractions.Thesharedexperienceofthecollaborativegameencouragespeoplewithdifferentperspectivesona
94 The Agile Extension to the BABOK® Guide
Techniques Stimulate Collaboration & Continuous Improvement
topictoworktogethertobetterunderstandanissueanddevelopasharedmodeloftheproblemorofpotentialsolutions.
Collaborativegamesoftenbenefitfromtheinvolvementofaneutralfacilitatorwhohelpstheparticipantsunderstandtherulesofthegameandhelpstoenforcethem.Thefacilitator'sjobistokeepthegamemovingforwardandtohelpensurethatallparticipantsplayarole.
Collaborativegamesalsousuallyinvolveastrongvisualortactileelement.Activitieslikemovingstickynotes,scribblingonwhiteboards,assemblingthings,ordrawingpictureshelpovercomeinhibitions,fostercreativethinking,andthinklaterally.
.3 Elements
Purpose
Gamesalwayshavesomedefinedpurpose,typicallytodevelopabetterunderstandingofaproblemortostimulatecreativesolutions.Theparticipantsinthegameneedtounderstandthatpurpose,andthefacilitatorwillhelpkeepthemmovingtowardit.
Process
Gamesalsohaveaprocessorrulesthattheyfollowtokeepthegamemovingtowarditsgoal.Often,eachstepinthegameistimelimited.Gamestypicallyhaveatleastthreesteps:
1.anopeningstep,wheretheparticipantsgetinvolved,learntherulesofthegame,andstartgeneratingideas,
2.theexplorationstep,whereparticipantsengagewithoneanotherandlookforconnectionsbetweentheirideas,testthoseideas,andexperimentwithnewones,and
3.aclosingstep,wheretheideasareassessedandparticipantsworkoutwhichideasarelikelytobethemostusefulandproductive.
Outcome
Finally,attheendofacollaborativegame,thefacilitatorandparticipantswillworkthroughtheresultsofthegameanddetermineanydecisionsoractionsthatneedtobetakenasaresultofwhattheparticipantshavelearned.
November2011DraftforPublicReview 95
Stimulate Collaboration & Continuous Improvement Techniques
.4 Usage Considerations
Itisnotpracticaltoelaborateonthemanycollaborativegamingtechniquesandtheirusageconsiderationsinthisdocumentbutthefollowingexamplesmayprovideastartingpoint.
Thefollowingchartprovidessomeexamplesofcollaborativegames.
TABLE 4.6 Examples of Collaborative Games
4.1.2 Retrospectives
.1 Purpose
Themostsingularobjectiveofaretrospectivemeetingisforateamtocometogetherinordertoreflectonwhatithasdonewell,whatitcoulddobetter,andtoreachagreementonhowanyimprovementswillberealized.Uniquetotheagileenvironment,retrospectivesareheldattheendofeachiterationsothatlearningscanbequicklyembeddedintheprocessesandpracticesgoingforwardforremainderoftheproject.
.2 Description
Theretrospectiveprovidesanopportunityforallmembersoftheteamtoreflectonthemostrecentdeliveries.Theretrospectiveshouldincludethewholeteamespeciallybusinessstakeholdersandusers.Itiscommonfortheretrospectivetobesplitintotwoparts.Thefirstpartinvolvingthewholeteamandthesecondparttodiscusstechnicalaspectsoftheprojectthatonlyaffectpartoftheteam.
Theretrospectiveshouldbefocusedonidentifyingissueswiththeprocess.Itshouldidentifyprocessimprovements,andnotbepersonal
Game Description Objective Product 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.
96 The Agile Extension to the BABOK® Guide
Techniques Stimulate Collaboration & Continuous Improvement
inanysense.Akeyelementofaretrospectiveisthattheteamfeelsafetodiscussanyissuethatconcernsthem.
Ideally,retrospectivesshouldbefacilitatedbyanneutralfacilitatorratherthanbyamemberoftheteam.
.3 Elements
Preparation
Theteampreparesideasfromtherecentiterationthatmaybeanalyzedintheretrospective.
Safety Check
Theteammustagree,together,totrusteachotherandtobelievethateverycommentorsuggestionisintendedforthesolepurposeofimprovingtheteam'sperformance.
Identify the Issues
Therearemanymechanismstoidentifyissuestodiscuss.Oneofthemostcommonisforallteammemberstowriteupthingsthatwentwell,thingstoimprove,andthingsofinterestonpost‐itnotes.Colourcodingthenotesandapplyingthemtoavisualtime‐lineassistinaddingunderstandingtotheemergingpicture.
Choosing Future Actions.
Oncealltheideashavebeendiscussedtothesatisfactionoftheteam,thefacilitatoraskstheteamtodecidewhichsolutions/improvementstheywanttofocusonnext.Theteamthenidentifieswhichimprovementswillbeaddressedandassignsresponsibilitytoanindividualteammemberwhoensuresthesolution/improvementisimplemented.
.4 Usage Considerations
Advantages• Anexcellentwayfortheteamtofindacollectivevoicearound
opportunitiesforteamimprovement.
November2011DraftforPublicReview 97
Avoid Waste Techniques
Disadvantages• Teammembersmayfeelobligedtopretendthattheytrusteach
other,eventhoughtheydonot.• Retrospectivesareonlyofvalueiftheteamactsuponthe
learninginthesessiontoimprovetheprocess.• Mostideasraisedintheretrospectiveareknowtoatleastone
memberoftheteam.Amatureteamshouldbeaddressingissuesastheyarriveratherthanbatchingthemuptobehandledinaretrospective.
4.1 Avoid Waste
Agilemethodsemphasizethedeliveryofworkingsoftwaretothecustomer.Businessanalysisworkaddsvaluebyensuringthattheneedsofthecustomerareunderstoodandthattheteamdeliverswhatthecustomerreallyneeded.Anyactivitythatdoesnotcontributedirectlytothisgoal,orthatthecustomerwouldnotbewillingtopayfor,iswaste.
Wasteeliminationisanissuethathasbeentreatedwithgreatemphasisbytheagilecommunity.Itisamind‐setoriginatedfromLeanasthemosteffectivewaytoincreasetheprofitabilityofanybusiness.Leanthinkingconsidersavaluestreamhashavingtwocomponents.Valueaddedactivitiesandmuda(theJapanesewordforwaste).Theaimofleanthinkingistoremovethemuda,orwaste,fromthevaluestream.Wasteisfurthersub‐dividedintotwocomponents.Thoseactivitiesthathavevaluebutdonotcontributetothefinalproductdirectlylikeanarchitectsplanandthoseactivitiesthatdonotaddvalueatall.Theaimistoremovecompletelythoseactivitiesthatdoaddvalueatall,andminimizethoseactivitiesthatdonotcontributetothefinalproductdirectly.Youcanstartavoidingwasteinbusinessanalysisbydevelopingandkeepingdocumentationlightweight.
Thefollowingprinciplesarehelpfulwhenworkingtoidentifywasteinanybusinessanalysisprocess:
• Avoidproducingdocumentationbeforesomebodyelseneedsit.• Whenevervalueisnotbeingdeliveredtoyourcustomers,the
wasteofwaitingoccurs.Don'tletothersbewaitingforyourjob.• Transportinginformationbetweendifferentmediatypesisa
costincursionwhichaddsnovaluetotheproductdevelopment.
98 The Agile Extension to the BABOK® Guide
Techniques Avoid Waste
Trytoelicit,analyze,specify,andvalidaterequirementswiththesamemodels.
• Analysismodelsshouldbeassimpleaspossible.Donotincludeinformationthatisnotdirectlyusefultoastakeholder.
• Work‐in‐progress(WIP),orinventory,isadirectresultofoverproductionandwaiting.Theytendtohideproblemsontheprocess.Ifyouseeit,trytoletthemflowovertheprocessoreliminateit.
• Workclosetothecustomersanddevelopmentteambecauseunnecessarymotionorwork‐a‐roundstosubstituteface‐to‐faceconversationsarealsowaste.
• Keepcontinuousattentiontoyourtechnicalexcellence.Qualitydefects(suchasunclearrequirements)resultinreworkandaretheworstwasteintheprocess.
Thefollowingsectionsdescribecommonlyusedtechniques.
• Lightweight Documentation
4.1.1 Lightweight Documentation
.1 Purpose
Ensurethatalldocumentationproducedthroughbusinessanalysisisintendedtofulfillanimmediateneed,hasclearvalueforstakeholders,anddoesnotcreateunnecessaryoverhead.
.2 Description
Lightweightdocumentationisaprinciplethatgovernsalldocumentationproducedinanagileproject.Thebusinessanalystshouldaimtoproduceaslittledocumentationaspossible,allofwhichshouldbeofvalue.Intraditionaldevelopmentlife‐cycles,documentationmaybeusedbydeveloperstocreatesoftwarealongtimeafteritsinitialcreation.Inagilemethodologies,thesoftwareisconstructedwithindaysoftheteamagreeingtodeliverasetofrequirements,andsodoesnotneedtoincludeinformationthattheteamcanrememberoragreetoduringtheconstructionprocess.
Traditionally,functionalspecificationsincludeallinformationthatthebusinessanalystknowsaboutthedomainproblem.Thespecificationmaycontainextensivedescriptionofthecontextinwhichtheprojecttakesplace,andmayattempttotrainthedeveloperinallaspectsofthe
November2011DraftforPublicReview 99
Avoid Waste Techniques
domain.Thetransferofknowledgeistakenoutofthespecificationandismademoreeffectivethroughfacetofaceconversationsorothercommunicationmethods.
Thecontextplaysanimportantfactorintheamountofdocumentationrequired.Someprojectsaremandatedtoproducedocumentationbyexternalentities(forexample,regulators).Documentationmayalsobeneededtoprovidealong‐termrecordofdecisionsreachedbytheteamorfunctionsimplementedintheapplication.However,thisdocumentationcanbewrittenafterthesoftwareisdeveloped,whichensuresthatitactuallymatcheswhattheteamdelivered.
Ageneralprinciplewithagileisthatifadocumentisvaluableenoughtobecreated,itisprobablyimportantenoughtobeautomatedsothatitispartofthelivingcodebase.Thishasleadtotheriseofautomatedacceptancetestingandbehaviourdrivendevelopmentthatallowsbusinessanalyststoworkwithqualityassuranceprofessionalstocreateexecutablespecificationintheformofexamples.
ThisprinciplecomesdirectlyfromtheAgileManifestowhichsays“Workingsoftwareoverextensivedocumentation”.Itisoftenmisinterpretedasmeaningnodocumentation.Instead,documentationshouldbebarelysufficienttomeettheneedsoftheteam.
Theagileprinciplehaselevatedthevalueofdocumentationthatisproducedbythebusinessanalyst.Thedocumentationproducedbythebusinessanalystshouldideallybeautomatedintheformofautomatedtestsorexamples.
.3 Usage Considerations
Advantages• Reduceamountoftimespentwritingdocumentation.• Reduceeffortspentreadingandreviewingdocumentation.• Reducenumberofdraftsofdocuments.• Allreviewerscanfocusonkeyissuesratherthanextraneous
details.• Training(knowledgetransfer)isdonetosuiteachperson
ratherthanusingthedocumentation.• Thedocumentationlivesintheformofautomatedexamples.
100 The Agile Extension to the BABOK® Guide
Techniques Avoid Waste
Disadvantages• Producinglightweightdocumentationmaycauseconflictwith
groupswhoenforcecorporateprocessstandards.• Somemaymisunderstandtheprincipleasmeaningno
documentation.• Someproducedocumentationthatisnotsufficientforan
externalentity.
November2011DraftforPublicReview 101
Avoid Waste Techniques
102 The Agile Extension to the BABOK® Guide
appendix A Glossary
Acceptance Criteria Requirementsthatmustbemetinorderfor a solution to be consideredacceptabletokeystakeholders.
Acceptance Test Driven Development (ATDD) ATDD is a TDD instance that involveswritingoneormoretests(or“customertests”) for a customer‐centric feature,beforethesolutionhasbeendeveloped.
Acceptance Testing SeeUserAcceptanceTest.
Agile Agilereferstoagroupofprinciplesandpractices that promote a disciplinedproject management process thatencourages frequent inspection andadaptation,aleadershipphilosophythatencouragesteamwork,self‐organizationandaccountability, a set of engineeringpractices intended to allow for rapiddeliveryofhigh‐quality software,andabusiness approach that alignsdevelopment with customer needs andcompanygoals.AlsoseeAgileManifesto,AgileSoftwareDevelopment.
Agile Manifesto TheAgileManifestoisastatementoftheprinciples thatunderpinAgileSoftwareDevelopment. It was drafted fromFebruary11ththrough13th,2001.
Agile Retrospective Retrospectivesareavariationofprojectretrospectives whereby theretrospectiveworkshopisconductedatregular intervals throughout thedelivery process, such as after eachiterationand/orrelease.
Agile Software Development Agile software development refers to agroup of software developmentmethodologies based on iterative andincremental development, whererequirements and solutions evolvethrough collaboration between self‐organizingcross‐functionalteams.
Anti-patternA commonly used, yet ineffective,processorpractice.
Backlog SeeProductBacklog.
Backlog Item An element that belongs to a productbacklog. It canbea feature,abug fix,adocument,oranyotherkindofartifact.
Behavior Driven Development (BDD) An approach that enhances thecommunicationbetweenbusinessusersandthedevelopmentteambyusingrealexamples.
November2011DraftforPublicReview 103
Glossary
Burndown Chart Used to track thework remaining overtime.Work remaining is theY axis andtime is the X axis. Thework remainingshould jig up anddown and eventuallytrenddownward.AlsoseeReleaseBurndownChart.
Business Value In management, business value is aninformaltermthatincludesall formsofvalue that determine the health andwell‐beingofthefirminthelong‐run.Inagile development, business value isrelatedtoalldeliverablesthatincrease/protect revenue or reduce/avoid costsinabusiness.
CeremoniesControlled processes and documentsthat constitute events and outputs inanygivenmethodology.Ahighdegreeofceremony frequently implies a highdegreeofcontrolandtraceability.Basedon the just‐in‐time and just‐enoughmodel, agile projects generally have alower degree of ceremony. Agileceremonies include iteration planning,dailymeetings,andretrospectives.
Change Driven Methodology A software development approach thatrefers to a group of principles andpractices that promote a disciplinedproject management process thatencourages frequent inspection andadaptation,aleadershipphilosophythatencouragesteamwork,self‐organizationandaccountability, a set of engineeringbest practices intended to allow forrapid delivery of high‐quality software,and a business approach that alignsdevelopment with customer needs andcompanygoals.
Class-Responsibility-Collaboration (CRC) Cards Abrainstormingtoolusedinthedesignofobject‐orientedsoftware.
Daily Burndown SeeBurndownChart.
Daily Meeting Oneachdayofasprint, theteamholdsdailymeetings. Ideally they are held inthemorningastheyhelpsetthecontextfor the coming day's work. The dailyscrum isnotusedasaproblem‐solvingor issue resolutionmeeting. Issues thatare raisedare takenofflineandusuallydealt with by the relevant sub‐groupimmediatelyafterthedailyscrum.
Daily Scrum Meeting SeeDailyMeeting.
Daily Standup SeeDailyMeeting.
Elicitation An activity within requirementsdevelopment that identifies sources forrequirements and then uses elicitationtechniques (for example, interviews,prototypes, facilitated workshops,documentation studies) to gatherrequirements from thosesources.
Enterprise Analysis Describes how business analystsidentifyabusinessneed,refine and clarify the definition of thatneed, and define a solution scope thatcan feasibly be implemented by thebusiness.Thisknowledgeareadescribes
104 The Agile Extension to the BABOK® Guide
Glossary
problem definition and analysis,business case development, feasibilitystudies, and the definition of solutionscope.
Epic A piece of functionality that enables auser to achieve a clearly identifiedbusinessobjective.OftenEpicsareatthelevelofElementaryBusinessProcesses‐‐‐a piece of work undertaken by oneperson, at one time, in one place thatdelivers on a specific operationalobjective.
Feature Injection An analysis technique based on realoptionsandKolb’smodelof learning.Itcan be used to efficiently identify thebusinessvalue, and thendetermine theminimum set of features necessary todeliverthatvalue.
Iteration Burndown SeeProductBurndownChart.
Just-in-time Requirements Requirements that define only what isneeded for the current iteration andonly to the level of detail required fortheteamtodelivertheitem.
Lean DevelopmentAnagilemethodologythatisguidedby7principles: eliminate waste, amplifylearning, decide as fast as possible,empower the team, build integrity in,andseethewhole.
Minimal Marketable Feature (MMF) A chunkof functionality thatdelivers asubset of the customer’s requirements,andthatiscapableofreturningvaluetothe customer when released as anindependententity.
Minimal Viable Feature (MVF) Commonlyusedwithnewproducts.AlsoseeMinimalMarketableFeature.
On-site Customers The term used for the individualresponsiblefortherelativeprioritiesforthe solution requirements in theExtremeProgrammingmethodology.
Operations ReviewsA time‐based process that is used toevaluate milestones and ensure theproduction environment is monitoredandmeasured.
Pair ProgrammingA development technique, frequentlyused in Extreme Programming, wheretwo programmers work together onecomputer, developing code. Generallyoneprogrammerwrites the codewhiletheotherreviewsthecode.
Persona Fictional characters or archetypes thatexemplifythewaythattypicaluserswillinteractwithaproduct.
Plan-driven A software development approach thatfollows an orderly series of sequentialstages. Requirements are agreed upon,design is created and then the code isdeveloped,andtested.
Planning GameThe process used in ExtremeProgramming to conduct releaseplanning and iteration planning. Bothtypes of planning is broken down intothreedistinctphases:explorationphase,commitmentphase,andsteeringphase.
November2011DraftforPublicReview 105
Glossary
Planning PokerAttechniqueusedinrelativeestimationthat uses the entire team to contributetotheestimatedworkeffort.Duringthisgroup exercise, each member of theteamhas a setof cards thathave storypoint values on them. The stories arepresentedand theneach teammembersubmits the card that has the value ofstorypoints that they feel ishowmucheffort is required to deliver the story.Theprocessisrepeateduntilconsensusisreachedforeachstory.
Potentially Shippable Product Increment Scrumrequires thateachsprintdelivera potentially shippable productincrement.The incrementmustconsistofthoroughlytestedcodethathasbeenbuilt into an executable, and the useroperation of the functionality isdocumentedeither inHelp filesoruserdocumentation.
Product Backlog Item In Scrum, a product backlog item (PBI,backlog item,or item) isaunitofworksmallenoughtobecompletedbyateamin one sprint. Backlog items aredecomposedintooneormoretasks.
Product Burndown Chart InScrum,theproductburndownchartisa "big picture" view of a project'sprogress.Itshowshowmuchworkwaslefttodoatthebeginningofeachsprint.The scope of this chart spans releases;however, a release burndown chart islimitedtoasinglerelease.Alsoseeburndownchart.
Product Champion SeeProductOwner.
Product Owner The product owner represents theinterestsofallstakeholders,definesthefeatures of the product and prioritizestheproductbacklog.
Product Roadmap An initial high level project scope anddirection. It may include an initialarchitecture.
Rapid Application Development (RAD) Agenerictermreferringtoanynumberof lighter‐weight approaches, usingfourth‐generation languages andframeworks (such as web applicationframeworks), which accelerate theavailabilityofworkingsoftware.
Rational Unified Process (RUP) An iterative software developmentprocess framework created by theRational Software Corporation, adivisionofIBMsince2003.
Relative EstimationA way of estimating work effort byidentifying features/requirements withstories and then assigning story pointsto each story. The cumulative storypoints are the amount of effort toestimate the amount of effort requiredto deliver each story. The story pointsare then calculated against the team’svelocity to create an estimate on howmuch the team can deliver in aparticulariteration.
106 The Agile Extension to the BABOK® Guide
Glossary
Release The transition of an increment ofpotentially shippable product from thedevelopment team into routine use bycustomers. Releases typically happenwhenoneormore sprintshas resultedin the product having enough value tooutweighthecosttodeployit.
Release Burndown Chart The release burndown chart is a "bigpicture" viewof a release'sprogress. Itshowshowmuchworkwaslefttodoatthebeginningofeachsprintcomprisingasinglerelease.Thescopeof thischartis a single release; however, a productburndownchartspansallreleases.AlsoseeProductBurndownChart.
Release Planning At the beginning of a project the teamwillcreateahigh‐levelreleaseplan.Theteam cannot possibly know everythingup front so a detailed plan is notnecessary. The release plan shouldaddress:thenumberanddurationoftheiterations, how many people or teamsshouldbeonthisproject,thenumberofreleases, the value delivered in eachrelease,theshipdateforthereleases.
Scrum Master The Scrum Master is responsible formaking sure a Scrum team livesby thevalues and practices of Scrum. TheScrum Master protects the team bymaking sure they do not overcommitthemselves to what they can achieveduringasprint.
Scrum Team TheScrumTeambuildstheproductthatthe customer is going to consume: thesoftware or website, for example. Theteam in Scrum is "cross‐functional" ‐ it
includes all the expertise necessary todeliver the potentially shippableproduct each sprint ‐ and it is "self‐organizing",with a very highdegree ofautonomyandaccountability.
Shippable ProductA fully testedunitof codewhichmeetsacceptance criteria, that is delivered attheendofaniteration.
Service Level AgreementsFormalagreementsthatcontractlevelofserviceandperformance.
Solution Assessment and Validation The set of tasks that are performed inordertoensurethatsolutionsmeet thebusiness need and to facilitate theirsuccessful implementation. Theseactivities may be performed to assessand validate business processes,organizational structures, outsourcingagreements, software applications, andany other component of thesolution.
Spike An experiment to explore potentialsolutions or build a partial solution.Spikesarecreatedtofigureoutanswerstotoughtechnicalordesignproblems.
Sprint An iteration of work during which anincrement of product functionality isimplemented.
Sprint Backlog Itemsselectedfromtheproductbacklogtobedeliveredinthecurrentsprint,andtheirtasks.
November2011DraftforPublicReview 107
Glossary
Sprint Goal The Sprint Goal sprint goal is a shortdescription of what the sprint willattempttoachieve.
Sprint Planning Meeting TheSprintPlanningMeetingisattendedbytheproductowner,scrummaster,theentire scrum team, and any interestedand appropriate management orcustomer representatives. During thesprint planning meeting the productowner describes the highest priorityfeatures to the team. The team asksenoughquestionsduringthismeetingsothat they can go off after the meetingand determine which tasks they willmove from the product backlog to thesprintbacklog.
Sprint Retrospective The Sprint Retrospective is the mainmechanismfor taking thevisibility thatScrum provides into areas of potentialimprovement,andturningitintoresults.
Sprint Review Meeting Ameetingwherethescrumteamshowswhat they accomplished during thesprint.Typicallythistakestheformofademo of the new features. Participantsinthesprintreviewtypicallyincludetheproduct owner, the scrum team, thescrummaster,management,customers,and engineers from other projects.During the sprint review the project isassessed against the sprint goaldetermined during the Sprint planningmeeting.Ideallytheteamhascompletedeachproductbacklogitembroughtintothesprint,butitismoreimportantthatthey achieve the overall goal of thesprint.
Standup Meeting SeeDailyMeeting.
Story SeeUserStory.
Story Mapping AStoryMapisatooltoassistincreatingunderstanding of product functionality,the flow of usage, and to assist withprioritizing product delivery (such asreleaseplanning).
Task Board The task board shows all thework theteam is doing during an iteration. It isupdated continuously throughout theiteration – if someone thinks of a newtasktheywriteanewcardandputsitonthe board. Either during or before thedaily meeting, estimates are changed(up or down) and cards are movedaroundtheboard.
Team Velocity The rate at which a team canconsistently deliver software featuresper iteration. Typically, it can beestimated by viewing previous sprints,assuming the team composition. andsprintdurationarekeptconstant.Itcanalsobeestablishedonasprint‐by‐sprintbasis, using commitment‐basedplanning.
Theory of Constraints Developed by Dr. Eli Goldratt, theTheory of Constraints (TOC) holds thateverysystemhasatleastoneconstraintlimiting it. TOC’s goal is to increaseefficienciesbyidentifyingandmitigatingtheseconstraints.
108 The Agile Extension to the BABOK® Guide
Glossary
UMLUnified Modeling Language (UML) is astandardized language used to visuallyarticulate elements of a piece ofsoftware.
User Acceptance Criteria Test cases that users employ to judgewhether the delivered system isacceptable. Each acceptance testdescribes a set of system inputs andexpectedresults.
User Story Ahigh‐level,informal,shortdescriptionof a solution capability that providesvalue to a stakeholder. A user story istypicallyoneortwosentenceslongandprovides the minimum informationnecessary to allow a developer toestimate the work required toimplementit.
User Story Mapping A workflow of a business process thatbreaksdowntasksforeachprocessandrepresentsthesetasksbasedonpriority.
Value driven developmentA process used to prioritizerequirementsorbacklogitemsbasedonbusinessvalue.
Velocity SeeTeamVelocity.
Waterfall A software development approach thatfollows an orderly series of sequentialstages. Requirements are agreed upon,design is created and then the code isdeveloped,andtested.
Whole Team Testing The concept embraced by may agilemethodologieswheretheentireprojectteam is responsible for qualityassuranceandtestingthecode.
November2011DraftforPublicReview 109
Glossary
110 The Agile Extension to the BABOK® Guide
appendix B Bibliography
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.
Arthur,Jay.2006.LeanSixSigmaDemystified:ASelf‐TeachingGuide.McGraw‐HillProfessional.
Berenbach,Brian,DanielJ.Paulish,JuergenKazmeier,andArnoldRudorfer.2009.Software&SystemsRequirementsEngineering:InPractice.McGraw‐HillOsborneMedia.
Chelimsky,David,DaveAstels,BryanHelmkamp,andDanNorth.2010.TheRSpecBook:BehaviourDrivenDevelopmentwithRspec,Cucumber,andFriends.PragmaticBookshelf.
November2011DraftforPublicReview 111
Bibliography
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.
IIBA(2009).AGuidetotheBusinessAnalysisBodyofKnowledge®(BABOK®
Guide),Version2.InternationalInstituteofBusinessAnalysis.
112 The Agile Extension to the BABOK® Guide
Bibliography
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.
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.
November2011DraftforPublicReview 113
Bibliography
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.
114 The Agile Extension to the BABOK® Guide
appendix C Contributors
IIBA®andTheAgileAlliance®wouldliketothankthefollowingcontributorstoTheAgileExtensiontotheBABOK®Guide.WithouttheireffortsandcommitmentTheAgileExtensiontotheBABOK®Guidewouldnotbepossible.
November 2011 Release• KevinBrennan• SusanBlock• DavidC.Cook• PeterGordon• EllenGottesdiener• ShaneHastie• BrianHemker• MarshaHughes• ChrisMatts• AliMazer• LuizClaudioParzianello• CarolScalice• DennisStevens
August 2010 Release• SusanBlock• PascalVanCauwenberghe• SteveErlank• EllenGottesdeiner• ShaneHastie• MarshaHughes• AliMazer• MaureenMcVey• DavidMorris• LuizClaudioParzianello• DennisStevens
November2011DraftforPublicReview 115
Contributors
116 The Agile Extension to the BABOK® Guide
IIBA International Institute of Business Analysis
About International Institute of Business Analysis (IIBA)
International Institute ofBusinessAnalysis (IIBA) is anindependentnon‐profitprofessionalassociationservingthe growing field of Business Analysis. For individualsworking in a broad range of roles ‐ business analysis,systemsanalysis,requirementsanalysisormanagement,project management, consulting, process improvementandmore ‐ IIBA®canhelpyoudoyour jobbetter andenhanceyourprofessionallife.
IIBA has created the Business Analysis Body ofKnowledge® (BABOK®) Guide, the collection ofknowledge within the BA profession, reflecting thecurrent generally accepted practices.We help businessanalystsdeveloptheirskillsandfurthertheircareersbyproviding access to unique and relevant content.Membershipbenefitsincludeaccesstothefollowing:
• CopyofthelatestBABOK®Guide
• Online library with access to hundreds of BArelatedbooks
• Webinars on a range of professionaldevelopmenttopics
• BA CompetencyModel and BA Self‐AssessmentTool
• JobsearchcapabilitiesusingtheCareerCenter
• Discounted fees to apply for, re‐certify and sitexams for professional accreditation Certified
Business Analysis ProfessionalTM (CBAP®)designation and Certification of Competency in
BusinessAnalysisTM(CCBATM)designation.
• Monthly"BAConnection"newsletter
• Chapters
IIBAisdedicatedtothedevelopmentandmaintenanceofstandardsforthepracticeofbusinessanalysis,andforthecertificationandrecognitionofpractitioners.
Certified Business Analysis ProfessionalTM (CBAP®) TheCertifiedBusinessAnalysisProfessionalTM(CBAP®)designation is aprofessional certification for individualswithextensivebusinessanalysisexperience.Withatleast7500hoursofhands‐onBAexperience,CBAP®recipientsaretheelite,seniormembersoftheBAcommunity.
Certification of Competency in Business AnalysisTM (CCBATM) TheCertification of Competency inBusinessAnalysisTM
(CCBATM) designation is a professional certification forbusiness analysis practitioners who want to berecognized for their expertise and skills by earningformalrecognition.Withatleast3750hoursofhands‐onBAexperience,theyhavedevelopedessentialBAskills.
MoreinformationregardingCertificationscanbefoundatwww.iiba.org/certification.
IIBA® Chapters IIBA®Chaptersadvancethemissionandobjectivesoftheorganization by promoting professional standards andpractices at the local level. Ongoing professionaldevelopmentisakeybenefitofyourIIBA®membershipand is supported at the chapter level through activities,meetings, and educational programs. A list of IIBA®Chapters andmore information regarding them can befoundatwww.iiba.org/chapters.
Membership in IIBA®When you join IIBA®, you become a member of aninternational association dedicated to developing andpromoting the Business Analysis profession. Moreinformation regarding IIBA® can be found atwww.iiba.org.
www.iiba.org
The Agile Alliance
The Agile Alliance is a nonprofit organization with global membership, committed to advancing Agile developmentprinciplesandpractices.AgileAlliancesupportsthosewhoexploreandapplyAgileprinciplesandpracticesinordertomakethesoftwareindustrymoreproductive,humaneandsustainable.Weshareourpassiontodeliversoftwarebettereveryday.
Agilemethodshaveproventheireffectivenessandaretransformingthesoftwareindustry.Asagilemethodsevolveandextend,AgileAlliance fosters a communitywhereorganizationsand individuals findways to transition to andadvanceAgilepractices,regardlessofmethodology.
TheAgileAlliancewebsiteoffersan informationhubwheremembers canaccessawidevarietyof resources—anarticlelibrary,videos,presentations,localusergrouplistingsandlinkstoadditionalagileresources.
Agile Alliance organizes the largest, most diverse and comprehensive agile conferences each year. Conferenceparticipants learn from hundreds of sessions spanning the entire agile organization and lifecycle, make businessconnections,andconversewithagilethoughtleaders,practitioners,andauthors.
Inadditiontothesemajorconferences,AgileAllianceprovidesfinancialandorganizationalsupporttoscoresoflocal,regionalandspecialinterestconferencesandusergroupsworldwide.
TheAgileAllianceoperatesontheprinciplesoftheAgileManifesto.http://www.agilemanifesto.org
TheAgileAlliancewebsiteis:www.agilealliance.org.
www.iiba.org
Changing the Way Organizations Change™Business analysis is the set of tasks and techniques used towork as a liaison amongstakeholders in oder to understand the structure, policies, and operations of anorganization, and to recommend solutions that enable the organization to achieve itsgoals.
Business analysis involves understanding how organizations function to accomplishtheir purposes and defining the capabilities an organization requires to provideproducts and services to external stakeholders. It includes the definition oforganizational goals, understanding how those goals connect to specific objectives,determiningthecoursesofactionthatanorganizationhastoundertaketoachievethosegoalsandobjectives,anddefininghowthevariousorganizationalunitsandstakeholderswithinandoutsidethatorganizationinteract.
TheAgileExtension to theBABOK®Guide contains descriptions of generally acceptedpractices and techniques used by those to practice business analysis within an agiledevelopment framework. The content has been verified through reviews bypractitioners,consultationwithrecognizedexpertsinthefield,andclosecollaborationbetweenIIBA®andtheAgileAlliance®.
The BABOK®Guide is recognized around the world as a key tool for the practice ofbusinessanalysisandhasbecomeawidely‐acceptedstandardfortheprofession,withover 200,000 copies downloaded from the IIBA®website. TheAgileExtension to theBABOK® Guide builds on the practices found in the BABOK® Guide, and describesbusinessanalysisareasofknowledge,theirassociatedactivitiesandtasks,andtheskillsnecessary to be effective in their execution within the framework of agile softwaredevelopment.