Agile Extension to the BABOK Guide - Agile Alliance

ComplimentaryMemberCopy.NotforRedistributionorResale

Agile Extension to the

BABOK®GuideVersion 1.0

www.iiba.org

InternationalInstituteofBusinessAnalysis,Toronto,Ontario,Canada

© InternationalInstituteofBusinessAnalysis.Allrightsreserved.

Thisdocumentisprovidedtothebusinessanalysiscommunityforeducationalpurposes.IIBA®warrantsthatitissuitableforanyotherpurposeandmakesnoexpressedorimpliedwarrantyofanykindandassumesnoresponsibilityforerrorsoromissions.Noliabilityisassumedforincidentalorconsequentialdamagesinconnectionwithorarisingoutoftheuseoftheinformationcontainedherein.

IIBA®,theIIBA®logo,BABOK®andBusinessAnalysisBodyofKnowledge®areregisteredtrademarksownedbyInternationalInstituteofBusinessAnalysis.CBAP®andCCBA®areregisteredcertificationmarksownedbyInternationalInstituteofBusinessAnalysis.CertifiedBusinessAnalysisProfessional,CertificationofCompetencyinBusinessAnalysis,EndorsedEducationProvider,EEPandtheEEPlogoaretrademarksownedbyInternationalInstituteofBusinessAnalysis.”

TheAgileAlliance®andtheAgileAlliancelogoarearegisteredtrademarksownedbyTheAgileAlliance.

NochallengetothestatusorownershipoftheseoranyothertrademarkedtermscontainedhereinisintendedbytheInternationalInstituteofBusinessAnalysis.

Table of Contents

Agile Extension to the BABOK® Guide i

ComplimentaryMemberCopy.NotforRedistributionorResale.

Chapter 1: Introduction to the Agile Extension 1

What is the Agile Extension to the BABOK® Guide?...................................................... 1 What is Agile? ..................................................................................................................... 2 What does Agile Mean for Business Analysis? ............................................................... 4 What does Agile Mean for Business Analysts? ............................................................... 6 What makes a BA Successful on an Agile Team?............................................................ 8

Chapter 2: Business Analysis in Agile Approaches 9

Scrum ................................................................................................................................ 10Backlogs ......................................................................................................................................................... 10Sprint Planning and Execution.................................................................................................................... 11Roles and Responsibilities............................................................................................................................ 12Business Analysis in Scrum.......................................................................................................................... 12Techniques ..................................................................................................................................................... 13

Extreme Programming (XP) ............................................................................................ 13User Stories.................................................................................................................................................... 14Release Planning and Execution ................................................................................................................. 14Roles and Responsibilities............................................................................................................................ 16Business Analysis in XP................................................................................................................................. 16Techniques ..................................................................................................................................................... 16

Kanban .............................................................................................................................. 17Queues ........................................................................................................................................................... 17Roles and Responsibilities............................................................................................................................ 18Business Analysis in Kanban ....................................................................................................................... 18

Levels of Planning in Agile Approaches ........................................................................ 19Strategy Planning.......................................................................................................................................... 20Release Planning........................................................................................................................................... 21Iteration Planning ......................................................................................................................................... 21Daily Work Planning ..................................................................................................................................... 23Continuous Activity Planning....................................................................................................................... 23

ii Agile Extension to the BABOK® Guide


Chapter 3: Mapping Agile Techniques to the BABOK® Guide 25

Business Analysis Planning and Monitoring ................................................................ 25Plan Business Analysis Approach (2.1)....................................................................................................... 25

Agile Techniques....................................................................................................................................... 26Conduct Stakeholder Analysis (2.2) ............................................................................................................ 27

Agile Techniques....................................................................................................................................... 27Plan Business Analysis Activities (2.3)......................................................................................................... 27

Agile Techniques....................................................................................................................................... 27Plan Business Analysis Communication (2.4)............................................................................................ 28

Agile Techniques....................................................................................................................................... 28Plan Requirements Management Process (2.5)......................................................................................... 28

Agile Techniques....................................................................................................................................... 28Manage Business Analysis Performance (2.6) ........................................................................................... 29

Agile Techniques....................................................................................................................................... 29 Elicitation.......................................................................................................................... 29

Prepare for Elicitation (3.1) ......................................................................................................................... 30Agile Techniques....................................................................................................................................... 30

Conduct Elicitation Activity (3.2) ................................................................................................................. 31Agile Techniques....................................................................................................................................... 31

Document Elicitation Results (3.3) .............................................................................................................. 31Agile Techniques....................................................................................................................................... 32

Confirm Elicitation Results (3.4) .................................................................................................................. 32Agile Techniques....................................................................................................................................... 32

Requirements Management and Communication ...................................................... 32Manage Solution Scope and Requirements (4.1)...................................................................................... 33

Agile Techniques....................................................................................................................................... 33Manage Requirements Traceability (4.2).................................................................................................... 33

Agile Techniques....................................................................................................................................... 33Maintain Requirements for Reuse (4.3)...................................................................................................... 34

Agile Techniques....................................................................................................................................... 34Prepare Requirements Package (4.4) ......................................................................................................... 34

Agile Techniques....................................................................................................................................... 34Communicate Requirements (4.5) .............................................................................................................. 35

Agile Techniques....................................................................................................................................... 35 Enterprise Analysis.......................................................................................................... 35

Define Business Need (5.1) .......................................................................................................................... 35Agile Techniques....................................................................................................................................... 36

Assess Capability Gaps (5.2) ........................................................................................................................ 36Agile Techniques....................................................................................................................................... 36

Determine Solution Approach (5.3) ............................................................................................................ 36Agile Techniques....................................................................................................................................... 36

Define Solution Scope (5.4).......................................................................................................................... 36Agile Techniques....................................................................................................................................... 37

Define Business Case (5.5) ........................................................................................................................... 37Agile Techniques....................................................................................................................................... 37

Requirements Analysis ................................................................................................... 38Prioritize Requirements (6.1)....................................................................................................................... 38

Agile Extension to the BABOK® Guide


Agile Techniques....................................................................................................................................... 38Organize Requirements (6.2) ....................................................................................................................... 39

Agile Techniques....................................................................................................................................... 39Specify and Model Requirements (6.3)....................................................................................................... 39

Agile Techniques....................................................................................................................................... 40Define Assumptions and Constraints (6.4)................................................................................................. 40

Agile Techniques....................................................................................................................................... 40Verify Requirements (6.5)............................................................................................................................. 41

Agile Techniques....................................................................................................................................... 41Validate Requirements (6.6) ........................................................................................................................ 41

Agile Techniques....................................................................................................................................... 42 Solution Assessment and Validation............................................................................. 42

Assess Proposed Solution (7.1).................................................................................................................... 42Agile Techniques....................................................................................................................................... 42

Allocate Requirements (7.2)......................................................................................................................... 43Agile Techniques....................................................................................................................................... 43

Assess Organizational Readiness (7.3) ....................................................................................................... 43Define Transition Requirements (7.4) ......................................................................................................... 43

Techniques................................................................................................................................................ 44Validate Solution (7.5).................................................................................................................................. 44

Agile Techniques....................................................................................................................................... 44Evaluate Solution Performance (7.6).......................................................................................................... 44

Agile Techniques....................................................................................................................................... 45

Chapter 4: Agile Techniques 47

A Context for Agile Business Analysis ........................................................................... 47 A Note on Agile Extension Techniques.......................................................................... 49 BA Techniques Mapped to Agile Guidelines ................................................................. 49 Guidelines for Agile Business Analysis.......................................................................... 53 The Discovery Framework .............................................................................................. 54

See The Whole ............................................................................................................................................... 54Business Capability Analysis................................................................................................................... 55Personas ................................................................................................................................................... 59Value Stream Mapping............................................................................................................................ 60

Think as a Customer..................................................................................................................................... 64Story Decomposition ............................................................................................................................... 65Story Elaboration ..................................................................................................................................... 68Story Mapping.......................................................................................................................................... 70User Story ................................................................................................................................................. 72Storyboarding .......................................................................................................................................... 75

Analyze to Determine What is Valuable ..................................................................................................... 77Backlog Management.............................................................................................................................. 78Business Value Definition........................................................................................................................ 80Kano Analysis ........................................................................................................................................... 81MoSCoW Prioritization ............................................................................................................................ 84Purpose Alignment Model....................................................................................................................... 86

The Delivery Framework................................................................................................. 89Get Real Using Examples.............................................................................................................................. 89

iv Agile Extension to the BABOK® Guide


Behaviour Driven Development (BDD) .................................................................................................. 90Understand What is Doable ........................................................................................................................ 93

Relative Estimation .................................................................................................................................. 93Planning Workshop ................................................................................................................................. 96Real Options ............................................................................................................................................. 98

Stimulate Collaboration and Continuous Improvement ....................................................................... 102Collaborative Games ............................................................................................................................. 103Retrospectives ........................................................................................................................................ 105

Avoid Waste ................................................................................................................................................. 106Lightweight Documentation ................................................................................................................. 108

Glossary ..........................................................................................111

Index ...............................................................................................117

Bibliography ....................................................................................121

Contributors ...................................................................................125

Agile Extension to the BABOK® Guide 1


ONEChapterIntroduction to the Agile Extension

1.1 What is the Agile Extension to the BABOK® Guide?TheAgileExtensiontotheBABOK®Guidedescribesbusinessanalysisareasofknowledge,theirassociatedactivitiesandtasks,andtheskillsnecessarytobeeffectiveintheirexecutionwithintheframeworkofagilesoftwaredevelopment.

ThepurposeoftheAgileExtensiontotheBABOK®Guideistoactasabusinessanalysisprimerforagilesoftwaredevelopmentapproachesandprovidebusinessanalysispractitionerswith:

• anintroductiontoagilepracticesforbusinessanalysis,• anoverviewofbusinessanalysistechniquesforagilepractitioners,• asetofdefinitionsoftypicalworkingpracticesusedbybusinessanalystsworkingonagileprojects,and

• anoverviewofthenewandchangedroles,skills,andcompetenciesforbusinessanalysts.

TheAgileExtensionisofvaluetobusinessanalystsnewtoagile,aswellasthoseexperiencedinagileapproaches.Bothgroups,andallthoseinbetween,willfindhelpfulinformationsuchasanintroductiontothepracticeofbusinessanalysisinanagilecontext,themappingofexistingbusinessanalysistechniquestoagilepractices,andinclusionoftechniquesthatarespecifictothepracticeofbusinessanalysisintheagileworld.

AstheAgileExtensionhighlights,anymemberofanagileteammayengageintheprocessofbusinessanalysis.Tothatend,eachpersononanagileteamwillbenefitfromhavingasetofpracticesandtoolsfromwhichtheycanselectwhileworkinginanyoneofthedifferentflavorsofagile.IntheAgileExtension,wehavecalledparticularattentiontothemind‐setabusinessanalysispractitionermusthaveinordertoeffectivelycontributetodelivery

2 Agile Extension to the BABOK® Guide

What is Agile? Introduction to the Agile Extension


ofongoingvaluetostakeholders.WehavealsodescribedanumberoftechniquesnotfoundintheBABOK®Guide,andexpandedonothersthatneededtobedescribedingreaterdetail.Manyoftheconceptsdescribedhere,andthemind‐setwedescribe,willprovevaluabletobusinessanalysisinanycontextorenvironment.Businessanalystsshouldalwaysworktoensurethatrequirementsarealignedwithorganizationalgoalsandobjectivesandthatallstakeholdershaveasharedunderstandingofthosegoals,objectives,andrequirements.Theymustalsoworktomanagerisksandvalidatethattherequirements,ifdelivered,willcreaterealvalueforstakeholders.Agileapproachescanhelpusfindnewwaystodothesethingsthatsupportcontinuousdeliveryofworkingsoftware,buttheresponsibilitytodothesethingsisinherenttotheprofessionofbusinessanalysis.

1.2 What is Agile?Agileisatermusedtodescribeanumberofiterativedevelopmentapproachesthathavedevelopedovertime.Agileoriginatedwithintheworldofsoftwaredevelopment.However,withitssuccessandabilitytoadapttoindividualcontextsandenvironments,agilehasevolvedintobeingutilizedbynon‐softwarerelatedprojects.

Thetermagilecanhavemanydifferentinterpretations.ItistheAgileManifesto(www.agilemanifesto.org)thatclearlydefineswhatagilemeans,andtheprinciplesthatsupportit.

Manifesto for Agile Software DevelopmentWeareuncoveringbetterwaysofdevelopingsoftwarebydoingitandhelpingothersdoit.Throughthisworkwehavecometovalue:

Individualsandinteractionsoverprocessesandtools

Workingsoftwareovercomprehensivedocumentation

Customercollaborationovercontractnegotiation

Respondingtochangeoverfollowingaplan

Thatis,whilethereisvalueintheitemsontheright,wevaluetheitemsontheleftmore.

http://www.agilemanifesto.org





Introduction to the Agile Extension What is Agile?


Principles Behind the Agile Manifesto

Wefollowtheseprinciples:

1. Ourhighestpriorityistosatisfythecustomerthroughearlyandcontinuousdeliveryofvaluablesoftware.

2. Welcomechangingrequirements,evenlateindevelopment.Agileprocessesharnesschangeforthecustomer'scompetitiveadvantage.

3. Deliverworkingsoftwarefrequently,fromacoupleofweekstoacoupleofmonths,withapreferencetotheshortertimescale.

4. Businesspeopleanddevelopersmustworktogetherdailythroughouttheproject.

5. Buildprojectsaroundmotivatedindividuals.Givethemtheenvironmentandsupporttheyneed,andtrustthemtogetthejobdone.

6. Themostefficientandeffectivemethodofconveyinginformationtoandwithinadevelopmentteamisface‐to‐faceconversation.

7. Workingsoftwareistheprimarymeasureofprogress.

8. Agileprocessespromotesustainabledevelopment.Thesponsors,developers,andusersshouldbeabletomaintainaconstantpaceindefinitely.

9. Continuousattentiontotechnicalexcellenceandgooddesignenhancesagility.

10. Simplicity‐‐theartofmaximizingtheamountofworknotdone‐‐isessential.

11. Thebestarchitectures,requirements,anddesignsemergefromself‐organizingteams.

12. Atregularintervals,theteamreflectsonhowtobecomemoreeffective,thentunesandadjustsitsbehavioraccordingly.

ForthepurposesoftheAgileExtensiontotheBABOK®Guide,wecharacterizetheManifestoanditsPrinciplesasaphilosophyandanapproach.

TheAgileManifestousesthetermdeveloperstodescribetheteamwhoworksonbuildingtheproduct.Thisisacross‐functionalteamofskilledindividualswhobringavarietyofexpertisetobearontheprocessofbuildingasoftwareproduct.Theskillsthatdevelopersrequiretodothisincludebusinessanalysis,technicaldesign,programminginvariouslanguagesandtools,testing,UIdesign,


What does Agile Mean for Business Analysis? Introduction to the Agile Extension


technicalwriting,architecture,andwhateverelseisneededtoproduceworkingsoftware.Workingsoftwareisaproductwhichisintheproductionenvironmentdeliveringvalueforourcustomers.

1.3 What does Agile Mean for Business Analysis?Muchlikeotherapproaches,businessanalysisiscentraltothesuccessofagileprojects.Businessanalysisisnecessarytoenableadiversegroupofcustomerstospeakwithasinglevoice.Notallagileprojectshavethedefinedroleofbusinessanalyst,butallagileprojectsdopracticebusinessanalysis.Businessanalysismaybedonebyoneormoremembersofanagileteam.

Intheagileworld,softwarerequirementsaredevelopedthroughcontinualexplorationofthebusinessneed.Requirementsareelicitedandrefinedthroughaniterativeprocessofplanning,definingacceptancecriteria,prioritizing,developing,andreviewingtheresults.Throughouttheiterativeplanningandanalysisofrequirements,businessanalysispractitionersmustconstantlyensurethatthefeaturesrequestedbytheusersalignwiththeproduct'sbusinessgoals,especiallyasthebusinessgoalsevolveandchangeovertime.Thisistruefornewsoftwaredevelopment,maintenanceofexistingsoftware,migrationofsoftwareanddata,orimplementationofcommercialoff‐the‐shelf(COTS)software.Itappliestoverylargemission‐criticalsoftwareprojectsinheavilyregulatedindustries,aswellastodevelopmentofsmallorsimplesoftwarefunctionalityinunregulatedenvironments.Agilebusinessanalysisisprimarilyaboutincreasingthedeliveryofbusinessvaluetothesponsorsandcustomersoftheproject/productbeingdeveloped.AgilebusinessanalysisalignswiththevaluesandprinciplesoftheAgileManifesto(www.agilemanifesto.org):

• Wevalueindividualsandinteractionsoverprocessesandtools.• Ourhighestpriorityistosatisfyourcustomerthroughearlyandcontinuousdeliveryofvaluablesoftware.

• Workingsoftwareistheprimarymeasureofprogress.

Agilebusinessanalysisisaboutensuringtherightinformationisavailabletothedevelopmentteamintherightlevelofdetail,attherighttime,sotheycanbuildtherightproduct.



Introduction to the Agile Extension What does Agile Mean for Business Analysis?


Thetechniquesofbusinessanalysisdonotchangedramaticallyintheagileenvironment.However,thetimingandhowtheyareuseddochange.Artifactssuchaspersonas,datamodels,usecases,storymaps,andbusinessrulescontinuetobeemployed,butarekeptaslight‐weightaspossible.Artifactsthataremorequicklydevelopedsuchasdiagrams,maps,andliststendtoprovidemorevaluetoanagileprojectthanhighlydetailedspecificationsthatslowdownthedevelopmentofworkingsoftware.Lower‐fidelityartifactsaredevelopedforthesolepurposeofbuildingthesoftwareforaspecificiterationandonlyneedtobeintelligibletotheteamduringthecourseoftheiteration.Long‐livedartifacts,ontheotherhand,areintendedtobeutilizedbeyondthescopeofdevelopment.Long‐livedartifactsmayincludethebusinesscase,charter,anddocumentationthatisusedtocommunicatewhatthesoftwaredoesandwhyitdoesit.

Agileofferstheopportunityforbusinessanalysistobenefitfromthefrequentfeedbackprovidedbythebusiness.Byreviewingtheresultsofsuccessiveiterationswiththebusinessstakeholders,analystshavetheopportunityto

• refinetheproduct'srequirementstoensuretheymaintaincohesionwiththebusinessneedsfortheproduct,

• identifyandmitigateriskearlyintheproject,and• ensurethattherightsolutionisdelivered.

Wheneverpossible,inagileprojects,highriskitemsareaddressedinearlyiterations.Thisallowstheteamtomitigateissuesandthepossiblereworkrequiredifriskitemsarenotaddresseduntillaterintheproject.Facilitatingriskdiscoveryandassistingtheteaminremainingfocusedoneffectiveriskmitigationiscentraltotheanalyst'sroleonanagileteam.

Iterativedevelopmentprocessesprovideopportunitiesforincreasedefficienciesinthepracticeofbusinessanalysis.Inplan‐drivenprojects,requirementsaredevelopedintheirentiretypriortothedevelopmentphase.Asriskelementsareuncoveredandbusinessneedsevolve,certainrequirementsmaychangeorbeeliminatedoutright;makingtheworkeffortputintothoserequirementswasted.Byprovidingjust‐in‐timerequirements,thereislessreworkofrequirementsbecauseonlytherequirementsrequiredforthecurrentreleasearedefinedindetailanddeveloped.


What does Agile Mean for Business Analysts? Introduction to the Agile Extension


1.4 What does Agile Mean for Business Analysts?Theearlystagesofagile'sevolutionfrequentlyreliedonasingleindividualbeingabletomakeallthedecisionsregardingthedevelopmentofthesoftware.Asagileprojectsgrowinsizeandbreadth,andbecomeadoptedbylargerandmorediverseorganizations,theroleofbusinessanalysthasbecomeavitalcontributor.Businessanalysisskillsareneededtoelicitandanalyzetheneedsandwishesofdiversestakeholdersandforarrivingatasingle,agreeduponproductvision.

Insomeprojectsadedicatedbusinessanalystroleisunnecessary.Thisisnottosaythatbusinessanalysisisnotconductedduringthecourseoftheproject,onlythatitmaybedonebyanymember,ormembers,oftheoveralldevelopmentteam.

Thereareavarietyofwaysabusinessanalystcanbeengagedonanagileproject:

• Theanalystmightbethefacilitatorinmorecomplexenvironments,bringingdivergentbusinessstakeholderstogetherandhelpingthemspeakwithasinglevoicesotheprojectteamisnotconfusedbycontradictoryandconflictingperspectives.

• Theanalystmightactastheproductowner/customerrepresentativewheretheyareempoweredbythebusinesstomakedecisionsonproductfeaturesandpriority.

• Theanalystcouldactasasurrogateproductowner,insituationswherethebusinessproductownerisnotavailable.

• Theanalystmightactasthesecondincommandtoabusinessproductownerwithlimitedavailability.

• Theanalystcouldtaketheroleofcoachinanenvironmentwherethebusinessproductowneriscompetentandcommitted,buthaslimitedITprojectexperienceandtherestofthedevelopmentteamarelackingindomainknowledge.

• Theanalystcanplayacentralroleindefiningandcommunicatingtheacceptancecriteriapriortodevelopmentworkcommencing.

• Theanalystcanbeinvolvedincreatingandexecutingacceptancetests.

• Theanalystcanensurethattheteamremainsfocusonthebusinessvalueoftheproject.

• Theanalystcanplayaroleinidentifyingimportantrequirementsthatmightnothavebeenactivelyrepresentedbystakeholders.


Introduction to the Agile Extension What does Agile Mean for Business Analysts?


Irrespectiveofjobtitles,businessanalysisisaboutensuringtheprojectisabletodeliverthemaximumvalueforcustomersandadaptingtotheevolvingbusinessneeds.

Thetechniquesutilizedinagileapproachesdonotrepresentamajorshiftforbusinessanalysts.TheycontinuetoutilizemanyofthetoolsandtechniquesdefinedinAGuidetotheBusinessAnalysisBodyofKnowledge®(BABOK®Guide).Whathaschangedisthetimingandtheusageofthesetechniques.Therigorsanddemandsofagileprojectsalsorequirebusinessanalyststoutilizeanddevelopskillsthattheymaynothavepreviouslyexercisedatahighlevel.Inanagileenvironment,thesuccessofthebusinessanalystreliesincreasinglyonsuchinterpersonalskillsascommunication,facilitation,coachingandnegotiation.Theseskillsarecertainlycentraltothesuccessofananalystinanyenvironment.However,duetotheinter‐connectednessofagileteams,iftheseskillsarenotbeingeffectivelyutilized,thenumberofrequeststhatcanbeadequatelyunderstoodandprioritizeddecreases.Thisresultsinfeweritemsmakingitintothesolutionimplementationforagivenrelease.

Analystsarerequiredtoapproachrequirementsfroma360degreeperspective.Theyarerequiredtoworkwiththebusinesssponsoronastrategiclevel,anddefinehowtheproposedproductorfeaturealignswiththeorganization'sportfolioandstrategy.Theymustthenworkwiththebusinessandprojectteamtobreakthisvisiondownintorequirementsthatsupporteffectiveandaccurateestimation.Inanagileprojectthisisdoneforeachiterativerelease,asopposedtothesinglerequirementsphasethatexistsinplan‐drivenapproaches.Theanalystdeliversjust‐in‐time,detailedrequirementstothedevelopmentteamsotheycanbuildonlywhatisrequiredforaspecificiteration.

Businessanalystsplayakeyroleinfacilitatingasharedunderstandingofthebusinessneedfortheprojectwithallstakeholders.Itistheroleofthebusinessanalysttofacilitateashared,agreeduponvisionfortheproductacrosstheentiredeliveryteam.Understandingandpresentingmultipleviewpoints,alongsidetheabilitytoholdsuccessfulconversations,trumptheneedforformal,detailed,longtermartifactssuchasrequirementdocuments.

Oneofthekeyelementsforabusinessanalystworkinginanagileenvironmentistheabilitytousefeedbacktodrivechange.Itisincumbentontheanalysttoconstantlyreviewrequirementswiththebusinessstakeholdersandensurethatanyshiftsinbusinessneedsareaccuratelyreflectedinfuturereleasesoftheproduct.


What makes a BA Successful on an Agile Team? Introduction to the Agile Extension


1.5 What makes a BA Successful on an Agile Team?Theverynatureofagileapproachesrequiresallteammemberstobeoperatingataveryhighlevelofcompetency,skill,andeffectiveness.Thisisespeciallytrueforbusinessanalysts.Onsuccessfulagileteams,businessanalystsareanintegralcomponentofthedeliveryteam.Theyareactiveparticipants,ifnottheactualfacilitatorsofplanning,analyzing,testing,anddemonstratingactivities.

Thebusinessanalystplaysacentralroleinensuringthattheproductroadmapclearlydefinestheproduct'sstrategicalignmenttothebusinessneed.Theanalystholdssharedresponsibilityindefiningthestrategiccriteriaforcompletionoftheproject.Thisrequirestheanalysttoexerciseanextremelyhighlevelofskillincommunication,facilitation,andnegotiation.Theyrequiretheabilitytolistentoandunderstandfeedbackfromallstakeholdersandusethisfeedbacktodrivethechangesrequiredtotherequirementsandprioritiesoftheproject.



TWOChapterBusiness Analysis in Agile Approaches

Agileisatermusedtodescribeanumberofiterativedevelopmentapproachesthathavedevelopedovertime.Itisimportanttonotethatthoughmostagileapproachesareiterative,notalliterativeapproachesareagile.Commontraitsamongstagileapproachesincludefrequentproductreleases,highlevelsofreal‐timecollaborationwithintheprojectteamandwithcustomers,reducedtimeintensivedocumentation,andregular,recurringassessmentsofvalueandrisktoallowforchange.

Afewexamplesofagileapproachesinclude

• Scrum,• ExtremeProgramming(XP),• Kanban,• Crystal,• DynamicSystemsDevelopmentMethod(DSDM),• AgileUnifiedProcess(AUP),• FeatureDrivenDevelopment,and• AdaptiveSoftwareDevelopment.

Eachagileapproachhasitsownuniquesetofcharacteristicsthatallowteamstoselectanapproachthatbestsuitstheprojectathand.Itiscommonforprojectteamstoblendcharacteristicsfrommorethanoneagileapproachbasedonuniqueteamcomposition,skills,experience,operatingenvironment,andotherfactors.DuetotimeandspacelimitationstheAgileExtensiondoesnotprovidecomprehensiveinformationoneachapproach.WedoprovideanoverviewofScrum,ExtremeProgramming(XP),andKanbaninordertoprovidealevelofcontextforthosewhoarenotfamiliarwiththeseagileapproaches.

Agileapproachestendtofocusonachievingbusinessvaluebasedonbusinessneeds.Plan‐drivenapproachestendtofocusonachievementoftheirquality/cost/deliveryanalysis(QCD)withintheprojectlife‐cycle.Whenworkinginan


Scrum Business Analysis in Agile Approaches


agileenvironmentbusinessanalystsworktotransformbusinessneedintobusinessvalue.

Althoughwedousetheplan‐drivenapproachasameansofarticulatingsomeofthedifferentiatingaspectsofagileapproaches,itshouldbenotedthatthesearenottheonlyapproachesavailabletothosepracticingbusinessanalysis.TheAgileExtensiontotheBABOK®Guidedoesnotrecommendoneapproachoveranother,nordoesittakeapositiononthebenefitsofapplyingagileapproaches.Duediligenceandresearchisrequiredwhenselectinganapproach.

2.1 ScrumScrumisoneofthemostpredominantagileprocessframeworksinusetoday.IntheScrumframeworkworkonaprojectisperformedinaseriesofiterations,calledsprints,whichgenerallylastfrom2to4weeks.Attheendofeachsprint,theteammustproduceworkingsoftwareofahighenoughqualitythatitcouldpotentiallybeshippedorotherwisedeliveredtoacustomer.

WithintheScrumframeworktherearefourformalmeetings,knownasceremonies:

• sprintplanning,• thedailyscrum(orstand‐up),• sprintreviews,and• sprintretrospectives.

2.1.1 Backlogs

IntheScrumframework,aproductbacklogliststherequirementsforaniterationprioritizedbyhighestcustomervalue.Thebacklogisacollectionofuserstoriesthatincludetheexpectedbusinessvalue.Theuserstoriesarerefinedastheacceptancecriteriaisdeveloped.Astheteamcollaborateswiththecustomerfortheproject,theproductbacklogisupdatedwitheachrequest.

Theproductbacklogisconstantlyprioritized,suchthatatanygiventimeitcanbeusedtoidentifyhighpriorityrequestsforthesolutionbeingdeveloped.Atthebeginningofeachsprint,inthesprintplanningceremony,theteamreviewstheprioritizedproductbacklogand


Business Analysis in Agile Approaches Scrum


identifiesthecustomer'shighest‐priorityuserstoriesthatcanbecompletedwithinthesprintperiod.Theselectedstoriesarethenplacedonasmallersprintbacklog.

2.1.2 Sprint Planning and Execution

Duringthesprinttheteamrefinestheirunderstandingoftheselecteduserstoriesandworkstoensurethattheyarecompletedwithinthedefinedtimelimitofthesprint.Assprintsareexecuted,theteammeetsonceperday(referredtoasthedailyscrumorstand‐upmeeting)tobrieflydiscusswhattheyareworkingonandidentifyanyimpedimentsthatmaypreventthemfromcompletingtheirwork.Attheendofthesprint,theteamdeliversworkingandtestedsoftwarethatfullyimplementsthesprint'suserstories.Thesprintisthencompletedwithacustomerreviewandaretrospective.Duringthecustomerreview,thesoftwareisdemonstratedandthecustomerprovidesfeedback.Duringtheretrospective,theteammeetsandcollaboratestofindwaystoimproveboththeproductandtheirprocessesusedtodelivertheproduct.Boththecustomerreviewandtheretrospectivemayidentifyadditionalitemsthatfeedintotheproductbacklog.Theseitemsarethenusedtore‐prioritizetheproductbacklogforthenextsprintplanningsession.

Thefollowingillustrationdemonstratesatypicalscrumlife‐cycle.

FIGURE 2.1 Scrum Life-cycle


Scrum Business Analysis in Agile Approaches


2.1.3 Roles and Responsibilities

InScrum,therearethreeroles:

• ProductOwner:Theproductownerprovidestheoverallvisionanddirectionoftheproduct.Theyareresponsiblefordefiningtheproductbacklogandperformbacklogprioritizationaccordingtocustomervalue.

• ScrumMaster:Thescrummasterensurestheteam'sScrumprocessesarefollowedandtheteamfunctionswellthroughcollaborationandfacilitation.Theymanageanyimpedimentsthatmaypreventtheteamfromaccomplishingworkandshieldtheteamfromexternalinterferences.

• TheTeam:Theteamisresponsiblefordevelopinganddeliveringtheproduct.Theycollaboratewiththeproductownertodeterminewhatuserstorieswillbedeliveredinasprintandcommittodeliveryoftheuserstories.

2.1.4 Business Analysis in Scrum

WhileScrumfocusesonvaluedrivendevelopmentitdoesnotaddressbusinessanalysisactivitiesindetailandmanyoftheseactivitiesoccurasimplicitstepsinthescrumframework.Thefollowingillustrationshowsthetypicalscrumlifecyclewithbusinessanalysistechniquessuperimposed.

FIGURE 2.2 Business Analysis in Scrum


Business Analysis in Agile Approaches Extreme Programming (XP)


Theproductbacklogisbuiltthroughacombinationofenterpriseanalysiswork(identifyinggapsandnewcapabilitiesrequiredtoaccomplishorganizationalgoalsanddefiningtheirvaluetotheorganization)andsolutionassessmentandvalidation(identifyingwaysinwhichtheexistingsolutioncanbeenhancedtobetterdeliverbusinessvalue).Withinasprint,businessanalysisactivitiesfocusonelicitingtherequirementsforthesprintbacklogitemsbeingworkedandtheacceptancecriteriaforthoseitems.Thisapproachisfrequentlyreferredtoasjust‐in‐timerequirementselicitation;developingonlywhatisrequiredforthecurrentsprintandonlydonetothelevelofdetailrequiredtoenabletheteamtobuildtheproductandacceptancecriteria.

2.1.5 Techniques• BacklogManagement:Backlogmanagementistheprimarymethodofhandlingbothrequirementsprioritizationandchangemanagementinmostagileapproaches.

• Retrospectives:Retrospectivesareacommonpracticeusedbyagileteamsseekingtoimprovetheirwaysofworking.Businessanalystsshouldlookforfeedbackontherequirementstheyprovidetotheteamandhowandwhenthoserequirementsareprovidedinordertofindwaystoimprovetheirprocesses.

• MoSCoWPrioritization:MoSCoWPrioritizationisusedtoprioritizestories(orotherelements).MoSCoWprovidesawaytoreachacommonunderstandingonrelativeimportanceofdeliveringastoryorotherpieceofbusinessvalueintheproduct.

2.2 Extreme Programming (XP)ExtremePrograming(XP)beganbeingusedbydevelopmentteamsinthemid‐1990s.Likeotheragileapproaches,XPisiterativeinnatureandprovidessmallreleasesattheendofeachiteration.XP'sprimaryfocusisontheengineeringaspectsofagilesoftwaredevelopmentandisbasedon12practicesinfourcategories.


Extreme Programming (XP) Business Analysis in Agile Approaches


TABLE 2.1 Extreme Programming Categories

2.2.1 User Stories

XPusestheconceptofuserstoriesasacentralmechanismtodefinerequirements.Theyarecreatedbyusersofthesystemtodefinefeaturesandfunctionalitytobeincludedinthesolutionanddonotcontainahighlevelofdetail.Eachuserstoryisnormallyaccompaniedbyalistofacceptancecriteriawhichidentifyspecificdetailsaboutthestory.

Storiesareusedto:

• prioritizeworkintoiterations,• identifyriskassociatedwitharequest,• estimatetheeffortrequiredtodelivertherequest,and• establishaconversationbetweentheteamandtheproductowneraroundthesubjectoftherealbusinessneed,inordertoconfirmacommonunderstandingofwhathastobedone.

2.2.2 Release Planning and Execution

XPreliesonthreelevelsofplanning:

• releaseplanning,• iterationplanning,and• dailyplanning.

Releaseplanningidentifiesthenextsetofusablefeaturesthatcouldmakeuparelease.Thereareoftenseveraliterationsworthofworkbeforetheproductisrelease‐ready.Iterationplanningservestoplan

XP Categories

Fine Scale Feedback

Continuous Process

Shared Understanding

Programmer Welfare

XP Practices

• Pair Programming

• Planning Game• Test Driven

Development• Whole Team

Testing

• Continuous Integration

• Re-factoring• Small

Releases• Coding

Standards

• Collective Code Ownership

• Simple Design• System

Metaphor

• Sustainable Pace


Business Analysis in Agile Approaches Extreme Programming (XP)


eachincrementaliterationthatwillultimatelyresultinareleasableproduct.Finally,indailyplanningtheteamplansouteachday'sactivitiestoensuretheteamisonscheduleandidentifyrisksthatmayhavearisen.

InXP,releaseplansareusedtotrackanddescribewhatfeaturesorfunctionalityistobedeliveredineachproductrelease.ThereleaseplanissimilartotheconceptoftheproductbacklogintheScrumframework.Iterationplanningmeetingsarethenusedasavehicleforteamcollaborationinplanningthecomingiteration.Astheteamworkstoscheduletherelease,theuserstoriesareorderedbasedonthemostimportantfeaturestothecustomer,ensuringthatthemostimportantfeaturesarealwaysdeliveredfirst.Storiesaredecomposedintotheirgranularfunctionalrequirementsinatechniqueknownasstorydecomposition,onajust‐in‐timebasis.Then,throughstoryelaboration,theteamidentifiesthedetaileddesignandacceptancecriteriaforthestory.

Whileaniterationisunderway,XPisalsosimilartoScruminthatitutilizesdailymeetingsasthekeycommunicationvehiclefortheteam.Thisdailystand‐upmeetingisusedtofacilitatedailyplanningactivitiesandreviewprogresssincethepriorday'sstand‐up.Inpractice,teamsemployingtheXPapproachfrequentlycombinesuchelementsascadence,roles,andceremonies(suchassprintplanningandsprintreviews)fromtheScrumframework.

ThefollowingdiagramprovidesanoverviewoftheXPmodel.

FIGURE 2.3 ExtremeProgrammingModel


Extreme Programming (XP) Business Analysis in Agile Approaches



InExtremeProgramingtherearefourkeyroles:

• Customer:Thecustomercreatesandprioritizestheuserstoriesandperformsriskanalysis.

• Developer:Thedevelopercommunicatesdirectlywiththecustomerandbuildsonlywhatisnecessarytodeliveroneachiteration.

• Tracker:Thetrackerkeepstrackofthescheduleandthemetrics.• Coach:ThecoachguidesandmentorstheteaminapplyingXPpracticeseffectively.

2.2.4 Business Analysis in XP

WhileXPdoesfocusonvalue‐drivendevelopment,itdoesnotexplicitlyaddressbusinessanalysisactivities.XPreliesonthefundamentalassumptionthatthecustomerroleisfilledbyasmallnumberofpeoplewhoknowwhatthemostvaluablefeatureswillbe.WhenXPisappliedatalargerscale,orwithcustomerswhodonothaveaclearvisionoftheincrementalvalueoffeatures,abusinessanalystaddssignificantvalueinfacilitatingandnegotiatingwithstakeholderstoreachasharedunderstandingofwhatthemostvaluabledeliverableswillbe.Abusinessanalystcanalsocontributebyfacilitatingstorymapping.

IntraditionalXP,theuserstoriesarecreatedandmanageddirectlybythecustomer.Thiscanleadtounfilteredrequirementsthatareatriskofconstrainingasolutionwithoutconsiderationforrootcauseorapplicabilitytoothercustomergroups.Businessanalysisskillscanbeusedtoensureunderlyingproblemsarebeingaddressedinawaythatworksformost,ifnotall,ofthestakeholdersontheproject,aswellasensurethoroughacceptancecriteriahavebeencollectedforeachuserstory.Onprojectswherethereisadedicatedbusinessanalysttheyoftenperformstorydecompositionandelaborationactivities.

2.2.5 Techniques• UserStory:Userstoriesidentifywhichrolesinthestoryprovidevalueandthereforeidentifiesthestakeholderswhocanelaborateonthatvalue.


Business Analysis in Agile Approaches Kanban


• StoryMapping:Storymapsshowrelationshipsbetweenuserstoriesandlargeractivitiesthattheusermustbeabletoaccomplish.

• StoryDecomposition:Epics,features,orminimallymarketablefeatures(MMF)tiegroupsofuserstoriestogetherintolargerpackagesthatcanbediscussedwithstakeholders.

• StoryElaboration:Definesthedetaileddesignandacceptancecriteriaforauserstoryonajust‐in‐time/just‐enoughbasis.

2.3 KanbanScrumandXPareframeworksthatdefinesetsofroles,ceremonies,andpracticesforproductdelivery.Inthecontextofsoftwaredevelopment,Kanbanisanapproachformanagingtheflowofworktoallowforevolutionarychange.WithrootsintheTheoryofConstraintsandLeanproductdevelopment,Kanbanhasfivekeyprinciples:

• visualizethework,• limitworkinprocess,• focusonflow,• makeprocesspoliciesexplicit,and• continuallyimprove.

Unliketheotheragileframeworksthatwehavediscussed,Kanbandevelopmentdoesnotrequirefixediterations.Workmovesthroughthedevelopmentprocessasacontinuousflowofactivity.AkeyfeatureofKanbanistolimittheamountofworkunderwayatanyonetime(referredtoastheWorkinProgressLimitorWIP).Inthisapproachtheteamworksonlyonafixednumberofitemsatanyonetimeandworkmaybeginonanewitemonlywhenitisrequiredtomaintainflowdownstreamandafterthepreviousitemhasbeencompleted.

2.3.1 Queues

Kanbanreliesontheuseofworkqueuestomanagetheflowofactivitiesthatmusttakeplacetodeliveraworkingproduct.Theformatandcontentforworkqueuesislessprescriptiveinthisapproachthanotherswehavelookedat.Thequeueshouldonlydescribetheworktobecompletedinrelativeprioritytodelivertheproduct.Forthisreason,theKanbanapproachisoftencombinedwith


Kanban Business Analysis in Agile Approaches


approachessuchasScrumwherethebacklogisusedastheimplementationforthequeue.Whenanewfeaturerequestisreceived,itisassessedforrelativepriorityandurgencyandthenplacedintothequeueinitsrelativeposition,maintainingtheorderbypriority.

AnalogoustotheScrumtechniqueofmanagingtheproductbacklog,theteamevaluatesthefeatureswaitingintheinputqueuetoseeiftheyaretoolargeoroutofscopefortheupcomingrelease.Foritemsthataretoolargetobecompletedbeforeaplannedreleasedate,theprojectteamwillbreaktheitemdown(decomposeit)intosmallerchunksofwork,decidingwhichwillbeincludedinthereleaseandwhichwillnot.Theteamthenreassessesthepriorityoftheitemsinthequeueandreordersthemasneededtomaintainacontinuous,prioritizedflowofwork.


Kanbandoesnotincludedefined,mandatedrolesorbusinessanalysispractices.Likeanyagileapproach,itstrivestobreakdownworksuchthatindividualworkitemscanbeimplementedinarelativelyshortperiodoftime.TheKanbanapproachalsoattemptstobringtheprojectteamtogetherbyincreasingcommunicationandcollaboration,enablingtheteamtoworktogetherasacollectiveandcohesiveunit.

2.3.3 Business Analysis in Kanban

Businessanalysis,likeallactivitiesintheKanbanapproach,occursinaconstantandcontinuousflowthroughthelifeofaproject.Inordertomaintainaprioritizedqueueofworkbusinessanalysistechniquesareusedtoelicitnewproductfeatures.Requirementsanalysispracticesarethenusedtoprioritizetherequirementsbasedonbusinessvalue,whilealsocontinuouslyusingbusinessanalysistechniquesforscopingtheproductandmanagingthequeueofrequirements.

WhenplanningandmanagingtasksintheKanbanapproach,ServiceLevelAgreements(SLAs)areusedtomaintaintheestimatesforhowlongafeatureorchunkofworkwilltaketobecompleted.InKanban,thisestimateincludestheplanningandanalysisactivitiesthattakeplacebeforesoftwaredevelopmentbegins.Thisapproachforcesabusinessanalysttofocusonplanningandmonitoringactivities,enablingconstantrevisionandrefinementofestimatesaseachnewrequestenterstheanalysisportionofthecycle.InaKanbanproject,


Business Analysis in Agile Approaches Levels of Planning in Agile Approaches


thebusinessanalystonlybeginstodefinerequirementsforanewworkitemwhenthequeuestepsforward.Atthatpointthedevelopmentteambeginstoworkononeofthecompletedrequirementswhilethebusinessanalystbeginscollectingrequirementsforthenextiteminthequeue.Byopenlyandvisiblymanagingtheworkoftheprojectteam,inefficiencieswillsurfaceasprocessimprovementopportunities.Thiswillhelptomitigatetheriskrelatedtothetimingofbusinessanalysisactivities,enablingthebusinessanalysttomanagetheriskearlyintheprocess.

2.4 Levels of Planning in Agile ApproachesDuetothefluid,dynamicnatureofagileapproaches,itisimportanttounderstandwhenandhowtoapplydifferentplanningtechniquesandtheappropriatelevelofdetailforeachlevelofplanning.Itisimportanttonotethatmanyofthetechniquesusedinanagileenvironmentaresimilartotraditionaltechniques;whatisdifferentishowandwhenthesetechniquesareapplied.Just‐in‐timeandjustenoughrequirementsthatareconsistentlyvalidatedbythebusinessarecentraltotheanalyst'sroleinagileapproaches.

Whenundergoingplanningexercisesintheagileworld,itishelpfultoconsiderhowtheanalyst'srolediffersfromplan‐drivendevelopmentapproaches.Inagiletheroleoftheanalystiscentraltothevalueoftheproject.Theanalystholdsakeyroleinmaximizingvaluebyfacilitatingtheinteractionswithalltheprojectstakeholders.Exceptionallyhighcommunication,facilitation,andnegotiationskillsareanimportantsetoftoolsforanalystsintheagileenvironment.

Successfulagileprojectsfollowaconsistentplanningcadenceof

• strategy,• release,• iteration,• daily,and• continuous.

Throughthiscadence,therequirementsfortheprojectareprogressivelyelaboratedtoanappropriatelevelofdetail.Ateachstepstableconceptsarecaptured,contextiscaptured,andlearningopportunitiesareidentified.Oneofthekeytenetsofagileistoperformasufficientlevelofanalysisateachplanninglevel.Toomuchanalysis


Levels of Planning in Agile Approaches Business Analysis in Agile Approaches


upfrontcanresultinthecreationofdocumentsthataresubjecttochange,requirethebusinessusertoexplaintheirneedsmultipletimes,andmaynotbenecessarytoachievethegoalsoftheproject.Toolittleanalysisupfrontcanresultinirresponsiblecommitments,rework,andalackoffocusoncustomervalue.Mostagileteamsfocusondailywork,iteration,andreleaseplanning.

FIGURE 2.4 AgileLevelsofPlanning

2.4.1 Strategy Planning

Projectsandproductdevelopmenteffortsstartwithavisionofthebusinessdirectionorneed.Thevisionincludesthewhat,why,andsuccesscriteriafortheeffort.Thevisionisoftenassociatedwitharoadmap.Theroadmapincludesthehigh‐levelscopeandmayincludeaninitialarchitecture.Inadditiontoactivitiessuchasestablishingavision,scope,androadmap,thestrategyworkonanagileprojectincludestheinitialcreationofafeaturerequestlist.Forexample,inScrumthisentailsseedingtheinitialrequestsinaproductbacklogor,inXP,userstories.Thisisanalogoustopre‐projectelicitationofbasicstakeholderrequirementsthatareusedtofacilitatediscussionsonscopingandphasinginplan‐drivenprojects.




Atastrategiclevel,thepersonwhoownstheproductorisleadingtheinitiativehelpsthedeliveryteamto

• identifythedesiredbusinessvalue,• definethebusinesscontext,• definethecontextofthesolutionneeded,• identifyandoutlinesthestepstorealizethevisionwiththedeliveryteam,

• identifytheprincipleswhichshouldbeusedwhenprioritizingwork,and

• definetheproductroadmap.

Strongenterprisebusinessanalysisskillsarerequiredtoeffectivelyplanastrategyforanagileproject.Insomeways,youcouldarguethattheseskillsbecomemoreimportantinagileapproaches.Thisisbecausewithoutdirectionbasedonbusinessvalueandaclearlydefinedscopeandaudience,agileprojectsareatriskfordeliveringincrementalfeaturesthatnevercometogethertocreateend‐to‐endvalueforanyonecustomergroup.Withoutaroadmapandsuccesscriteriafortheproduct,agileprojectscouldconceivablygoonforever,wastingtime,money,andotherresourcesintheprocess.

2.4.2 Release Planning

Releaseplanningistheactivityinwhichthepersonwhoownstheproductgroupsactivitiesandallocatesthemtoteams.Teamsworkondefiningenoughdetailtoresponsiblycommittosomerangeofscopefortherelease.Whenconsideringrelease,teamsconsiderbusinessconditionsandoperationalreadiness.Teamsshouldreleasewhenthebenefitsofdeliveryoutweighthecostsassociatedwithrelease.Thereleaseisdefinedbyadate,strategictheme,andplannedfeatureset.Releasedatescanbelinkedtoevents,likeconferencesorcompliancerequirements.Inreleaseplanningthetargetscopeisagreeduponandtheprioritizedlistoffeaturerequests,suchasaproductbacklog,isusedasthebasisforplanning.

2.4.3 Iteration Planning

Manyagileteamsworkinfixedtimewindowscalledsprintsoriterations.Aniterationplanningeventisheldat,orshortlybefore,thestartofeachiteration.Priortothatiterationplanningmeeting,theitemsinthefeaturerequestlistthatarebeingconsideredforthe




iterationneedtobesufficientlyunderstood,thusenablingtheteamtoresponsiblymakeacommitment.InScrumthisisknownasgroomingthebacklog.IncontinuousflowmodelslikeKanban,thefeaturerequestlistisstillgroomedbeforeitiscommitted,buttheplanningcadenceisbasedondemand,notonadefinedtimeperiod.Onsometeams,thecustomerorowneroftheproductcollaborateswiththedeliveryteamtogroomtherequestlistpriortoiterationplanning,whileotherteamsuselow‐fidelityspecificationsdevelopedduringworkshopsheldpriortoiterationplanning.Thisworkiscomprisedofrequirementcommunicationandanalysis,withadditionalelicitationanddocumentationasneeded.

Initerationplanningtheworkthatwillbeperformedinthesprintisidentified,estimated,reviewed,andcommittedtobecompleted.Thedeliveryteammeetswiththecustomerortheowneroftheproducttounderstandtherequirementsandacceptancecriteria,andtogainclarityonspecifications.Thisisanalogoustotheworkinaplan‐drivenprojectwherethebusinessanalystcommunicatesrequirementstostakeholders.Attheendofiterationplanning,thedeliveryteamcommitstodeliveringanincrementofworking,tested,anddeployablecode.

Afteraniterationhasbeencompletedaniterationrevieworproductdemonstrationisheld.Theresultsoftheproductdemonstrationfeedintothenextcycleofiterationplanning.Theproductdemonstrationmeetingissimilartolight‐weightuseracceptancetestingandisgenerallylimitedtoamaximumof4hours.

Duringtheproductdemonstration

• thedeliveryteamdemonstrateshowthecodethatwasdevelopedmeetstheacceptancecriteria,

• theowneroftheproductdetermineswhichitemsonthefeaturelisthavebeencompletedintheiteration,

• anynewrequeststhatarisefromthecustomerasaresultofviewingthelatestproductareaddedtothefeaturerequestlist,and

• theowneroftheproductanddeliveryteamreviewthestateofthebusiness,themarket,andthetechnology,andre‐prioritizethefeaturerequestlistforthenextiteration.

Aftertheiterationreviewmeetingtheprocessstartsupagain.Whileaworkingproductistheexpectedoutputofeachiteration,manyagileteamswillwaittoreleaseaproductuntilseveraliterationsworthofworkhavebeencompleted.Theteammustdeterminetheappropriatetrade‐offpointbetweenthecosttodeliverthelatestproductandthe




amountofneworimprovedfunctionalitythatwillbedeliveredtothecustomerbase.Iterationsproceeduntilenoughfeatureshavebeendonetocompleteorreleaseaproduct.

2.4.4 Daily Work Planning

Manyagileteamsperformdailyteammeetingstocoordinatethework.Thedailymeetingisusuallyafifteenminutemeetingdesignedtoclarifythestateofthework.

Duringthedailymeetingtheteam

• getsaglobalsnapshotoftheproject,• discoversanynewdependencies,• addressesanypersonalneedsofcommittedindividuals,and• adjuststheworkplantomeettheneedsofthedayandensuretheteamcandeliverontheiterationcommitment.

Frequentlythedialogueheldduringthismeetinguncoversitemsthatlackclarityorrequirefurtheranalysis.Theteamthenidentifiesaplanfordealingwiththeseimpedimentstotheproject.Thisoftenentailsassigningsomeonetodofurtherbusinessanalysisworkforelicitationandanalysisontheimpactedrequirements.

2.4.5 Continuous Activity Planning

Therearemanydynamicactivities,efforts,andchallengesthatariseduringtheplanningactivitiesofagileprojects.

Herearesomeguidingprinciplesthatthoseconductingbusinessanalysismayfindhelpful:

• Startwithvalueandkeeptheteamtruetovalue.Itisvitalthattheindividualholdingthebusinessanalysisroleispayingcloseattentiontotheproject'sbusinessvalue.

• Low‐fidelityartifactsserveasanenablerofbusinessvaluebycreatingcontextandgeneratingsharedunderstanding.However,theydonotreplace,oreventakeprecedenceovereffectivecollaborationandconversation.

• Businessanalysisisaboutfacilitatingdiscussionandunderstanding.Businessanalystsmaynotpossessthedepthof




understandingaboutthebusinessasdoesthebusinesssponsor,orasmuchabouttechnologyasthetechnologyteam.

• Operateinthebestinterestofthebusinessovertime.Responsiblybalancevalueandcapacitytodeliver.

• Identifyandcommunicatecompetingconcernsandgapsinunderstandingbetweenthebusinessandtechnology.Ensurethatcommonunderstandingisreached.

• Resourcesarelimitedandvaluable.Alwaysassistinmaximizingvalueovertime.

• Assisttheteamtotakeaction.Effectivelycommunicatewhatisrequiredwhentakingthenextsteps.Ensurethatfeedbackisclearlyunderstoodandactedonbytheteam.

• Deliverincrementallyanditeratively.Dothesmallest,simplestthingthatcouldpossiblywork.Iteratetoreachminimalvalue.Progressivelyelaborateinsmallpieceswhiletestingassumptionsandarticulatingclearacceptancecriteria.

• Producethesmallestamountofdocumentationthatmeetstheneedsoftheteamanddeliveritjustintime.



Mapping Agile Techniques to the

THREEChapterBABOK® Guide

ThefollowingareasofknowledgerepresentaselectionofpopularagilebusinessanalysistechniquesidentifiedthroughthedevelopmentoftheAgileExtensiontotheBABOK®Guide.ManyofthebusinessanalysistechniquesdescribedintheBABOK®Guidecontinuetobeusableinanagilecontext.Inaddition,theremayalsobeothertechniquesnotlistedhereorintheBABOK®

Guidethatmayprovetobeusefulandapplicableinaparticularsituation.TechniquesnotlistedintheAgileExtensiontotheBABOK®Guideshouldnotbediscreditedasvaluableinthecontextofperformingagilebusinessanalysis.

InthefollowingsectionwefocusourattentiononcommonbusinessanalysistechniquesapplicabletoagilethataresupplementaltothosedescribedintheBABOK®Guide.TheagiletechniquesthataremappedtoBABOK®KnowledgeAreasinthischapterareexplainedingreaterdetailinChapter4:Techniques.

3.1 Business Analysis Planning and MonitoringBusinessAnalysisPlanningandMonitoring(Chapter2oftheBABOK®Guide)describestheworkrequiredforabusinessanalysttodeterminetheactivitiesthatwillberequiredtoperformbusinessanalysisthroughthelifecycleofaproduct.Inagileapproaches,businessanalysisplanningcanbedoneup‐frontordeferreduntilworkonanactivityisreadytobegin.Somebusinessanalystswilldevelopaninitialplan,whichgetsupdatedpriortostartingeachnewactivitytoaccountforchangeandensuretheplanisalwaysuptodate.

3.1.1 Plan Business Analysis Approach (2.1)

Agileapproachesfallintothegeneralcategoryofchange‐drivenapproachesasdescribedintheBABOK®Guide.Somebusinessanalysisworkwillgenerallybeperformedupfronttodefineavisionfortheprojectandhowtheproblemoropportunitywillbeaddressed,butdetailedanalysiswillbeperformedas‐


Business Analysis Planning and Monitoring Mapping Agile Techniques to the BABOK® Guide


needed.Iftheproblemsthesoftwareissupposedtosolveareunclear,orseveralstakeholdergroupshaveconflictinginterests,itmaybenecessarytodobusinessanalysisworkpriortothebeginningofaproject.Thatup‐frontanalysiswillprovideabetterunderstandingofunderlyingproblems,theirdrivers,andthegoalsofthestakeholdersinordertoreachagreementonthevisionfortheproduct.Thisincludesasharedagreementontheproblemoropportunitytheproductisintendedtoaddress.Asaresult,theremaybeplannedbusinessanalysisactivitiesthataredefinedinthepre‐projectphase,inadditiontothebusinessanalysisactivitiesthataredefinedforeachcycleofwork,suchasforaniteration.

.1 Agile Techniques• BacklogManagement:Backlogmanagementistheprimarymethodofhandlingrequirementsplanning,prioritization,andchangemanagementinmostagileapproaches.Becausethebacklogoftendescribesthebreakdownofrequirementsintherelativeorderinwhichthefeaturesshouldbeimplemented,itcanserveasadescriptionfortheorderinwhichbusinessanalysisactivitieswilltakeplace.Somebacklogsalsoincludebusinessanalysisactivitiesastaskstobecompletedinadevelopmentcycle.

• PlanningWorkshop:Businessanalystsparticipateinplanningworkshopstodeterminethebusinessanalysiseffortandactivitiestosupportateamobjective.

• RealOptions:Realoptionanalysismayhelpdeterminewhenbusinessanalysisneedstobeconductedtoinvestigateaparticularbusinessissue.

• Retrospectives:Thefeedbackfrompriorretrospectivesshouldbeconsideredwhenselectingtheapproach.


Mapping Agile Techniques to the BABOK® Guide Business Analysis Planning and Monitoring


3.1.2 Conduct Stakeholder Analysis (2.2)

Stakeholdersmaybechallengedbytherapid,iterativedevelopmentfoundinanagileprojectandtheneedtobeoncallwheneverinformationisneededbytheteam.Inagiledevelopment,businessanalystsneedtoconsidertheimpactoftheagilecadenceonthestakeholderandhowthingslikeprogresselaborationwillaffectexpectations.Businessanalystsneedaskquestionssuchas,canthestakeholderparticipateinupdatingtheprocesses,interactions,andproductspecificationsduringthecourseoftheproject?Prototypingandfrequentfeedbackfromstakeholderscanhelptorefinewhatisknownabouttheneedsofastakeholderorstakeholdergroup

.1 Agile Techniques• CollaborativeGames:Manycollaborativegamescanbeusedtounderstandtheperspectivesofvariousstakeholdergroups.

• Personas:Personascanhelptheanalystordevelopmentteambyenablingthemtobetterdescribeandvisualizetheneedsofagrouporarchetypeofstakeholders,understandinghowthearchetypewillderivevaluefromasolution,potentialrisksforthearchetype,andotherinformationthatwillhelptheteamtobetterunderstandtheneedsofthestakeholdergroupsinvolvedwiththeproject.

3.1.3 Plan Business Analysis Activities (2.3)

Businessanalysisactivitiesareplannedasneeded,usuallyatthestartoftheprojectandrefinedwitheachiterationorwhenanewworkitemisreadyforanalysis.Thebusinessanalystshouldalwaysbeawareofandpreparedtoaddressthenextiterationofwork,keepingthevisionfortheproductandevolutionofincrementalvalueinmind.Thereislessofafocusonformaldocumentation(althoughitstillcanberequiredtomeetstatutoryorregulatoryrequirements,ortocaptureknowledgedevelopedduringtheanalysisanddevelopmentprocess)andmorefocusonprogressiveelaborationofdocumentationthroughoutthelifeoftheproject.Also,muchoftheelaborationisreplacedbyinteractionsandceremonysotheseoutcomesneedtobeaccomplishedwithactivitiesaddressedinthecommunicationplan.

.1 Agile Techniques• PlanningWorkshop:Decisionsregardingbusinessanalysisactivitieswillusuallybemadeduringaplanningworkshop.


Business Analysis Planning and Monitoring Mapping Agile Techniques to the BABOK® Guide


3.1.4 Plan Business Analysis Communication (2.4)

Duringdevelopment,formalcommunicationofrequirementsisgenerallyreplacedwithad‐hocinformaldiscussionsandmodeling.Somedeliverablesarereplacedbyspecificinteractionsorceremonies.Bydefinition,theseinteractionsandceremoniesrequirereal‐timeparticipationbythebusinessanalyst.Formaldocumentationmaybedevelopedfollowingdevelopmentofthesoftwaretoensureknowledgeretentionbytheorganizationortomeetregulatoryrequirements.

.1 Agile Techniques• Personas:Thesemayproveusefulinassessingtheneedsandavailabilityofthestakeholdergroupsforthenecessarycommunicationinanagileapproachandhowyouwillorganizethisagilecommunication.

• PlanningWorkshop:Theplanningworkshopisgenerallyusedastheforumforestablishinghowtheteamwilloperate,includingdecisionsabouthowtheresultsofbusinessanalysisactivitieswillbedeliveredandcommunicatedtotheteamthroughoutthecourseoftheproject.

3.1.5 Plan Requirements Management Process (2.5)

Inagileapproaches,requirementsmanagementisfocusedonensuringthattheintakeofnewworkbytheteammatchestheprioritiesofthestakeholdersand/orsponsor,anddeliversvaluetothebusiness.Agileapproachesstresstheimportanceofwelcomingchangingrequirements.Thismeansthattheorderingofworkitemsthatarereadyfordevelopmentmaybechangedatanytime.

.1 Agile Techniques• BacklogManagement:Mostagileapproachesusebacklogmanagementtodeterminewhichrequirementsarereadytobeworkedonbythedevelopmentteam.


Mapping Agile Techniques to the BABOK® Guide Elicitation


3.1.6 Manage Business Analysis Performance (2.6)

Thisactivitywillbeperformedonanongoingbasisasthebusinessanalystlearnstoworkeffectivelywithstakeholdersandthedevelopmentteam.Aseveryoneinvolvedbetterunderstandshowtoworktogethertodelivervalue,thebusinessanalysisprocess,methods,ortechniquesinusemayneedtochange.Effectivebusinessanalysisperformancewillresultinlimitedreworkoftherequirementsdocumentation,effectiveprioritizationandscopingofrequirements,andclearcommunicationofneedtothedevelopmentteam.

.1 Agile Techniques• Retrospectives:Retrospectivesareacommonpracticeusedbyagileteamsseekingtoimprovetheirwaysofworking.Businessanalystsshouldlookforfeedbackontherequirementstheyprovidetotheteamandhowandwhenthoserequirementsareprovidedinordertofindwaystoimprovetheirprocesses.

• ValueStreamMapping:Valuestreammappingcanbeusefulinassessinghowbusinessanalysisactivitiesarecontributingtothedeliveryofvaluetothecustomerandidentifyingactivitiesthatmaynotbeaddingvalue.

3.2 ElicitationElicitation(Chapter3oftheBABOK®Guide)describeshowbusinessanalystsworkwithstakeholderstoidentifyandunderstandtheirneedsandconcernsandunderstandtheenvironmentinwhichtheywork.Effectiveelicitationensuresthatthestakeholders'actualunderlyingneedsareunderstood,ratherthanstatedorsuperficialdesires.Elicitationisongoingthroughouttheprojectandperformedinconjunctionwithanalysisactivities(ascomparedtotraditionalapproaches,whereitispossibletoperformelicitationasadistinctactivityorphase).

Onagileprojects,themostcommonpatternisaninitialelicitationactivitywhichlooksatthehighlevelneeds,goals,andscopeofthesolution.Ineveryiteration,thereismoredetailedelicitationfortheuserstorieswhichconstitutethebacklogitemsforthatiteration.


Elicitation Mapping Agile Techniques to the BABOK® Guide


3.2.1 Prepare for Elicitation (3.1)

Preparingforelicitationchangesduringthelifeoftheproject.Earlyon,itisdonebythebusinessanalysttocoordinatesupportingmaterialsandscheduleresourcestodefinethehigh‐levelrequirements.Duringthisphaseoftheproject,elicitationactivitieswillgenerallybestructuredasmoreexploratorysessionstounderstandunderlyingneeds,buildouttheinitiallistoffeaturerequests,anddeterminewhatismostvaluabletoworkon.Astheprojectprogresses,workiscoordinatedbyprioritizationofthebacklog.Thiswilloftenresultinmorestructuredanddirectedelicitationsessionsdesignedtounderstandlow‐leveldetailsofaparticularfeatureorrequirement.Stakeholdersmayworkdirectlywiththedeveloperstoelaboraterequirements.Inthatsituation,thedeveloperisperformingbusinessanalysisactivitiesfortheprojectandshouldbetrainedingoodbusinessanalysispractices.Wherethisisnotpossible,thebusinessanalystwilloftenactasaproxy.Thistaskrequirestheschedulingofresourcesandthecoordinationofinputstoalignwiththeprogressiveelaborationofthebacklog.

Inpreparationforelicitationactivities,itisrecommendedthatthebusinessanalystperformcustomerresearchandastakeholderanalysistounderstandtheneeds,wants,andpreferencesofthestakeholderstheywillbeworkingwith.Bytailoringelicitationdiscussionstothestakeholder,businessanalystscanmaximizetheefficiencyandvalueoftheelicitationsession.

.1 Agile Techniques• Personas:Personasmayprovideinsightintotheparticularneedsofastakeholderorthetechniquesthatwillbemosteffectiveinunderstandingthoseneeds.

• UserStory:Auserstorywillidentifytheroleforwhomthestoryprovidesvalue(andthereforeidentifythestakeholderswhocanelaborateonthatvalue).

• StoryMapping:Developingauserstorymapwithusersandotherstakeholderswillensurethestoriesimplementedinthesolutionwillcometogetherasacohesiveproductintheend.


Mapping Agile Techniques to the BABOK® Guide Elicitation


3.2.2 Conduct Elicitation Activity (3.2)

Elicitationactivitiesareconductedonafrequentbasisthroughouttheproject,possiblyevendaily.Earlyon,elicitationisperformedtodefinehigh‐levelrequirementsoravisionfortheproduct.Astheprojectprogresses,stakeholdersinteractwiththedevelopmentteamdirectlyduringiterationplanninganddevelopment.Theintentofallelicitationactivitiesistogeneratejustenoughdetailtoensurethattheworkathandisperformedcorrectly.Theseelicitationactivitiesoftenoccurinworkshopswithproductusersandotherstakeholderswhohaveavestedinterestinthefeaturesorrequirementsbeingdiscussed.

.1 Agile Techniques• BehaviourDrivenDevelopment(BDD):Stakeholdersmayfinditeasiertoarticulatetheirneedsbyprovidingexamplesratherthanthroughabstractmodels.

• CollaborativeGames:Collaborativegamesencourageparticipantsinanelicitationactivitytocollaborateinbuildingajointunderstandingofaproblemorasolution.

Note:Asmentionedabove,analysisisusuallyperformedduringelicitationsessions.MostofthetechniquesfoundintheAgileExtension,aswellasmanyofthetechniquesintheBABOK®Guide,aresuitableforthispurpose.

3.2.3 Document Elicitation Results (3.3)

Amajorvalueofdocumentationisthatitcanbeusedforlong‐termknowledgeretention.Agileapproachesaimtominimizethetimebetweenthedevelopmentofrequirementsandtheirimplementationinsoftware,reducingtheoverallvalueofthatdocumentationtotheteam.Recordsofelicitationactivitiesshouldbekepttoensurethatkeydecisionscanbeunderstoodatalaterdate,ortoensurethatregulatoryorgovernancerequirementsaremet.Itisimportanttonotethatdocumentationshouldnotbelimitedtopurelytextualartifactstorepresentrequirementsandcontextforrequirements.Visualizingrequirementsthroughmodels,mock‐ups,andprototypesanbeaquickmechanismforconveyingalargeamountofinformationaboutasolution.However,careshouldalsobetakenwhenusingvisualizationsthatmimicthesolution,asitisimportanttodefinerequirementswithoutunnecessarilylimitingthesolutionoptions.


Requirements Management and Communication Mapping Agile Techniques to the BABOK® Guide


.1 Agile Techniques• LightweightDocumentation:Seethissectionforguidelinesondevelopingdocumentation.Inmostcases,therewillnotbeseparatedocumentationoftheelicitationandanalysiswork.

3.2.4 Confirm Elicitation Results (3.4)

Thiswillbeperformedbytheteamduringiterationplanning,throughoutthedevelopmentiteration,andatcustomeracceptance.Thecustomermaychangetheirmindaboutsomespecificelementofastoryafterseeingtheresult.Thisfeedbackbecomesaninputintotheconductelicitationactivity.

.1 Agile Techniques• BehaviourDrivenDevelopment(BDD):Elicitationoutcomeswillfrequentlybecapturedintheformofacceptancecriteriathatwillbeusedbytheteamtoverifythatthesoftwaremeetsstakeholderneeds.Inbehaviourortestdrivendevelopment,examplesareoftenusedasthebasisforgeneratingacceptancecriteriathatcanbeusedtoconfirmelicitedrequirements.

• Retrospectives:Duringretrospectivesessions,theinformationthatwaselicitedmaybeconfirmedorrefutedbasedontheperspectivegeneratedwhenacustomerseestheproductinaction.Thismayresultinmodificationstothesolutionrequirements.

3.3 Requirements Management and CommunicationRequirementsManagementandCommunication(Chapter4oftheBABOK®Guide)describeshowbusinessanalystsmanageconflicts,issues,andchangesinordertoensurethatstakeholdersandtheprojectteamremaininagreementonthesolutionscope,howrequirementsarecommunicatedtostakeholders,andhowknowledgegainedbythebusinessanalystismaintainedforfutureuse.Thisisnotaone‐timeactivity,butisperformedcontinuouslythroughoutthelifeoftheproject.


Mapping Agile Techniques to the BABOK® Guide Requirements Management and Communication


3.3.1 Manage Solution Scope and Requirements (4.1)

Asagileprojectsunfold,thescopeisdefinedwithincreasingspecificity.Dependingontheagileapproachbeingused,thespecificdetailsofthescopecanbefoundintheproductbacklogorasimilardocument.Contentfortheproductbacklog,userstories,orotherrequirementsdocumentationmanagedintheseactivitiesisgeneratedthroughelicitationactivities,whicharementionedintheprevioussection.Basedonthelevelofelaborationtheproductbacklogitselfmayvaryinitsownlevelofdetail.Itshouldalsobeconsideredthatthesponsormaydecidetoterminatetheprojectshouldtheydecidethatfurthereffortswillnotprovideanacceptablereturnofbusinessvalue.

.1 Agile Techniques• BacklogManagement:Mostagileteamsusetheproductbacklogtomanagebothsolutionscopeandrequirements.

• StoryDecomposition:StoryDecompositionenablesplanningattheappropriatelevelofgranularityandsupportsthejust‐in‐timenatureofagileapproaches.

3.3.2 Manage Requirements Traceability (4.2)

Onagileprojects,everythingisconnectedbacktothestrategicthemes,epics,andstoriesthatareusedtodefinetheproject.Thisismaintainedbytheproductownerorthebusinessanalyst.

.1 Agile Techniques• StoryDecomposition:Whenstoriesaredecomposedintosmaller,moregranularpieces,retainingthelargerepicorfeatureandtieingthedecomposedstorytoitslarger,parentconceptcanhelpcreaterequirementstraceability.

• StoryMapping:Whilestorymapsprimarilyshowrelationshipsbetweenuserstories,indicatingaprocessorflowofactivities,theyalsomapuserstoriestolargeractivitiesthattheusermustbeabletoaccomplish.Assuch,storymappingcanserveasatooltoprovidetraceabilitybetweenrelatedstoriesandbetweenstoriesandthelargeractivitiestheysupport.


Requirements Management and Communication Mapping Agile Techniques to the BABOK® Guide


3.3.3 Maintain Requirements for Reuse (4.3)

Inmatureagileorganizationsthishappensmuchthesamewayasitdoesintraditionalefforts,wheredocumentationandprototypesareretainedforthefuturedevelopmentoftheprojectorreusedonsimilar,relatedefforts.Thedifferenceisinthewaythatrequirementsaredocumentedthroughoutthelifeoftheprojectorattheendoftheproject.Inadditiontoproductbacklogs,userstories,andotherstandardrequirementsdocumentation,thesourcecodeitselfisoftenwrittentobeself‐documenting.Informationregardingtherequirementsthecodesatisfiescanbeincludedinthenotesthedeveloperscreateforthesourcecode.

.1 Agile Techniques• UserStory:Awelldocumenteduserstorycanberetainedandre‐usedasastartingpointforfuturerefinementsoftheproductorsimilarneedsforanotherproduct.

3.3.4 Prepare Requirements Package (4.4)

Preparingtherequirementspackagecanbehandledthroughtechniquessuchasscenarios,usecases,acceptancetests,mock‐ups,andmodelsassociatedwiththethemes,epics,andstoriesusedtodefinetheproject.Thisisanongoingactivitythroughthelifeofthedevelopmentofthesolution.Thespecifictechniquesusedwilldependupontheapproachchosenatthebeginningoftheproject,andwillchangebasedontheemergentunderstandingofwhatworksbestinthecontextoftheproject.Releaseplanningoftenhelpstoguidehowrequirementsshouldbepackagedbyunderstandinghowtheteamisproposingtobundlefeaturesinplannedproductreleases.

.1 Agile Techniques• StoryDecomposition:Epics,features,orminimallymarketablefeatures(MMF)tiegroupsofuserstoriestogetherintolargerpackagesthatcanbediscussedwithstakeholders.


Mapping Agile Techniques to the BABOK® Guide Enterprise Analysis


3.3.5 Communicate Requirements (4.5)

Inagileprojectsrequirementsarecommunicatedtodevelopersonanon‐goingbasis.Requirementscommunicationmostoftenhappensinreleaseplanningmeetingswherethemesandstoriesarereviewedandselectedforrelease.Theyarealsodiscussedinmoredetailiniterationplanningmeetingswherethemodelsandspecificationsareselectedanddiscussedamongtheteamandtheproductowner.Intheseiterationplanningmeetings,risksarealsoreviewedanddiscussed.Additionally,dailyteammeetingsareoftenusedasanopportunityfordeveloperstogetclarificationoridentifyambiguousrequirements,wherethebusinessanalystcommunicatesthedetailsoftherequirementsorclarifiesambiguity.Modelsandvisualizationsforrequirementscanbeaquickwaytocommunicatedetailedrequirementsandfacilitateunderstandingoftheproblemthesolutionneedstosolve.

.1 Agile Techniques• PlanningWorkshop:Seethistechniqueforfurtherdetails.

3.4 Enterprise AnalysisEnterpriseAnalysis(Chapter5intheBABOK®Guide)describeshowbusinessanalystsidentifyabusinessneed,refineandclarifythedefinitionofthatneed,anddefineasolutionscopethatcanfeasiblybeimplementedbythebusiness.Thisknowledgeareadescribesproblemdefinitionandanalysis,businesscasedevelopment,feasibilitystudies,andthedefinitionofsolutionscope.Enterpriseanalysisisaboutidentifyingthebusinessneed,opportunityorproblemtobesolvedanddecidingontheappropriateapproachtoaddressingtheneed.

3.4.1 Define Business Need (5.1)

DefineBusinessNeed,asdescribedinBABOK®Guide,extendstoagileapproaches.


Enterprise Analysis Mapping Agile Techniques to the BABOK® Guide


.1 Agile Techniques• BusinessCapabilityAnalysis:Abusinessneedwillusuallycorrespondtothedevelopmentofanewcapabilityortheenhancementofanexistingcapability.

• CollaborativeGames:Somecollaborativegamescanbeusefulinexposingun‐metbusinessneeds.

3.4.2 Assess Capability Gaps (5.2)

AssessCapabilityGaps,asdescribedinBABOK®Guide,extendstoagileapproaches.

.1 Agile Techniques• BusinessCapabilityAnalysis:Thiscanbeusedtounderstandwhatshortcomingsexistinanexistingcapability.

3.4.3 Determine Solution Approach (5.3)

Agileisasolutionapproach.Itmaybeselectedinordertoprovideafasterdeliveryofvaluethantraditionalapproaches,orbecausetheproblemareaneedstobeexplored.Italsosupportsincrementaldeliverysothesolutionapproachcanbeevolvedoverthecourseoftheproject.Thisapproachprovidesflexibilityindeterminingthebestsolutiontoaproblemoropportunitybeingexplored.Asolutionmaybeginasacustomdevelopedevolutionaryprototype,thentransitiontoacustomizedCOTSsolutionorbecomeanintegratedpartofanotherproduct,forexample.Assuch,onagileprojectsthesolutionapproachcansometimeschangeduringthecourseofdevelopment.

.1 Agile Techniques• PurposeAlignmentModel:Thepurposealignmentmodelcanprovideguidanceregardingthebestsolutionapproachtotakeforagivenbusinessneed.

3.4.4 Define Solution Scope (5.4)

Thescopeofagileprojectsevolvesduringthecourseoftheprojectastheteamlearnsmoreaboutwaystosolvetheproblemandthecustomerpreferencesforasolution.Thescopeisdefinedinhigher‐


Mapping Agile Techniques to the BABOK® Guide Enterprise Analysis


levelabstractions(suchasthemesandepics)andisdetailedastheprojectevolves.Thesehigher‐levelabstractionsareimportantforscopingthesolutionandenablingtheteamtocomeupwithaninitialvisionforthearchitectureandreleaseplanfortheproduct.Thisisoftenaniterativeprocess,asscopemayberefinedbasedonwhatistechnicallyfeasibleinaninitialarchitectureassessment,impactingthereleaseplanandprojecttimelines.Similarly,thearchitectureplanmaybemodifiedorcontainaphasedapproachtobuildingouttheinfrastructurebasedontheplannedhigh‐levelrequirementsthatwillbedeliveredintherelease.

.1 Agile Techniques• BusinessCapabilityAnalysis:Thescopeoftheprojectshouldberelatedtothebusinesscapabilitiesitiscreatingorenhancing.

• StoryDecomposition:Epicsandfeaturescanserveasthebasisfordefiningthescope.

• StoryMapping:Astorymapcanbeusedtoseetherelationshipbetweenthevariousstoriesdeliveredbytheproject.

3.4.5 Define Business Case (5.5)

Thebusinesscaseforagileprojectsistypicallybasedonachievingaspecificbusinessoutcomewithinaspecifiedcostandtime.Thebusinesscaseisrevisitedfrequentlyastheteamlearnswhatitcandeliver,howwellitmeetsthereal(notperceived)needs,andwhetherthebusinessoutcomeandintendedvaluecanbeachievedwithinthespecifiedcostandtime.

.1 Agile Techniques• BusinessCapabilityAnalysis:Definesthecustomerandorganizationalvalueassociatedwithabusinesscase.

• KanoAnalysis:Identifieswhichproductfeaturesarelikelytohavethegreatestmarketimpact.

• PurposeAlignmentModel:Identifieswhatkindofinvestmentislikelytogeneratethegreatestvaluefortheorganization.

• RealOptions:Allowsassessmentofwheninvestmentneedstobemadeinordertoensurevalueisobtained.


Requirements Analysis Mapping Agile Techniques to the BABOK® Guide


3.5 Requirements AnalysisRequirementsAnalysis(Chapter6intheBABOK®Guide)describeshowbusinessanalystsprioritizeandprogressivelyelaboratestakeholderandsolutionrequirementsinordertoenabletheprojectteamtoimplementasolutionthatwillmeettheneedsofthesponsoringorganizationandstakeholders.Itinvolvesanalyzingstakeholderneedstodefinesolutionsthatmeetthoseneeds,assessingthecurrentstateofthebusinesstoidentifyandrecommendimprovements,andtheverificationandvalidationoftheresultingrequirements.

3.5.1 Prioritize Requirements (6.1)

Onagileprojectsrequirementsareprogressivelyelaborated.Inotherwords,throughouttheelicitationtaskelicitationresultsareprogressively,orcontinually,brokendownandelaborated.Thisissimilartotheconceptofcontinuousimprovement,wherethebusinessanalystcontinuallyelaboratesontherequirementstoprovideadditionaldetailasneededandidentifiesnewrequirementsthatareprioritizedbasedontheintendedprojectoutcomes.Ateachpointofelaborationtheconstituentpartsneedtobeevaluatedandprioritizedbasedonbusinessvaluecontributionandriskburn‐down.Inagilethisisnotaone‐timeupfrontactivity.Thishappensthroughoutthelifeoftheprojectonallremainingworkandnewworkbroughtinfromlearningabouttheproduct.

.1 Agile Techniques• BacklogManagement:Backlogmanagementisthestandardmethodofprioritizingrequirementsinmanyagileapproaches.Thebacklogcanbere‐prioritizedwheneverbusinessneedschangeorarebetterunderstood.

• KanoAnalysis:Kanoanalysiscanprovideinsightintotherelativeimportanceoffeaturestoausergroup.

• PlanningWorkshop:Prioritizationnormallytakesplaceduringaplanningworkshop.

Note:alsoseetheexpandedtreatmentofMoSCoWPrioritization.


Mapping Agile Techniques to the BABOK® Guide Requirements Analysis


3.5.2 Organize Requirements (6.2)

Duetothejust‐in‐time,continualnatureofrequirementselicitationanddocumentationactivities,itisimportanttothinkabouthowrequirementswillbeorganizedforanagileproject.Forexample,userstoriescanoftenshowupinmultipledocumentsthatarededicatedtotheuserstorythattheydescribe.Asaresultitcanmakefindingtheappropriaterequirementsacumbersomeactivity.Whiledocumentationonagileprojectsshouldbelightweight,itisstillimportanttohavearequirementsmanagementplanandmethodfororganizingrequirementsthatcanbeusedbyprojectteammembersandotherstakeholders.

Inagile,itcanbevaluabletoorganizerequirementstominimizedependenciesbetweenfeaturesets.Thisreducescomplexityandriskandimprovestestabilityatthebusinesslevelvalue.Organizingrequirementsaroundbusinessvalueandprogressivelyelaboratedrequirements,asopposedtotechnicalimplementations,resultsinthesolutionbeingarchitectedfromabusinessstandpoint.Exceptionsdoexistonprojectssuchascomponentteams,wherethebusinessvaluearisesfromdeliveringenablingtechnology.Eventhen,theserequirementsneedtobeprioritizedandfilteredbasedonriskburn‐downandbusinessvaluecontribution.Storymapswithinepicscanbeusedasamethodtoorganizerequirements.

.1 Agile Techniques• StoryDecomposition:Individualstoriesmaybeorganizedaroundanepicorfeature,wheretheepicsand/orfeaturesareusedastheorganizationalmethod.

• StoryMapping:Storymappingalsoshowshowindividualstoriesarerelatedtoorsupportoneanother.Thismaybeusedasamethodfordeterminingrelatedstoriesandorganizingthosestoriesandtheirassociatedrequirementsbasedonthoserelationships.

3.5.3 Specify and Model Requirements (6.3)

Atdifferentlevelsofelaborationtherearedifferentmethodsforspecifyingandmodelingrequirements.Theapproachshouldsupportprogressiveelaboration,beadaptabletochangebasedonlearning,andnotcausetheteamtoselectsolutionstooearly.Itshouldalsoensurethatintentandintendedbusinessvaluearecommunicated


Requirements Analysis Mapping Agile Techniques to the BABOK® Guide


consistentlythroughtheelaboration.Agileteamstendtousestoriesandtasksatthelowestlevelofdecomposition.Thesestoriesandtaskscanbesupportedbydetaileddocumentationandusecases.Itisbecomingincreasinglycommonforacceptanceteststobeproducedaspartofspecifyingandmodellingtherequirements.

.1 Agile Techniques• BehaviourDrivenDevelopment(BDD):Concreteexamplesoffunctionalitymayhelpstakeholdersbetterspecifyandunderstandtheirneeds,ordealwithspecificscenariosthatareofgreatervalue.

• Storyboarding:Usedtodescribeuserinterface(UI)functionalityandbehaviour.

Note:alsoseetheexpandedtreatmentofUserStoryinthisextension.

3.5.4 Define Assumptions and Constraints (6.4)

Onagileprojectsdefiningassumptionsandconstraintsishandledthroughariskmanagementapproach.Forexample,someagileteamstreatrisksasstorieswithinthemessothattheycanbetrackedwiththefeaturesorepicstheypertainto.Riskmitigationactivitieswouldthenbeprioritized,burneddown,andthenre‐prioritizedasthestoriesareperformed.Thisistypicallyproducedbytheindividualsperformingthebusinessanalystandprojectmanagerfunctions,alongwiththesupportoftherestoftheteam.Prioritizationwouldthenbeperformedbytheproductownerorsomeoneinananalogousrole.

.1 Agile Techniques• LightweightDocumentation:Assumptionsandconstraintscanbedocumentedinlightweightdocumentationthatiscreatedbytheprojectteamasitprogresseswiththeproject.

• Personas:Personascanbeusedasawaytotrackrisksassociatedwithaparticularusergrouporstakeholdertypethattheproductteamshouldbeawareofduringdevelopment.Personascanalsobeoptionallymodifiedtoincludeinformationregardinganyassumptionsmadeaboutastakeholdertypeduringthestakeholderanalysis.

• UserStory:Userstoriescanbemodifiedtotrackassumptionsorconstraints(particularlythelatter)relatedtoastory.Teamcanalsousetheuserstoryformatasawayofcollectingriskstobeaddressedbytheteamasanoutstandingworkitem,althoughit


Mapping Agile Techniques to the BABOK® Guide Requirements Analysis


needstobecleartotheteamandstakeholdersthattheseareseparatefromthestoriesplannedfordevelopment.

3.5.5 Verify Requirements (6.5)

Verificationensuresthatsomethinghasbeendesignedtospecificationandadheringtoqualitystandards.Forexample,verifyingthatauserstoryorotherrequirementsdocumentisproperlystructured,containstheappropriatefields,andcontainstheappropriatelevelofdetail.Requirementsareverifiedbytheteamthroughoutthecourseoftheproject.Throughretrospectivesandoperationsreviews,theteammaydecidetomodifythelevelofdetailoftherequirementsorthemethodofspecifyingandmodelingrequirementstoimprovetheperformanceoftheteam.Verificationofrequirementsusuallyisdonethroughdirectstakeholderinteractionwiththeteamasthesoftwareisdeveloped,elicitingdirectfeedbackfromtheteamduringretrospectives,dailyteammeetings,orothermeetingsorworkshops.

.1 Agile Techniques• Retrospectives:Retrospectivesproviderapidfeedbackonwhathasbeenbuilttoverifythatwhathasbeenbuiltwillmeetthedesiredbusinessoutcomes.

• StoryMapping:StoryMappingisatechniquethatenablesconfirmingthattheselecteduserstorieswillactuallydeliverthedesiredbusinessoutcomes.

3.5.6 Validate Requirements (6.6)

Validationensuresthatadeliverableorproductactuallyfulfillsitsintendedpurpose.Forexample,validatingthatauserstoryadequatelydescribesthebusinessprocessoractivitythatitisintendedtodescribe.Requirementsarevalidatedthroughoutthedevelopmentanddeliveryofthesolutionthroughcontinualinvolvementwiththecustomerand,whereapplicable,theproductowneroranalogousrole.Thishappensatmanypointsduringtheproject,suchasreleaseplanning,iterationplanning,duringdevelopment,andatcustomeracceptance.Prototypescanalsobeaneffectivewaytovalidatetheutilityoffunctionalityrelativetoitsintendedpurposebygivingausersomethingtotestandtryearlyindevelopmentwithproductreviewsessionstoobtainfeedbackfromtheusersontheevolutionoftheprototype.


Solution Assessment and Validation Mapping Agile Techniques to the BABOK® Guide


.1 Agile Techniques• BehaviourDrivenDevelopment(BDD):InBehaviourorTestDrivenDevelopment,examplesareusedasameansfordesignedrequirementsandestablishingacceptancecriteriathatcanbeusedtodesignthesolution.Theabilitytomeetthesereal‐worldexamplescanserveasameanstovalidatesolutionrequirements.

• Retrospectives:Retrospectivesessionsenablecustomerstoassessthesolutionasitisbeingdevelopedtovalidatewhetherornotitisontracktoorsuccessfullymeetstheirneeds.

3.6 Solution Assessment and Validation

SolutionAssessmentandValidation(Chapter7oftheBABOK®Guide)describeshowbusinessanalystsassessproposedsolutionstodeterminewhichsolutionbestfitsthebusinessneed,identifygapsandshortcomingsinsolutions,anddeterminenecessarywork‐a‐roundsorchangestothesolution.Italsodescribeshowbusinessanalystsassessdeployedsolutionstoseehowwelltheymettheoriginalneedsothatthesponsoringorganizationcanassesstheperformanceandeffectivenessofthesolution.

3.6.1 Assess Proposed Solution (7.1)

Inagileprojectssolutionassessmentoccurscontinuallyasthesolutionisbuiltandrefined.Initialsolutionsoptionsareidentifiedup‐front,withdecisionsthatserveasastartingpointforcontinualevolutionoftheproduct.Throughoutthelifeoftheproduct,asthebusinessneedsevolveorbecomemorewelldefined,theteam'sunderstandingoftheproblem'ssolutionwillalsoevolve.Witheffectiveagilearchitectureanddesign,thecostofredoingcomponentsthathavealreadybeendevelopedcanberelativelylow.Withanagilecadence,assessingtheproposedsolutionbecomesanongoingassessmentofthesolutionoptionsagainstthebusinesscaseandcurrentstatusoftheproject.

.1 Agile Techniques• RealOptions:Allowsforassessmentofaspectsofthesolutiontodeterminewhendecisionshavetobemaderegardingaparticularproposal.


Mapping Agile Techniques to the BABOK® Guide Solution Assessment and Validation


3.6.2 Allocate Requirements (7.2)

Onagileprojects,requirementsallocationisdonebyallocatingrequirementsintogroupsorcategories.Thiscanbedonebylookingforthemesamongstproposedpiecesoffunctionalitythatcontributetooneormorefeatures.Agileteamsaretypicallysmallteamsandthisallocationshapesthedesignofthedeliveryorganizationitself.Featureteamsformaroundthefeaturesandcomponentteamssupportingcross‐featurerequirements.

.1 Agile Techniques• StoryDecomposition:Breaksdownhigh‐levelepicsandfeaturesintosmallersupportingstorieswhichcanbeallocatedtodifferentcomponents(includingprocessororganizationalchanges).

3.6.3 Assess Organizational Readiness (7.3)

Theorganizationalreadinessassessmentoccursonagileprojectsinmuchthesamewayasitdoesintraditionalprojects.Thedifferenceisthatthereleasecadencecanbemorefrequent.Asignificantareatodefineinagileprojectsishowoftentheorganizationcanabsorbreleases.Organizationalreadinessshouldincludenotjusttheend‐user/customeroftherelease,butthesupportingorganizationaswell(forexample,support,training,sales,marketing,andaccounting).Anassessmentshouldbemadeofwhatisrequiredforasolutionreleasetodelivervaluebyconsideringthingssuchaswhethertheproductneedstobefullytestedandwhatfeaturesareminimallyrequiredtoachieveuptakeandvalueforcustomers.

3.6.4 Define Transition Requirements (7.4)

Thedeterminationoftransitionrequirementsoccursinanagileprojectmuchasitdoesinatraditionalproject.Theabilitytodelivervalueincrementallyopensupnewpossibilitiesfortransition.Unlikeamonolithicrelease,theorganizationalimpactcanbesmallerbutmorefrequent.Sincethecostofdevelopmentperunitislower,temporaryintegrationintoexistingsystemscanbedeveloped,whichmakestheneedforrunningparallelsystemslesssignificant.Transitionrequirementsforagileshouldprojectsshouldbetracked,ensuringthoserequirementsaremetinthedevelopment,operations,andsupportplansforeachdeliverycycleoftheproduct,asneeded.




.1 Techniques• UserStory:Userstoriescanbeusedfortheplanningoftransitionrequirements,wheretheyareprioritizedand/ororderedinthesamefashionasuserstoriesforanyothersolutionrequirement.Userstoriescanbeaccompaniedwithalistofacceptanceteststhatcanbeusedtoassessiftheuserstoryhasbeensatisfiedintheresultingproduct.

3.6.5 Validate Solution (7.5)

Validationofasolutionhappensasanongoingeffortinanagileproject.Withineachiteration,thecustomerisprovidedwithdetailedfeedbackonthecurrentrequirements.Atthecompletionofeachiterationcycle,theproductownerfacilitatesalignmentwiththecustomerneedandcontinuedalignmentwiththebusinesscase.

.1 Agile Techniques• Retrospectives:Retrospectivesarereviewsthatexamineifthepieceoftheproducthasbeenbuiltinthecurrentiterationmeetstheactualbusinessneed.

3.6.6 Evaluate Solution Performance (7.6)

Uponrelease,theproductownerfacilitatestheunderstandingofhowwellthesolutionmeetstheneedsofthecustomer.Whilethebusinessanalystorproductownermayalsoassesstheutilityandperformanceofthesolutionduringanypointinthedeliverycycle,itisimportanttoalsopauseattheendofthedeliverycycletoassessthecurrentstateoftheproductinthecontextofthebusinessvalueitneedstodelivertoitsusers.Thebusinessanalystorproductownershouldensurecompleteditemsmeetexpectationsandidentifynewopportunitiestoaddvalueforthebusiness.Asnewitemsareuncoveredabusinessanalystorproductownershouldassessthenewrequestsagainsttheproductroadmapandbusinessrequirementstoassesstherelativevalueofthenewitem.Theincrementalnatureofthebacklogallowsnewhigher‐valueitemsdiscoveredduringthisevaluationtoenterintothebacklogaheadofexistingitems.Thisislikelytocreatechangestoplansforsubsequentdeliverycycles;however,italsohelpstoensurethefeaturesofthehighestvaluearedeliveredfirsttoshortentimetodelivervaluetothecustomer/user.


Mapping Agile Techniques to the BABOK® Guide Solution Assessment and Validation


.1 Agile Techniques• BusinessCapabilityAnalysis:Allowsbusinessanalystsandstakeholderstounderstandtheimportanceandrelativeperformanceofabusinesscapability.

• ValueStreamMapping:Usedtoidentifythoseaspectsofthesolutionthataddvalueforcustomersandthosewhichdonotaddvalue.Thisassessmentbecomesthebasisforongoingimprovementefforts.



FOURChapterAgile Techniques

4.1 A Context for Agile Business AnalysisThischapteroftheAgileExtensiontotheBABOK®Guideprovidesanalystswithtechniquesandtoolsthatwillassisttheminexcellingintheagileworld.Inorderforthetechniquesandskillspresentedinthissectiontobeappliedsuccessfully,therearesomefoundationalprinciplesthatneedtobeunderstood.Theseprinciplesaresupportedbyanumberofpracticaltechniquesthatcanbeusedbypractitionerswhentheyundertakebusinessanalysisonagileprojects.

Theprinciplesthatguidesuccessfulbusinessanalysiscanbecategorizedintotwodistinctframeworks:

• theDiscoveryFrameworkand• theDeliveryFramework.

TheDiscoveryFrameworkdealswiththewhatsandthewhysoftheproduct.Effectivediscoveryissupportedbythreeunderlyingprinciples:

• SeeTheWhole,• ThinkasaCustomer,and• AnalyzetoDetermineWhatisValuable.

TheDeliveryFrameworkdealswiththehowsandthewhensoftheproduct.Effectivedeliveryissupportedbyfourunderlyingprinciples:

• GetRealUsingExamples,• UnderstandWhatisDoable,• StimulateCollaborationandContinuousImprovement,and• AvoidWaste.

Pleasenotethattheseguidingprinciplesaremeantasaguideandnotnecessarilyashardandfastrules.Forexample,whileGetRealUsing


A Context for Agile Business Analysis Agile Techniques

ComplimentaryMemberCopy.NotforRedistributionorResale.d

ExamplesisincludedintheDeliveryFramework,thetechniquesdescribedinthisprinciplecancertainlyproveeffectivewithintheDiscoveryFrameworkaswell.

ThefollowingtableshowstheAgileExtensiontechniquesthatsupporteachprinciple.

TABLE 4.1 Agile Extension Techniques

Principles of Agile Business Analysis

The Discovery Framework Delivery Framework

See the Whole

Think as a Customer

Analyze to Determine

What is Valuable

Get Real Using

Examples

Understand What is Doable

Stimulate Collaboration

and Continuous

Improvement

Avoid Waste

Business Capability Analysis

Story Decomposition

Backlog Management

Behaviour Driven Development

Relative Estimation

Collaborative Games

Lightweight Documentation

Personas Story Elaboration

Business Value Definition

Planning Workshop

Retrospectives

Value Stream Mapping

Story Mapping

Kano Analysis

Real Options

User Story MoSCoW Prioritization

Storyboarding Purpose Alignment Model


Agile Techniques A Note on Agile Extension Techniques


4.2 A Note on Agile Extension TechniquesThetechniquesdescribedherehaveprovenvalueinsupportingagilebusinessanalysis,butwedonotclaimthatthislistisall‐inclusiveorinanywaycanonical.Thetechniquesherewereselectedbasedontheexperiencesoftheteammembers,andrepresentbothexpansionstoexistingcontentintheBABOK®Guideandnewtechniquesnotdescribedinthecurrentversion.FutureversionsoftheAgileExtensionwilllikelyincludenewtechniques,anditisalsopossiblethatsomeofthetechniqueslistedherewillberemoved.

Inaddition,manyofthetechniqueslistedheremayproveusefultobusinessanalysispractitionerswhoarenotworkingonagileteams.

Agileapproachestendtofocusoncontinuousimprovementintheirmethodsandtechnique.ThetechniquesintheAgileExtensiontotheBABOK®Guidewillberequiredtoreviewedandupdatedonaregularbasis.

4.3 BA Techniques Mapped to Agile GuidelinesThefollowingtablemapstechniquesasdescribedintheBABOK®Guidetotheprinciplesforagilebusinessanalysispresentedinthisdocument.

TABLE 4.2 Business Analysis Techniques Mapped to Agile Business Analysis Guidelines

Business Analysis

Technique

BABOK v.2

Chapter

See the

Whole

Think as a Customer


What is Valuable

Get Real using

Examples



and Improvement

Avoid Waste

Acceptance & Evaluation criteria definition

9.1

Base lining 4.1.5.2

Benchmarking 9.2

Brainstorming 9.3

Business Rule Analysis

9.4


BA Techniques Mapped to Agile Guidelines Agile Techniques


Checklists 6.5.5.2

Coverage Matrix

4.2.5.1

Data Dictionary and Glossary

9.5

Data Flow Diagrams

9.6

Data Modeling

9.7

Decision Analysis

9.8

Document Analysis

9.9

Estimation 9.10

Feasibility Analysis

5.3.5.2

Focus Groups 9.11

Force Field Analysis

7.3.5.2

Functional Decomposition

9.12

Interface Analysis

9.13

Interviews 9.14

Lessons Learned Process

9.15

Metrics and Key Performance Indicators

9.16

MoSCoW Analysis

6.1.5.2

Non-functional Requirements Analysis

9.17

Observation 9.18

Business Analysis

Technique

BABOK v.2

Chapter

See the

Whole

Think as a Customer


What is Valuable

Get Real using

Examples



and Improvement

Avoid Waste


Agile Techniques BA Techniques Mapped to Agile Guidelines


Organization Modeling

9.19

Problem or Vision Statement

5.4.5.2

Problem Tracking

9.20

Process Modeling

9.21

Prototyping 9.22

RACI Matrix 2.2.5.2

Requirements Documentation

4.4.5.1

Requirements for Vendor Selection

4.4.5.2

Requirements Workshops

9.23

Risk Analysis 9.24

Root Cause Analysis

9.25

Scenarios and Use Cases

9.26

Scope Modeling

9.27

Sequence Diagrams

9.28

Signoff 4.1.5.3

Stakeholder Map

2.2.5.3

State Diagrams

9.29

Structured Walkthrough

9.30

Survey/Questionnaire

9.31

SWOT Analysis

9.32

Timeboxing/Budgeting

6.1.5.3

Business Analysis

Technique

BABOK v.2

Chapter

See the

Whole

Think as a Customer


What is Valuable

Get Real using

Examples



and Improvement

Avoid Waste


BA Techniques Mapped to Agile Guidelines Agile Techniques


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


What is Valuable

Get Real using

Examples



and Improvement

Avoid Waste


Agile Techniques Guidelines for Agile Business Analysis


4.4 Guidelines for Agile Business AnalysisThefollowing7guidelinesforpracticingbusinessanalysisinsideanagilecontext,arebasedonthevaluesandprinciplesoftheAgileManifesto.Togethertheseguidelinesembodythedisciplineofagilebusinessanalysis.

Theseguidelinesprovidevaluablecontextwhenapplyingthevarioustechniquesdescribedinthischapter:

• Inanagilecontext,businessanalysisviewstheentiresystemofpeople,process,andtechnologytofindwheretruevalueliesandtohelporganizationsmaximizethelikelihoodofdeliveringavaluableandvaluedsolution.

• Agileanalysispaysspecialattentiontothevoiceofthecustomertounderstandtheirvaluesandexpectations.

• Toconfirmwhatisvaluable,itiscommontouseconcreteexamplestobothelicitandvalidateproductneeds.

• Technologystakeholdersareempoweredbyeffectivelyanalyzedneeds.Ithelpsthemdeterminehowmuchworktheycandeliveratanygivenpointintime,identifyproductrequirementsoptions,andproviderecommendationstobusinesspartnersonsolutions.

• Facilitativetechniquesenableefficientandeffectivecollaborationandaccelerateateam'sabilitytodefineanddeliverproducts.

• Trustandsafetyareintegraltohealthyteamsandallowsthemtotransparentlyidentifyimprovementopportunities.Improvingbothproductandprocessisimperative;thereforeagileteamscontinuallystrivetogetbetter.

• Alwaysbeonthelookoutfor,andavoid,anythingwasteful.

Adoptingtheseguidelinesrequiresleveraging,extending,andadaptingfoundationalbusinessanalysistechniques.See“BATechniquesMappedtoAgileGuidelines”onpage49foramatrixofbusinessanalysistechniquesthatmayapplyinanagilecontext.


The Discovery Framework Agile Techniques


4.5 The Discovery FrameworkTheDiscoveryFrameworkdealswiththewhatsandthewhysoftheproduct.Effectivediscoveryissupportedbythreeunderlyingprinciples:

• SeeTheWhole,• ThinkasaCustomer,and• AnalyzetoDetermineWhatisValuable.

4.5.1 See The Whole

SeetheWholeisaconceptthatdescribestheneedtolookataproblemoropportunityinthecontextofthebigpicture,focusingonthebusinesscontextandwhyaprojectisbeingundertaken.Itdescribesnotjustwhatasystemisbuthowitwillbeused.Itisimportanttoassesshowthesolutionachievessomethingofvalueforitsrecipients.Thevaluecontextforthesolutioniscreatedbyunderstandingboththesolutionandthestakeholders,andthenarticulatingwhotheyareandhowtheywillfindvalueinthesolution.TheideasbehindSeetheWholeareinfluencedbysystemsthinking.

Onagileprojectsthereisahighriskofgettingmiredinthedetailsoneachiteration.Whendevelopingthebusinesscaseforasolutionandperformingiterationandreleaseplanningactivitiesitisimportanttomaintainthefidelityofthecontext.Bydoingsothecontextguidesthenextlevelofelaboration.Bythinkingaboutthestrategicoutcomeforthesolution,thedeliveryteammovesfromordertakerstoagroupthatdeliversbusinessvaluewithlesscodebloat,scopecreep,andnever‐endingprojecttime‐lines.Seeingthewholecreatessituation‐appropriatecontextandasharedunderstandingofthebusinessproblemthatneedstobesolved,whichinturnwillguidedecisionmaking.

Thefollowingsectionsdescribecommonlyusedtechniquesforthisprinciple:

• BusinessCapabilityAnalysis,• Personas,and• ValueStreamMapping.


Agile Techniques The Discovery Framework


ThereareothertechniqueswithintheAgileExtensiontotheBABOK®Guide,theBABOK®Guide,andotheradhoctechniquesthatcanbeutilizedhereaswell.

.1 Business Capability Analysis

Purpose

Provideaframeworkforproductscopingandreleaseplanningby

• generatingasharedunderstandingoftheoutcomesofabusinessorproduct,

• identifyingalignmentwithastrategyandspecificperformancegaps,and

• providingascopeandprioritizationfilterthatisstableandhaslowfrictiontomaintainovertime.

Description

Businesscapabilityanalysisistheanalysisoftheperformanceandriskassociatedwithasetofbusinesscapabilitiestoidentifyspecificperformancegapsandtoprioritizethesebasedonbusinessvalueandrisk.Businesscapabilitiesdescribetheabilityofabusinesstoactonortransformsomethingthathelpsachieveabusinessgoalorobjective.Manyproductdevelopmenteffortsareanattempttoimprovetheperformanceofabusinesscapabilityortodeliveranewbusinesscapability.

Agileapproachescreateaframeworkthatfacilitatesfrequentre‐assessmentofbusinessneedsandvalue.Thedirectionofthebusinessandthegapsrequiredforthebusinesstomeetitsobjectivesmustberevisitedforeachiterationplanningsession,whichgenerallyoccursevery2‐4weeksinmostagilelife‐cycles.Thismeansthatanagileprojectteammustmaintainaconstantviewofthebusinesscapabilitiesthatarerequiredforthebusinesstobesuccessful,particularlythosethatareinscopefortheproductbeingdelivered.

Elements

Capabilities

Capabilitiesaretheabilitiesinabusinesstoperformortransformsomething.Capabilitiesshoulddescribethepurposeoroutcomeoftheperformanceortransformation,nothowtheperformanceortransformationisperformed.Itdescribesthewhat,asopposedtothe




how.Forexample,sendingafaxisnotacapability;notifyingthecustomeristhecapability.

Using Capabilities

Capabilitiesimpactbusinessvaluethroughincreasingorprotectingrevenue,reducingorpreventingcost,improvingservice,achievingcompliance,orpositioningthecompanyforthefutureinalignmentwiththebusinessstrategy.Notallcapabilitieshavethesamelevelofvalue.Forexample,whiledistributingpayrolltoemployeesisimportanttoacompany,itislikelyneitherofhighbusinessnorcustomervalue.Inotherwords,thismaynotbeacapabilitythataddsvalueforthecompanytobuildandmaintaininternally.Therearevarioustoolsthatcanbeusedtomakebusinessandcustomervalueexplicitinacapabilityassessment.

Performance Expectations

Sincecapabilitiesidentifytheabilitiesrequiredtoperformortransformsomething,capabilitiescanbeassessedtoidentifyexplicitperformanceexpectations.Whenacapabilityistargetedforimprovement,aspecificperformancegapcanbeidentified.Theperformancegapisthedifferencebetweenthecurrentperformanceandthedesiredperformancegiventhebusinessstrategy.

Risk Model

Risksintheperformanceofthecapabilityfallintothefollowingcategories:

• businessrisk,• technologyrisk,• organizationalrisk,and• marketrisk.

Strategic Planning

Businesscapabilitiesforthecurrentstateandfuturestateofanorganizationcanbeusedtodeterminewherethatorganizationneedstogoinordertoaccomplishtheirbusinessstrategyandimperatives.Asaresultofperformingabusinesscapabilityassessmentthereisgenerallyasetofrecommendationsorproposalsforsolutionsthatneedtobeputinplace.Thisinformationformsthebasisofaproductroadmapandservesasaguideforreleaseplanning.

Capability Maps

Frequentlyorganizationsusecapabilitymapstoprovideagraphicviewofelementsinvolvedinbusinesscapabilityanalysis.The




followingillustrationdemonstratesoneelementofacapabilitymapthatwouldbepartofalargercapabilitiesgrid.

FIGURE 4.1 SampleCapabilityMap

FIGURE 4.2 SampleCapabilityMapCell




Usage Considerations

Capabilityanalysisisusefulwhenanorganizationchangesitsbusinessfocusorstrategy,orthereismoredemandforchangethanthereiscapacitytodeliver.Whenthedemandoutweighsthecapacitytodeliver,alargeundifferentiatedbacklogofchangesorimprovementrequestscanresult.Capabilityanalysishelpstoidentifythoseimprovementrequeststhatwilladvancethestrategicgoalsofthebusiness.Uponcompletionofaprojecteffort,thecapabilityanalysiscanbeupdatedtoreflectimprovementsinperformanceandtoidentifythenextmostimportantcapabilityperformancegaptofocuson.

Theoutcomesofacapabilityanalysisserveaslong‐livedartifactsthatrepresentacommonviewofthebusiness.Thiscanbeusedtogeneratesharedunderstandingandalignefforts.Whenthebusinessstrategychangesorcustomerdesiresevolve,thismodelcanbeusedtorapidlyre‐prioritizethelistofwantsforasolution(forexample,re‐prioritizingthebacklog).

Advantages• Theadvantagesofcapabilityanalysisarethattheyresultinasharedarticulationofoutcomes,strategy,andperformance.Thesehelpcreateveryfocusedandalignedinitiatives.Themodelworkswellwithagileteamsbutitalsohelpsidentifyopportunitiesthatarenottechnologybased,includingprocess,talent,anddataimprovements.

• Thecapabilityanalysishelpsalignbusinessinitiativesacrossmultipleaspectsoftheorganization.

Disadvantages• Thismodelrequiresanorganizationtoagreetocollaborateonthismodel.

• Whenthismodeliscreatedunilaterallyorinavacuumitfailstodeliveronthegoalsofalignmentandsharedunderstanding.

• Themodelalsorequiresabroad,cross‐functionalcollaborationindefiningthecapabilitymodelandthevalueframework.




.2 Personas

Purpose

Usercentereddesignpracticesoftenusepersonasasapowerfulandsimpletooltohelpdesignsoftwarethatuserswillenjoyandbenefitfrom.

Description

Personasarefictionalcharactersorarchetypesthatexemplifythewaythattypicalusersinteractwithaproduct.Theyareoftenusedinagileapproachestounderstandvaluefromtheperspectiveofaparticularcustomerandallowateamthatmaynothavedirectaccesstoacustomerrepresentativetobetterunderstandtheirneeds.Workcanthenfocusonthefeaturesofgreatestvaluetoaparticularpersona.

Elements

Apersonashouldbedescribedasthoughtheyarearealperson.Personasmayprovideaname,personality,family,workbackground,skilllevel,preferences,behaviorpatterns,personalattitudes,goals,andneeds.Itisalsoagoodpracticetoincludeapictureandwriteashort“dayinthelife”narrativethathelpstheteamvisualizetheuser.


Usepersonaswhenyouwanttogetadeeperunderstandingofkeystakeholdersthanonegenerallygetsfromatraditionalroleoractordescription.Personashelpdriveproductsthatarefitforpurposeandhighlyusable,becausetheyarepatternedafterthesubtlequalitiesofrealpeoplethatwillinteractwiththesystemsandhowtheydotheirjob.

Ifthedataisavailable,usingdemographic(oranthropomorphic)dataabouttheintendeduserpopulationisagoodwaytostartbuildingpersonas.Howeverinsomecasesitisnecessarytobecreativeandinventpersonasbasedonlittlemorethanafewdryfactsabouttheintendedendusers.Ineithercase,arepresentativepoolofpersonasshouldbeidentified.

Personasarethenrankedtoidentifythosewillrealizethemostbenefitfromthesystemdesign.

Advantages• Personasfacilitatethesharedunderstandingofspecificrequirementsfordifferentsetsofusers.Theserequirementscanbe




visualizedwithinthecontextoftheirusergroupandthenusedtodevelopuserstories.

• Proposedsolutionscanbeguidedbyhowwelltheymeettheneedsofindividualuserpersonas.Featurescanbeprioritizedbasedonhowwelltheyaddresstheneedsofoneormorepersonas.

• Provideahuman“face”soastofocusempathyonthepersonsrepresentedbythedemographics.

Disadvantages• Personasarefictionalsothereisoftenatendencytocreatepersonasthatembodytraitsthatarecommontomostusers,butindoingsocreatingagenericuserthatisnotdistinctorrealistic.Thiscanleadtosoftwarethatistryingtobeeverythingtoeveryone.

• Personasmaynotbeagoodsubstituteforarealuser,iftheyareavailable.Personascandistanceateamfromausercommunity.

.3 Value Stream Mapping

Purpose

Valuestreammapping(alsoknownasmaterialandinformationflowmapping)providesacomplete,fact‐based,time‐seriesrepresentationofthestreamofactivitiesrequiredtodeliveraproductorservicetothecustomer(internalorexternal).Itisusedtoidentifyareasofpotentialimprovementinanend‐to‐endprocess.

Description

Avaluestreamrepresentstheflowofmaterialandinformationrequiredtobringaproductand/orservicefromrawmaterialtothecustomer.AValueStreamMap(VSM)isagraphicalrepresentationthatcapturesasnapshotofthevaluestream.

Therearetwomaintypesofvaluestreammapsthatarewidelyused:

• CurrentStateValueStreamMap:Depictsavaluestreamasitisappliedbythosewhoareresponsibleforexecutingit.Itisusuallyusedasastartingpointforanalysisofanexistingprocesstoidentifyimprovementopportunities.

• FutureStateValueStreamMap:Derivedfromthecurrentstateanditshowswhatthevaluestreamwilllooklikeaftertheimplementationoftheimprovements.

Inanagileenvironment,thisdiagramisusuallysimpleanddrawnonawhiteboard.Itcanbeusedtohelpre‐engineerbusinessprocessesto




optimizeuseofsoftware.Itcanalsobeusedtore‐engineerandtunethesoftwaredevelopmentprocessitself,forexample,toreduceleadtimefromproductdiscoverytorelease.

Elements

Thefollowingisabroaddescriptionforoneapproachtobuildingavaluestreammap.

Prepare1. Gatheracross‐functionalteam.Intheagileworldthisshould

includepeoplewithbusinessdomainknowledgeandtechnicalteammembers(suchasdevelopers,testers,andarchitects).Oftensomeoneactingasthebusinessanalystwillfacilitatethesession.

2. Assignavaluestreammapowner.Ideallythisissomeonewhohasadeepunderstandingofthecurrentprocess.

3. Selectaproduct,aproductfamily,oraservice,anddefinethescopeofthevaluestreammap.

4. Identifythecustomervaluereceivedsoitcanbetracedback.

Create Current State

Thecurrentvaluestreammapcanbecapturedfollowingthesesteps:

1. Observeorsimulatevaluestream.Followaproduct(orproductfamily)pathbystartingattheendclosesttothecustomerandrecordtheprocessworkingyourwaybackwardstothebeginning.

2. Drawthevaluestreammap.

3. Capturetheinformationflow.Theinformationthatisvitalforthevaluestreamtofunction.Informationflowincludes(butnotlimitedto)thingssuchasorders,schedules,inventorytime,changeovertime,cycletime,andnumberofoperatorsinvolved.

4. Buildamodelthatshowseachstepintheflowwithhand‐offsandsequence.Toassistintheanalysisneededtoidentifyopportunitiesforimprovementintheprocess,ensurethatyouincludetime/costvaluesontothestepsintheprocess.Thesetimevaluesmaybeestimated,ifneeded.Themoredetailsavailable,theeasieritistoidentifyimprovementopportunities.

5. Validatethevaluestreammap.Theinitialdraftofthecurrentvaluestreammapmustbevalidatedbeforeproceedingtotheimprovementphase.




Analyze Current State

ThecurrentvaluestreammapcanbeanalyzedasdescribedinRootCauseAnalysisoftheBABOK®Guideversion2.0(9.25RootCauseAnalysis)toidentifyvalueaddedsteps(suchastransformationprocesses)fromthosethatarenon‐valueadded(suchasexcessiveinventories).

Thenon‐valueaddedstepscanbeanalyzedfurthertodeterminewhichonesarenecessary(suchasmeetingregulatoryrequirements)andwhichonesareunnecessary(suchasexcessivepaperwork).

Create Future State

Thefuturestatevaluestreammapcanbedrawnasfollows:

1. Identifyimprovementareas.Unnecessarynon‐valueaddedstepsarethesourceofwasteandtheycanbeeliminated.Teammemberscanmarktheseareas(suchasreducingleadtime)onthecurrentvaluestreammap.

2. Capturethefuturestatevaluestreammap.Drawthevaluestreammapthatshowswhatthevaluestreamwilllooklikeafteryouhaveeliminatedthewaste(unnecessarywaittime,excessiveadministrativepaperwork,highinventories,andsoforth).

Oncethefuturestateiscaptureditcanbeusedasthetargetstateoftheimprovementinitiative.

Implement Process Improvement • Identifysupportingmaterialrequiredforimplementingtheimprovementsuchasinformationtechnologysystems,training,andchangeover.

• Implementtheimprovement.

Inanagileproject,valuestreammappingwillbemostutilizedwhenimplementingprocessimprovement.Oftenthechangestobemadeinthebusinessprocesswillrequirechangestoorimplementationofsupportingsoftwareproducts.Therequirementsforthesechangesorenhancementsbecomebacklogitemsthatfeedintoanagileinitiative.

Oncetheimprovementismade,thefuturestatebecomesthecurrentvaluestreammapanditcanbeusedasastartingpointforanotherimprovementcycle.




Thefollowingisanexampleofavaluestreammap.

FIGURE 4.3 ValueStreamMap


Advantages• Morecomprehensivethanaprocessflowdiagram.• Providesablueprintforimplementingimprovement.• Establishesasharedunderstandingofprocesswastesandbottlenecks.

• Providesacommonvisuallanguagefordiversestakeholders.

Disadvantages• Noteasytoconstructincomparisonwithothervisualmodelingtechniques.

• Canlookdauntingbecauseofalltheinformationcaptured.• Mappingparalysis.Itiseasytogetcaughtmakingthecurrentstatevaluestreammapcompleteandperfectinsteadofproceedingtotheimprovementstage.

• Doesn'tworkwellinknowledgebasedornon‐linearwork.• Leadstodisruptiveor“re‐engineering”approach.Doesn'tworkwellwithongoingimprovementefforts.




4.5.2 Think as a Customer

Thinkinglikeacustomerisakeycomponentofagilebusinessanalysis.Thecustomeristhepersonwhogetsvaluefromtheproductwearebuilding.Westartwithahighlevelviewofcustomergoalsandprogressivelydecomposetheseintoamoreandmoredetailedunderstandingofthespecificneedsthattheproductmustmeet.

Agileprocessesincorporatefeedbackloopstocontinuouslyvalidatethisunderstanding.Asproductdeliveryprogresses,thecustomerandteamunderstandingoftheneedswillevolve,itisimportantthatthesechangesinfluenceanddefinetheworkoftheteamgoingforward.

Agileanalysisslicesthedeliveryintothesmallestpracticalincrementsthatdeliverbusinessvalueoverthelifeoftheproject.

Itisimportantthatagileanalysisstartwithaholisticperspective,inordertohelptheteamunderstandtheoverallproductthatneedstobedelivered.Theteamcollaborateswiththecustomertoconsidertheuserexperienceexpected.

Agoalofanalysisistoensurethevoiceofthecustomer,especiallytheend‐user,iselicitedandexpressedintheproduct.

Backlogitemsrepresentworktobedoneandconveycustomerthinking,andcanberepresentedthroughprototypes,userstories,usecases,minimalmarketablefeatures,features,epics,orworkitems.

Thefollowingsectionsdescribecommonlyusedtechniquesforthisprinciple.

Thetechniqueslistedbelowarebasedonuserstories:

• StoryDecomposition,• StoryElaboration,• StoryMapping,and• UserStory.

Atechniqueforprototypingauserinterfaceandusingthattodefinedetailedrequirementsis:

• Storyboarding.





.1 Story Decomposition

Purpose

Storydecompositionisaderivationofexistingrequirementsanalysistechniquessuchasfunctionaldecomposition.Inanagilecontext,storiesareoftenusedtorepresenttheworkoftheteamandtherequirements(oracceptancecriteria)ofthatwork.Storydecompositionensuresthattherequirementsforaproductarerepresentedattheappropriatelevelofdetailandarederivedfromavaluablebusinessobjective.

Thistechniqueprovidesastructurefordefiningthevariouselementsofrequirementsatprogressivelysmallerlevelsofgranularity,startingwiththebroadsystemcontextanddrillingdowninmultiplelevelstoeventuallydefinethedetailedacceptancecriteriaforindividualuserstories.

Description

Themostcommonagileapproachtostorydecompositioncanbedescribedas“breadth‐before‐depth”:

• startwithaveryhighlevelpictureofwhatbusinessgoalsneedtobeachieved,

• decomposethoseintosmallercomponentsthatprovideincrementsofvaluablefunctionality(sometimescalledminimallymarketablefeaturesetsorMMFs.MinimalviableproductsorMVPsaretheaggregationofmultipleMMFs),and

• splitthecomponentsintouserstories,andeventuallyelaboratetheuserstorieswithacceptancecriteria,see“StoryElaboration”onpage68.

Astorythatistoolargeorinsufficientlyunderstoodtoelaborate,estimate,ordeliverasastoryissometimescalledanepic.Epics,whenused,arelaterdecomposedintosmallerstories.




FIGURE 4.4 StoryDecomposition

Differentteamsapplythistechniqueindifferentways.Forexample,someteamsfollowthemodellinearly,asshownintheabovediagram,whileotherteamsutilizetechniquesthatworkbestintheirenvironment.Forexample,onceateamhasdevelopedtheMMF(sometimesreferredtoasfeaturegroups),theymayemployusecasesinsteadofstories.Theanalyst'srolehereistofocusondynamiccollaboration,facilitation,andcommunicationingettingacceptanceforjustwhatisrequiredtodevelopanddelivertheproduct.




Thefollowingtabledescribesthedifferentlevelsofstorydecomposition.

TABLE 4.3 Story Decomposition


StoryDecompositionisundertakenprogressively.Oneofthemostsignificantdifferencesbetweenagileprojectsandplan‐drivenprojectsisinthedefinitionofdetailedrequirements.Inagileprojectstheinitialanalysisactivitieswillidentifythegoals,MMFs,andmostoftheepics.Theinitialsetofuserstories(probablyforthefirstreleaseoftheproduct)willbedoneintheprojectinitiationactivities.Thereisaclearunderstandingthatthesestoriesarelikelytochangeandthattheteams'understandingoftherequirementswillevolveovertime.Therefore,decomposingtothelowestlevelofdetailislikelytobeawastefulactivityearlyintheproject.

Advantages• Thisdecompositiontechniquehelpsavoidthecommonproblemofgettinglostinthedetailoftheuserstoriesandlosingthebig‐picturecontext.

• Itisimportantthatteammemberskeeptheproject'sgoalsandobjectivesinmind,andwhileusingthedecompositionapproach

Level DescriptionSystem Goals The product goals are the highest level of business requirements. They

represent the business drivers for undertaking the project and form the rationale against which all of the detailed level needs are assessed.

MMF/Component

MMF stands for Minimal Marketable Feature. Minimal Viable Products or MVPs are the aggregation of multiple MMFs. These are logical groupings of functionality and capabilities the delivered product needs to provide to be worth releasing. Often these will form the themes for a single release and serve to provide a big-picture context for the product being developed.

Epic A piece of functionality that enables a user to achieve a clearly identified business objective. Often epics are at the level of elementary business processes---a piece of work undertaken by one person, at one time, in one place that delivers on a specific operational objective. Epics are often a user story that is too large to fit into an iteration. Therefore it requires story decomposition in order to break it into less than iteration sized stories.

User Story Represents a user requirement that is to be implemented in the delivered system. The user story is the most common backlog item used in agile projects.

Acceptance Criteria

Conditions of satisfaction or criteria needed to validate a user story. Can be written as lists of items, specifications, or user acceptance tests (or a combination). Detailed requirements are represented and validated in the acceptance criteria.




theyareabletotraceimplementedorrequestedfunctionalitybacktothedrivingbusinessobjectives.

• BreakingtheproductintoMMFsandepicshelpswithrelease‐levelplanning,providesvisibilityintothedevelopmentproject,andhelpscoordinateexternalprogramactivitiessuchasorganizationalchangemanagementandusertraining.

Disadvantages• Acommonanti‐patternisthetemptationtotreatstorydecompositionasawayofrevertingtodetailedrequirementsup‐front.Ensuringthecontinuedemphasisonjust‐enoughandjust‐in‐time,meansknowingwhentostopdecomposing.

.2 Story Elaboration

Purpose

Storyelaborationisatechniqueusedtodefinethedetaileddesignandacceptancecriteriaforauserstoryonajust‐in‐time/just‐enoughbasis.Storyelaborationisanongoingactivitythatispartofthedevelopmentprocess.

Description

Storyelaborationisthelowestlevelofstorydecompositionandtheprocessbywhichthestorysentenceisintobrokendownintopiecesofwork.Thisisoftendonebysomeoneontheteamwhohasstrongbusinessanalysisskills,particularlywithfacilitationandcommunication.Storyelaborationisthetechniquethroughwhichdetailedrequirementsareelicitedandcommunicatedtotheprojectteam.

Duringeachiteration,theteamthatworksonastoryschedulestimetoexpandonthestorytounderstandthedetail.Often(butnotalways)thisiscompletedinashortworkshopwiththeprogrammerswhowillworkonthestory,thebusinessSMEorcustomerwhoneedsthestory,thepersonwhowilltestthestory,andsomeoneactingasabusinessanalysttofacilitateandchallengethestory.Typically,storyelaborationisundertakenafewdaysaheadofthedevelopmentofthestory.

Storyelaborationshouldbedoneonanas‐needed,just‐in‐timebasisforstoriesthathavebeendeterminedtobeinscopefortheupcomingiteration.Theprojectteamshouldnotinvestigatestoriesforfurther




elaborationiftheyhavenotbeenplannedforthereleaseinquestion,astheinformationcollectedmaybestaleandoutofdate.

Storyelaborationisacommunicationtechniquethathelpsensurethecorrectproductisbuilt.Inanagileproject,thedetailedrequirementsareproducedbystoryelaboration.However,asopposedtoplan‐drivenapproaches,andconsistentwiththejust‐in‐timephilosophyofagile,thedetailedrequirementsdefinedduringstoryelaborationcontainonlytherequirementdetailsforthepieceofworkthatistobecompletedinthecomingrelease.

Elements

Theresultofstoryelaborationisasharedunderstandingamongtheparticipantsofwhatthestorymeansandwhatshouldbedeliveredtoachievethe“Done”stateforthisstory.Theroleofthebusinessanalystindevelopingandcommunicatingdynamicrequirementsnecessitatesahighdegreeofskillinbothfacilitationandcommunication.

Someteamsusestasksasawaytocommunicatetheiranalysisoftheuserstory.Theoutputsofeffectivestoryelaborationdescribeand/ordocumenttasksthatenabletheteamtosuccessfuldelivertheupcomingiteration.Theseoutputsmayinclude

• taskdefinitionsandbreakdowns,• examplesandscenariosthatexplainthecustomer'sintentforthestory,

• low‐fidelitymodelsthatclarifythetechnicalorprocessdesign(forexample,datamodels,anddataflowdiagrams),

• screenorreportmock‐ups,• acceptancecriteria(testdesignspecifications)toclarifyhowthestorywillbetested,ofteninthe<given><when><then>formatofbehaviordrivendevelopment,

• input/outputdatatables,and• otherartifactsthatwillbeusefulinthedevelopmentandtestingofthisstory.


Advantages• Themajoradvantageofstoryelaborationisthatitdecreaseselicitationtime,andpotentiallydocumentation,byfocusingoncurrentfeatures.Byelaboratingonrequirementsonlyastheyareneeded,theteamavoidstheworkofelicitingrequirementsfor




featuresthatmayneverbebuiltorthatwillneedtobechangedbythetimetheyarereadyforimplementation.

Disadvantages• Forthosewhoarerelativelynewtoagileapproaches,itcanbedifficulttodeterminethebesttimingforconductingastoryelaboration.Ifconductedtooearly,theinformationmaynolongerbecorrectforthegivenreleaseandwillneedtobere‐elicited.However,whencollectedtoolate,itcandelayprojectteamprogressiontodevelopment.

• Anotherchallengetoimplementingstoryelaborationistheabilitytoelicittheappropriatelevelofdetailsuchthattherequirementscanbedeveloped,tested,andcomparedtoacceptancecriteria.

.3 Story Mapping

Purpose

Storymappingprovidesavisualandphysicalviewofthesequenceofactivitiestobesupportedbyasolution.Itusesatwo‐dimensionalgridstructuretoshowsequenceandgroupingsofkeyaspectsoftheproductonthehorizontaldimension,withdetailandpriorityofstoriesontheverticaldimension.

Description

Astorymapisatooltoassistincreatingunderstandingofproductfunctionality,theflowofusage,andtoassistwithprioritizingproductdelivery(suchasreleaseplanning).Itisalsodecompositiontechniquethatallowsfortheevolutionaryunderstandingofaproductstartingwithanend‐to‐endviewanddrillingdowntothedetaileduserstories.

Astorymapisdesignedtobeaninformationradiator,usedtovisualizeaproduct'srequestsinthecontextofusageandpriority.Thestorymapisoftenplacedondisplayfortheprojectteamduringreleaseplanningsessions.Byanalyzingthestorymap,theteamcanmorereadilyidentifydependenciesgeneratedasaresultoftheintendedflowthroughtheuserstories.Themapcanalsobeusedforriskassessmentandmanagementbyexamininghowthestorieswillneedtoworktogetherinthecontextofdeliveringbusinessvalue.




Thefollowingillustrationisanexampleofastorymap.

FIGURE 4.5 StoryMap

Elements

Thestorymaphasacentralbackboneofelementsthatwillmakeuptheproduct.Abovethisbackbonearethelargefeaturesets(activities)thatneedtobedeliveredoverthelifeoftheproject.Thebackboneisasequentialsetoftasksthatneedtobeenabledbythesoftware.Belowthebackbonearethedetailedstoriesthatimplementthespecificpiecesoffunctionalitytoenablethetaskstobeaccomplished.


Advantages• Whenthelargercontextofaproductisnotaccountedfor,agileprojectscanbesubjecttogettingmiredinthedetailswithaninabilitytoeffectivelystringcomponentstogethertocreateend‐to‐endbusinessvalue.Storymappinghelpsavoidthecommonproblemofgettinglostinthedetailoftheuserstoriesandtheriskoflosingthebig‐picturecontext.

Disadvantages• Storymappingcanbecomecumbersomewheretheproductisverylargeandmayrequirebuildinganumberofstorymapsthatcoveralargeprogramofwork.Whilestorymapsillustrateaflow,theydonotanalyzeorillustratedependenciesbetweenrequirements(thoughtheycanbeusedtohelpfacilitatethatanalysis).

• Environmentsthatarenotprocessorientedwillfindstorymapslessuseful.




.4 User StoryUserStoriesaredescribedindetailintheBABOK®Guideversion2.0(9.33UserStories).Thisinformationfoundherereflectsandexpandsonthatinformationinthecontextofagiledevelopmentapproaches.

Purpose

Auserstoryrepresentsasmall,concisestatementoffunctionalityneededtodelivervaluetoaspecificstakeholder.

Userstoriescanbeused

• tocaptureandprioritizeuserneeds,• asabasisofestimatingandplanningproductdelivery,• asabasisforgeneratinguseracceptancetests,• asawaytomonitorprogressindeliveringofvalue,• asaunitfortracingrelatedrequirements,• asabasisforadditionalanalysis,and• asaunitofprojectmanagementandreporting.

Description

Userstoriesareaplanningtechniquethatenablesagileteamstotrackfeaturesofvaluetoacustomerorenduser,andareusedasabasisforestimatingwork.Typically,theyareoneormoresentenceswrittenbythecustomers,productowners,orbusinessanalyststhatdescribesomethingofvaluetoastakeholder.Userstoriesprovideamechanismfortheproductownertoscope,coordinate,andprioritizetheincrementsofuservaluefordevelopment.Astoryshouldbeshortenoughtobewrittenonasmallpapernotecard,usuallya3×5inchindexcardorstickynote.Storiesmayalsoberecordedinanelectronicsystem.

Userstoriescapturestakeholderneedsusingshort,simpledocumentationandinviteexplorationoftherequirementsthroughconversations,tests,andsupplementalrequirementsrepresentationsasneeded.Theyareconciseandeasytochangeasstakeholderneedsarebetterunderstoodorasthoseneedsevolve.

Someteamsmakeuseofothertypesofstoriestocatalogue,estimate,plan,andtrackotherworkneededtobuildtheproduct.Thesestoriestypicallydefineworkneededtoenableproductdevelopment,deployment,andsupport.




AcommonlyusedconstructforensuringqualityinuserstoriesistheINVESTcriteria,whichcallforuserstoriestobe

• Independent,• Negotiable,• Valuable,• Estimable,• Small,and• Testable.

Elements

Title (optional)

Thetitleofthestorydescribesanactivitythattheuserwantstocarryoutwiththesystem.Typically,itisanactive‐verbgoalphrase,similartothewayusecasesaretitled.

Description

Thereisnomandatorystructureforuserstories;however,themostpopularformatincludesthreecomponents:

• auserroleorpersona[WHO],• anecessaryaction,behaviour,orfeature[WHAT],and• thebenefitorbusinessvaluereceivedbytheuserwhenthestoryisimplemented[WHY].

Usageexample:

"Asa<role>,Ineedto<behavior>sothat<businessvalue>."

Analternativeformatis:"Inorderto<businessvalue>,asa<role>,Ineedto<behavior>."

Thiscanonicalformatcanalsobeusedforstoriesusedtoidentifyqualityattributes.Forexample:

"AsaSecurityOfficer,IneedtoonlyallowauthorizeduserstoaccessthexyzfunctionalitysoIcanensureweenforceabcsecuritydirective".

Conversation

Userstoriesserveasareminderthattheteamneedstoexploreandunderstandthefeaturedescribedinthestoryandthevaluethatitwilldelivertothecustomer.Thestoryitselfdoesn'tcaptureeverythingthereistoknowaboutthecustomerneed,andtheinformationimplied




bythestorycanbesupplementedbyanalysismodelstopromotesharedunderstanding.

Acceptance Criteria

Whenauserstoryiswelldefinedandunderstood,itisaccompaniedbyacceptancecriteria.Acceptancecriteriadefinetheboundariesofauserstoryandhelpproductowners,customers,orbusinessanalyststoanswerwhattheyneedtoprovidevaluewiththeproduct.

Acceptancecriteriahelpdevelopersidentifywhentostopaddingmorefunctionalityandtoderivetestsforverificationandvalidationpurposes.Theycanalsobedevelopedasastorybecomeswellunderstoodtoenablethedevelopmentteamtoverifythatthesolutionwillmeettheuser'sneeds.


Advantages• Tiedtosmall,implementable,andtestableslicesoffunctionalityfacilitatingrapiddeliveryandfrequentcustomerfeedback.

• Easilyunderstandablebystakeholders.• Canbedevelopedthroughavarietyofelicitationtechniques,includingbutnotlimitedtofacilitatedworkshops,contextualinquiry,andotherethnographicelicitationtechniques.

• Userstoriesaresimpleenoughthatpeoplecanlearntowritetheminafewminutes,beingcarefulaboutalwaysdeliveringbusinessvalue.

• Theprocessofcollaboratingondefiningandexploringstoriesbuildsteamcommitmentandsharedunderstandingofthebusinessdomain.

• Storiesinviteconversationforfurtherdecompositionandexploration.

• Tofacilitateestimating,planning,anddelivery,manyagileteamssupplementstorieswithanalysismodels(suchasadatamodel,businessrules,useracceptancetests,screenmock‐upsorprototypes,contextdiagram,andstatediagram).

Disadvantages• Thisconversationalapproachcanchallengetheteam,sincetheydonothavealltheanswersanddetailedspecificationsupfront.

• Toomanystoriescaninflatethebacklog.• Large,chunkystories(epics)canbevagueanddifficulttousewithoutbreakingthemdownintosmallstories.




• Storiesspawnmorestoriesviadecompositionsotheinformationmustbeorganizedtoensureitiscurrentandrelevant(calledpruningorgrooming).

• Thecollectionofstoriesneedstobemanaged(forexample,withbacklogmanagement).

• Storiesrequirecontext.Iftheteamdoesn'ttracestoriesback(throughvalidation)orsupplementthemwithhigher‐levelanalysisandvisionartifacts,thentheteamcanlosesightofthebigpicture.

• Somepractitionerscanbeconfusedaboutthedifferencebetweenusecases,userstories,andstorytechniques.

.5 Storyboarding

Purpose

Storyboardingisusedinconjunctionwithothertechniquessuchasusecases,userstories,andprototypingtodetailvisuallyandtextuallythesequenceofactivitiessummingupdifferentuserinteractionswiththesystemorbusiness.

Storyboardingserves

• toelicit,elaborate,organize,andvalidatetherequirements,• tocommunicatetodeveloperswhatneedstobebuilt,• toassistinginuserinterfacedesign,• toshowdifferentvariationsoftheproposedsolution,• toalignstakeholderswiththevisionoftheproposedsolution,and• asaninputtotests.

Description

Storyboards(alsoknownasdialoguemap,dialoghierarchy,ornavigationflow)userepresentativeimagesandtexttodescribeatask,ascenario,orastory.Itcanalsobeusedwithprototypingtorepresentpartsofthesystemthatarewellunderstoodorexpensiveandunnecessarytoproduceviaformalprototypes.

Whenusedtodescribetheinteractionwiththesystem,thestoryboardshowshowscreenswilllookandhowtheywillflowfromonetoanother.Whenusedtodescribebusinessorganization,thestoryboardshowstheinteractionwithabusinessprocesssuchasbackoffice.

Storyboardscanbedevelopedusingwhite‐boardsandstickynotesorusingsoftware.




Storyboardsarecommoninmanyanalysisanddevelopmentapproaches,andareaformofprototyping(seetheBABOK®Guideversion2.09.22Prototyping).However,asagileapproachesfavourthedevelopmentofworking,usablesoftwareoverthrowawayprototypes,storyboardingisausefultoolforunderstandinghowpeoplewillactuallyusethesystem.

Elements

Storyboardscanbecreatedinaworkshopenvironmentwithrelevantstakeholders.

Preparation1. Identifymainscenarioswithinthescopeoftheproject.Thiscanbe

derivedfromusecasesoruserstoriesorcanbeidentifiedinacustomervisitoraninformation‐gatheringsessionwithexperts.

2. Selectthescenariosthatneedtohaveastoryboarddeveloped.Whilesomescenariosneedtobedetailedinastoryboard,othersareobviousandcanbeomittedsuchasalternatescenariosandexceptions.

3. Identifyparticipantsandschedulethesession.

4. Arrangeroomandequipmentsuchasflipcharts,markers,glue,scissors,rulers,printers,andaccesstotheinternet.

Session1. Haveattendeescreateillustrationsforthestoryboardsofthe

selectedscenarios.

2. Enhancestoryboardillustrationswithtextualinformationsuchasoptionalinteractions,unavailableinteractions,furtherstakeholderrequestsnotassociatedwiththeprimaryscenario,andgeneralnotesassociatedwithaspecificstep.

3. Makesureeachstoryboardstandsonitsownbyaddingrequiredexplanationsastext.

Wrap up

Attheendofthesession,thebusinessanalystreachesconsensusonthehighlevelflowofthedevelopedstoryboards.

Aftertheworkshop,thecompanytemplatesmaybeusedtoformallydocumenttheoutcomeofthesession,addingadditionalelementstothestoryboardssuchasstoryboardidentification,description,user,trigger,input,output,andissues.





Advantages• Storyboardingcansignificantlyreduceabstractnesscausedbyothertechniquessuchasusecasesanduserstories.

• Storyboardscanbeproducedquicklyandataverylowcostcomparedtoothertechniquessuchasprototypes.

• Theintuitivenatureofthestoryboardencouragesstakeholderparticipation.

Disadvantages• Differentlookandfeelthanthefinalproduct.• Easytogetboggeddownonhow,ratherthanwhy.

4.5.3 Analyze to Determine What is Valuable

Theagileapproachcontinuouslyassessesandprioritizesbusinessvaluetoensurethatthemostvaluableworkisdeliveredatanypointintime,alwaysusingtheendcustomerperspective.Itisalsoimperativetoquestionthepurposebehindrequirements,challengingthoserequirementsthatdonotsupportthebusinessgoals.Agileapproachesenabletheartofmaximizingtheamountofworknotdone,somethingessentialtodelivervaluablesoftwareearlyandcontinuously.Thetechniquesoutlinedinthissectionfacilitatethevaluationofproductneedsonanon‐goingbasis.


• BacklogManagement,• BusinessValueDefinition,• KanoAnalysis,• MoSCoWPrioritization,and• PurposeAlignmentModel.





.1 Backlog Management

Purpose

Thebacklogisawishlistofrequestsforfeaturestobeincludedinaproduct,andisthemainmechanismformanagingrequirementsonanagileproject.

Description

Theproductbacklogisestablishedatthebeginningofaproject.Thebacklogisafluidcollectionofstoriesthatevolvesoverthecourseoftheprojectasmoreislearnedabouttheproductanditscustomers.Theproductownerisresponsiblefororderingtheitemsonthebacklogbasedonbusinessvalue,featureimportance,orotherrelevantcriteria.Whenmanagingabacklog,itemsshouldbeorderedsuchthatthemostimportantitemsoccuratthetopofthelistandareorderedbasedondescendingpriority.

Duringtheplanningsessions,itemsareselectedfromthebacklogbasedonfactorssuchaspriority,risk,valuetotheproductorcustomer,andabilitytodeliverthefeaturewithinthegivenrelease.Attheendofeachrelease,feedbackonwhatwasdevelopedmayresultinnewitemsbeingaddedtothebacklog,changedpriorities,orremoveditems.

Thebacklogisdevelopedatthebeginningofanagileproject,butitdoesnotneedtobecompleteatthistimesinceitwillcontinuetoevolvethroughouttheproject.

Thebacklogissometimesreferredtoasaportfolioofoptionsthatthebusinesscaninvestin.Othertermsusedaremasterstorylistandprioritizedfeaturelist.

Elements

Items in the Backlog

Thebacklogcancontainuserstories,usecases,features,functionalrequirements,andqualityattributestoriesaswellasitemsthathavebeenaddedbytheteamtosupportdevelopmentoftherequirementssuchastechnicalinfrastructure.Toaidinorderingthebacklog,itemsshouldbeexpressedinsuchawaythatthebusinessvalueoftheitemsisclear.Productriskmitigationitemsmayalsogetaddedtothebacklogasstoriesorpiecesofworktobedone.




Appropriate level of detail

Itemswithhighorderinthebacklogwillbedevelopedinnear‐termreleases,sotheyneedtobedetailedenoughtoallowthedevelopmentteamtoestimatethemwithaccuracyandbeabletodecomposethemintothetasksneededtodevelopthem,ifneeded.Itemswithlowerprioritycanremainhigh‐levelandlesspreciseuntiltheyriseintheorderandneedtobespecifiedinmoredetail.LargeitemsinthebacklogaresometimesreferredtoasepicsorMMFs,andmaybebrokendownintomultiple,moregranularitemsasthebacklogiselaboratedviastorydecomposition.Someaspectsofthestorymaybeimportantnear‐termandotherslessimportant.

Estimation Accuracy

Itemswithhighorderinthebacklogneedtobeestimatedwithenoughaccuracytousethemforplanningreleases.Itemsinlowerorderalsoneedtobeestimated,butwithlessaccuracysincetheyareoftenlessdetailed.Estimatesfortimetocompleteitemsisoftenmaintainedwithinthebacklogitself.

Prioritization

Itemsinthebacklogareorderedrelativetoeachother.Orderingcanbeestablishedusingnumbering,valuepoints,high/medium/low,oranyotherprioritizationtechnique.Theorderofitemsonthebacklogislikelytochangeoverthecourseoftheproject,especiallyastheproductevolvesandtheteamreceivesfeedbackfromthestakeholdersandcustomers.Itisimportanttonotethatorderingneartermitemsisvaluable,butputtingalotofeffortintoorderingthebacklogfarintothefuturecanbeawastefulactivitybecausethefartheroutbacklogitemsaresubjecttochange.

Managing Changes to the Backlog

Thebacklogisthemainmechanismforbothmanagingchangetotherequirementsonanagileprojectandforcontrollingscope.Whenneworchangedrequirementsareidentified,theyareaddedtothebacklogandorderedrelativetotheotheritems.Thebacklogisalsousedtotrackandmanagereporteddefectsorbugs.Orderingtheentirebacklogcanbedoneupfrontusingrelativeimportancedesignations(basedonbusinessvalue),whichallowshigh‐levelprioritizationwithoutgettingintotoomuchdetail.Sincereleasesanditerationsaretime‐boxedonagileprojects,theitemsloweronthebacklogareoftennotincludedinagivenrelease.Rigorousorderingofthebacklogallowstheteamtocontrolthescopeoftheprojectandreleases.




Whenanitemisdevelopedandacceptedbytheproductowner,theitemisremovedfromthebacklog.Theproductownerroleisresponsibleformanagingthebacklog,addingandorderingneworchangeditems,removingcompleteditems,andrevisingtheorderonanongoingbasis.Thisprocessissometimesreferredtoaspruningorgroomingthebacklog.


Advantages• Sincetherequirementsonthebacklogareorderedinimportance,theteamknowsthatwhattheyareworkingoninagiveniterationishighpriorityandwillcontributebusinessvaluetotheproduct.Themembersoftheteamresponsiblefordetailingtherequirementscanreviewthebackloganddetermineiftheitemsthatwillbedevelopedinanupcomingreleaserequirefurtheranalysisinordertoreadythemfordevelopment.

• Sinceeachreleasetypicallyimplementsasmallsetofrequirements,requirementsareanalyzedindetailonajust‐in‐timebasis.Whattheteamandthestakeholderslearnabouttherequirementsdevelopedduringareleasecaninformtheanalysisofotherrequirementsinupcomingiterations.

Disadvantages• Largebacklogsmaybecomecumbersomeanddifficulttomanage.Breakingtheoverallproductbacklogintobacklogsforreleases(calledreleasebacklogs)canhelpaddressthisdisadvantage.Also,alackofdetailinthestoriesinthebacklogcanresultinlostinformationovertime.

.2 Business Value DefinitionInorderforaprojecttodelivervalue,theprojectteammustfirstbeabletoidentifywhetherarequestisactuallyvaluabletotheorganization.Withoutaclearunderstandingofbusinessvalue,itispossiblefortheprojecttodeliversomethingthatsoundsvaluablebutisactuallynot.

Aprojectcreatesbusinessvaluewhenitdeliversanythingthatcontributestoanorganization'sstatedprimarygoals,forexample

• increasingorprotectingrevenue,• reducingoravoidingcosts,• improvingservice,




• meetingregulatoryorsocialobligations,• implementingamarketingstrategy,and• developingstaff.

Oftenprojectscreateoptionsforthebusinesstoexploit.Forexample,theoptiontosell1000itemsofaproductaday.

Businessvalueshouldbeexpressedasarangeorsetofbenefits.Theevolutionofclarityaboutbusinessvaluewilldevelopunderstandingofwhytheprojectisneeded.Themostimportantaspectofexpressingbusinessvalueistheconversationthatgeneratesthesharedunderstanding.

Examplesofbadbusinessvaluestatementsare:

• Thisenablesstraightthroughprocessing.• Thiswillmake1milliondollars.• Thiswillsave1milliondollars.• Mr.Bigneedsthisproduct.

Noneoftheseshowalignmentwiththegoalsoftheorganization.

Examplesofgoodbusinessvaluestatementare:

• Thisprojectwillgenerateanadditional$20millioninprofit.Themodelisbasedonthefollowingassumptions:*Wemaintain25%ofthesalesofexistingproductXYZ($150millionayear).

• Thetotalcostofdesigning,producing,andmarketingtheproductis$7.5million.

• Ourproductisfirsttomarket.• Weareabletoreleasetheproductinthespring.

Thisstatementconveysunderstandingofwhytheprojectisneededandwouldlikelypromotevaluableconversationthatgeneratesasharedunderstandingoftheproject.

.3 Kano Analysis

Purpose

Kanoanalysishelpsanagileteamunderstandwhichproductcharacteristicsorqualitieswillprovetobeasignificantdifferentiatorinthemarketplaceandhelptodrivecustomersatisfaction.




Description

Kanoanalysisassistsinidentifyingfeaturesthatwillhavethegreatestimpactoncustomersatisfaction,eitherbecausetheyareexceptionallyimportantorbecausetheirabsencewillcauseintensedissatisfaction.Thishelpstheteamdeterminewhichfeaturesaremostimportanttoimplementbeforereleasingaproducttomarket.

Kanoanalysisratesproductcharacteristicsontwoaxes:

• theextenttowhichthefeatureisimplementedintheproduct,and• thelevelofcustomersatisfactionthatwillresultfromanygivenimplementationlevel.

Theresultinggraphisplottedona2×2matrix.Basedontheresultingprofile,theproductcharacteristicshouldfallintooneofthreecategories:

• thresholdcharacteristics,• performancecharacteristics,and• excitementcharacteristics.

Thisanalysiscanthenbeusedtotryandidentifycharacteristicsthatwillgivetheproductauniquepositioninthemarketplace.

Elements

Threshold Characteristics

Thresholdcharacteristicsarethosethatareabsolutelynecessaryforstakeholderstoconsideradoptingaproduct.Theirabsencewillcauseintensedissatisfactionbut,astheyrepresentminimumacceptancecriteria,theirpresencewillnotincreasecustomersatisfactionbeyondacertainlowlevel.Thechallengewithelicitingrequirementsforthesefeaturesisthatpeopleexpectthemtobepresentandsotendnottothinkaboutthemunlessexplicitlyasked.

Performance Characteristics

Performancecharacteristicsarethoseforwhichincreasesinthedeliveryofthecharacteristicproduceafairlylinearincreaseinsatisfaction.Theyrepresentthefeaturesthatcustomersexpecttoseeinaproduct(speed,easeofuse,etc).Requirementsforthesetypesoffeaturesarelikelytomostreadilycometomindforthemajorityofstakeholders.




Excitement Characteristics

Excitementcharacteristicsarethosethatsignificantlyexceedcustomerexpectationsorrepresentthingsthatthecustomerdidnotrecognizewerepossible.Theirpresencewilldramaticallyincreasecustomersatisfactionovertime.Asthesecharacteristicsarenotmetbyanythingcurrentlyonthemarket,stakeholderswillnottendtothinkaboutrequirementsthatdescribethem.


Inordertodeterminethecategorytowhichacharacteristicorfeaturebelongs,customerscanbesurveyedusingtwoformsofaquestionaboutthefeature:

• Functionalform:Howdoyoufeelifthisfeatureorcharacteristicispresentintheproduct?

• Dysfunctionalform:Howdoyoufeelifthisfeatureorcharacteristicisabsentintheproduct?

Possibleanswerstoeachquestionformare:

• Ilikeitthatway.• Iexpectittobethatway.• Iamneutral.• Icanlivewithitthatway.• Idislikeitthatway.

Determiningthecategoryisbasedonmappingtheanswerstobothformsofthequestiontothefollowinggrid.Thetoprowrepresentstheanswerstothedysfunctionalformofthequestion.Theleftcolumnrepresentstheanswerstothefunctionalformofthequestion.




TABLE 4.4 Kano Analysis Questions Grid

Thisapproachismostapplicableforconsumerproductsorgoodsthatwillberesold,asitfocusesonidentifyingrequirementsthatwillencouragewidespreaduseoradoptionofaproduct.Thecategorizationofaparticularcharacteristictendstoshiftovertime,ascustomersgrowtoexpectfeaturesorcharacteristicstobepresentinaproduct.Exciterseventuallybecomeastandardexpectationandthresholdcharacteristic(thinkofthenoveltyofATMswhentheywerefirstintroduced;nowcustomersassumetheirbankwillhaveATMs).

.4 MoSCoW Prioritization

Purpose

Toidentifythemostcriticalsetoffeaturesorstoriesthatwilldeliverbusinessvalueandproducedasequenced,prioritizedlist.

Description

MoSCoWisamethodtoprioritizestories(orotherelements)inincrementalanditerativeapproaches.MoSCoWprovidesawaytoreachacommonunderstandingonrelativeimportanceofdeliveringastoryorotherpieceofbusinessvalueintheproduct.

Allstoriesinthebacklogarevaluable,butoftennotallofthemcanbedeliveredatthesametime.MoSCoWprovidesamechanismfor

Like Expect Neutral Live With Dislike

Like Q E E E P

Expect R I I I T

Neutral R I I I T

Live With R I I I T

Dislike R R R R Q

E=Exciters

P=Performance

T=Threshold

I=Indifferent(Doesnotfitintooneofthe3categories)

QorR=QuestionableorReversed(theanswerdoesn'tmakesense)




prioritizingstoriesinabacklogacrossmultiplereleases.Prioritizationisimportantforanysoftwaredevelopmentapproach,butagileapproachescannotsucceedwithoutconstantandfrequentprioritizationofwork.

MoSCoWgetsitsnamefromanacronymformedbythefollowingclassificationsofpriority:Musthave,Shouldhave,Couldhave,andWon'thave.Theletteroisaddedtomaketheacronympronounceable.Theclassificationsareasfollows:

• Must:TheuserstoriesthataddsignificantvalueandconstituenttheMinimalMarketableFeatureset.

• Should:Theuserstoriesthatadddistinctvalue,butarenotrequiredfeatures.

• Could:Theuserstoriesthataddsomevalue,buthaveminimalimpactonfeatures.

• Won't:Theuserstoriesthataddlittletonovalue,andwillnotbeincludedasfeatures.

Thereisanexpectationthatprioritiescanchangeoverthelifeofaproject,andprioritiesarereassessedonaregularbasis.

Elements

Product Backlog

Acollectionofuserstoriesdescribingthedesiredfunctionalityofaproduct.

Strategy

Anunderstandingoftheoutcomesforaninitiative.

Customer Preference

Clarityonwhatismostimportanttothecustomer.


MoSCoWisusefulwhentryingtoprioritizeabacklog.Unlikesomeprioritizationmethods,thismodelhelpsdifferentiatebetweenasetofusefuluserstoriesfromthosespecificallyfocusedonanoutcome.AftergroupingthebacklogelementsintheMoSCoWcategoriesitisimportanttothensequenceatleasttheMustHaveandShouldHaveelementsintoaranked/numberedorderasthiswillbeusedtosequencetheworkonthebacklogitems.




SometoolsmaynotsupportMoSCoWasaprioritizationstructureandmayneedtobeconfiguredtosupportit,inwhichcaseanalternatecategorizationmaybeappropriatesuchas“High,Medium,Low”.

Advantages• MoSCoWiseasytodescribeandtypicallyispowerfulinprioritizingbacklogs.

Disadvantages• MoSCoWcanbesubjective.Ifthereisnoteffectivecollaborationamongtheteammemberswithacarefulfocusonbusinessvaluethismethodofprioritizationcanbeinaccurate.

• Onaprojectwhereabusinessvalueincrementsapproach(MinimalMarketableFeatures)isused,theteamshouldonlydeliverMustHavesintheincrement.MoSCoWisthereforeinappropriate,howeveritisstillimportanttoprovideasequencedlisttoprovideguidancefortheorderinwhichworkshouldbeundertaken.

.5 Purpose Alignment Model

Purpose

Thepurposealignmentmodelisusedtoassessideasinthecontextofcustomerandbusinessvalue.Fromanagileperspective,themodelaidsinmakingprioritizationdecisionsandfocusinginvestmentonthosefeaturesorcapabilitiesthatareofgreatestvaluetotheorganization.

Description

Thepurposealignmentmodelisusedtorateactivities,processes,products,orcapabilitiesintwodimensions,andusethatinformationtohelprecommendthebestactionstotaketoimprovethembasedonthoseratings.Thefirstdimensioniswhetherornottheactivitycreatesmarketdifferentiation,theseconddimensioniswhetherornottheactivityiscriticalforthecontinuedfunctioningoftheorganization.




Thefollowingillustrationisanexampleofapurposealignmentmodel.

FIGURE 4.6 PurposeAlignmentModel

Elements

Differentiating Quadrant

Features,products,orservicesthatbothservetodifferentiatetheorganizationinthemarketplaceandarecriticaltothefunctioningofthecompanyarepartofthedifferentiatingquadrant.Thesearethethingsinwhichtheorganizationshouldbepreparedtoinvesttooffersomethingthatisdistinctfromcompetitorofferings.Adifferentiatingactivityisonethatmightbeusedtoadvertisethecompany,thatisdifficultforcompetitorstomatch,orotherwisehassignificantstrategicvalue,andauniqueapproachtotheseactivitiesislikelytobeneeded.

Parity Quadrant

Thingswhicharemissioncritical,butnotmarketdifferentiating,fallintotheparityquadrant.Manystandardfunctions,suchasfinance,HR,payroll,andothersfallintothisquadrantformostorganizations.Activitiesinthisquadrantareimportantbuttheydonotprovidean




advantagetothefirminrelationtocompetitorsandsoadoptionofbestpracticesisgenerallysufficient.

Partner Quadrant

Activitiesthatmayhaveuniquevaluetocustomers,butwhicharenotcriticaltothefunctioningoftheorganization,fallintothepartnerquadrant.Eventhoughtheseactivitiesareimportanttocustomersorotherstakeholders,theorganizationdoesn'tneedtoperformthemtosurvive.Thatmeansthattheorganizationisunlikelytohavetheresourcestoexcelattheseactivities(asmoremission‐criticaloperationswilltakeprecedence),whileapartnermayperformthemmoreeffectively.

Who Cares? Quadrant

Activitieswhichareneithermission‐criticalnorhelptodifferentiatetheorganizationinthemarketplacefallintothewhocares?quadrant.Astheseactivitiesdonotaddcustomervalue,andtheorganizationcanfunctionwithoutperformingthem,theyareprimecandidatestobeeliminatedandtheresourcesreallocatedtosupportmoreusefulwork.


Thepurposealignmentmodelisdesignedforusebyfor‐profitorganizationsthatfacecompetitioninthemarketplace.Governmentalorganizationsandno‐profitsmayfindthatmarketdifferentiationisnotasignificantdriverfortheirdecisions.Stakeholderormembervalue,alignmentwiththeorganizationalmissionordeliveryofsocialgoodmayserveasanalternativetothemarketdifferentiationdimension.Evenwhendifferentlabelsareusedforthedimensions,thethinkingbehindtheuseifthemodelremainsthesame.

Secondly,themodelprovidesguidanceonwhethersomethingshouldbeanareaofstrategicconcernbutdoesnotprovideanyguidanceonwhatstrategiesordecisionsmightbethecorrectones.

Advantages• Oneofthekeyadvantagesofthismodelisitssimplicity.Itcanbetaughttobusinesssponsorsandusersinacoupleofminutessothattheycancriticallyassessanideathemselvesratherthanthebusinessanalystdotheanalysisthatmaythenbechallenged.

• Themodeliseasytouseinafacilitatedcollaborativeenvironment.• Itcanbeappliedallthewayupanddowntheinvestmentdecisionprocess.Fromstrategicinvestmentdowntoanindividualfeatureinasystem.

• Itisfastandentirebacklogcanbeanalyzedinlessthananhour.


Agile Techniques The Delivery Framework


Disadvantages• Itassumespositiveintentinthebusinessstrategy.Itdoesnotincorporate“spoiler”behaviourbycorporations.

4.6 The Delivery FrameworkTheDeliveryFrameworkdealswiththehowsandthewhensoftheproduct.Effectivedeliveryissupportedbyfourunderlyingprinciples:

• GetRealUsingExamples,• UnderstandWhatisDoable,• StimulateCollaborationandContinuousImprovement,and• AvoidWaste.

4.6.1 Get Real Using Examples

Inagileapproaches,inordertoelicitandvalidateproductneedsbusinessanalysispractitionersuserealcustomerexamplestocommunicatewiththeteam,includingthecustomer.Realexamplesservetobridgeunderstandingofthecustomer'sbusinessandhowtheyseetheproductservingafuturestateneed.Analysismodelscanbeconcurrentlydevelopedandelaboratedusingthesesameexamples.Modelsmaybeusefulfortheteambutexamplesaremoreconcreteforthecustomer.Thetechniquesareusediterativelybyalternatingbetweenexamplesandanalysismodelstoexploremultipledimensions(forexample,userrole,useractions,data,andbusinessrules)ofaproductneed.Thisisacontinuouspracticethatbuildsasharedteamunderstandingofproductneedsusefulforbothplanninganddelivery.Thesetechniquesengagecustomersinrequirementselicitation,analysis,andvalidation.

Examplesandmodelsshouldbeatalevelofgranularitythatisappropriatefortheoutcomeyouseek.Whenplanningtheproduct,modelsareusedtosetcontextandhelptheteamandcustomeridentifyscope.Thesemodelsaremoreabstractandprovideabroadperspectiveoftheproblemdomain.Whendeliveringtheproduct,thesamemodelcanbeprogressivelyelaboratedandrelatedexamplesareelicitedandspecifiedtolaunchintoadeeperdiscussionofthedimensions.Theexamplescanbeusedtoderiveacceptancecriteria,


The Delivery Framework Agile Techniques


helpthedeveloperdesignthesolution,andprovideafoundationforfunctionaltesting.


• BehaviourDrivenDevelopment.

ThereareothertechniqueswithintheAgileExtensiontotheBABOK®

Guide,theBABOK®Guide,andotheradhoctechniquesthatcanbeutilizedhereaswell.

.1 Behaviour Driven Development (BDD)

Purpose

Anapproachthatenhancesthecommunicationbetweenstakeholdersandprojectteammembersbyexpressingproductneedsasconcreteexamples.

Description

Traditionalbusinessanalysistechniquesofteninvolvecreatinganalysismodels.Inadditiontoanalysismodels,agiletechniquesfavourcommunicationusingexampleswhicharemoreconcreteforthecustomer.Manypeopleareuncomfortablewithabstractionsandprefertoworkwithrealexamples.

Examplestendtobeadditive(growinginbothclarityoftheneedanddetailofthesolutionastheprojectprogresses)andcanformaspecification.Theycanbeusedduringagileplanninganddeliveryworktohelpclarifyanddescribetherequirementsfortheproductbeingbuilt.Asmodelschange,examplescanberefinedbybuildingonpreviousexamples.Inagile,itishelpfultoiteratebetweenusingexamplesandanalysismodelsencouragingthemtocomplimenteachother.Progressiveelaborationleadstoricherexplorationofmultipledimensions(forexample,userrole,useractions,data,andbusinessrules)relatedtotheexample.

Supplementingproductneeddiscussionswithexamplescreatesamuchmorestablesetofrequirementsthanusingamodelalone.Examplesfeedsmoothlyintoabehaviour/testdrivendevelopmentapproach.




Elements

Examples

Examplesmayalsobeknownasscenarios.Examplesshouldnotbeartificialormadeup.Theyshouldbereallifebusinessscenariosprovidedbythebusinessusers.Businessanalysisactivitieshelptofacilitatethediscoveryoftheexamplesandensurethatthesetofexamplesiscomprehensive.Notallexamplesidentifiedwillnecessarilybewithinthescopeofadevelopmenteffort.

Behaviour Driven Development

Behaviourdrivendevelopmentprovidesasimplegrammarformatthatallowsrealscenariostobefilledin.Thistakestheform

• GIVEN<acontext>• WHEN<anevent>• THEN<anoutcome>

BothGIVENstatementsandmultipleTHENoutcomesforasinglescenariocouldbecompoundconditionslinkedwithANDstatements.ThereisnormallyonlyoneWHENeventthattriggersthescenario.

Forexample,anATM.

Scenario1:Accounthassufficientfunds.

• GIVEN:I'mincredit• ANDtheATMhassufficientcashavailable• WHEN:Irequest$20• THEN:Ireceive$20• AND:myaccountbalanceisreducedby$20• AND:mycardisreturned

Scenario2:Accounthasinsufficientfunds.

• GIVEN:I'minoverdrawn• ANDtheATMhassufficientcashavailable• WHEN:Irequest$20• THEN:Ireceivenomoney• AND:mycardisreturned

Scenariosthatarewritteninabehaviourdrivendevelopmentformatspecifyingevents,conditions,andactionsareverifiable.Theycanserveasacceptancecriteriaforstories[See“StoryElaboration”on




page68]andserveastestsinsupportofAcceptanceTestDrivenDevelopment(ATDD)thatdriveacommonunderstandingofrequirementsandfutureproductneeds.

ThetermsBDD,ATDD,andSpecificationbyExampletendtobeusedinterchangeablyingeneraluse.

Testing

Therearenowanumberofsoftwareproductsthatwilltakeexamplesinthisformat(butmayhavetheirownspecificsyntaxandstructure)andallowthemtobeeasilyconvertedintoautomatedtests,thusenablingmoreagiledelivery.Withacomprehensivesetofexamplesthatcanbeexecutedasautomatedtests,businessanalysisandtestingactivitiescanbemoretightlycoupled.


BDDisatechniquetomakeneedsclearandisdesignedtoimprovecommunicationandunderstandingacrossallmembersofaprojectteam.Technicalteammembersusetheexamplestounderstandwhattheproductneedstodo(development)andhowtoensurethatitdoeswhatisneeded(testing).Customerrepresentativesprovidetheexamplesandclarifytheirthinkingbydoingso.BusinessAnalysisentailsidentifyingthescenariosbyaskingmany“what‐if”questiontoexposeadditionalscenariosandexpressingtheseasadditionalexamples.

Advantages• BDDexpressescustomerneedsinnaturallanguage,inaformatthatallteammembersshouldbeabletoeasilyunderstand.

• ThestructureofBDDlendstowardsacceptancetestautomationandsupportstheproductionofeffectivetestcases.

• ToolsexisttosupporttheuseofBDDinprojects,andtheseprovideadditionalmetricssuchastestcasecoverageorrequirements.

• Scenarioscanbeeasilyprioritizedwhichsupportstheiterative,incrementalnatureofagileprojects.

Disadvantages• Itispossibletomissimportantscenariosunlessthereissomeonewhoactivelyasksthe“whatif”and“whatabout”questions.

• Wherebusinessrulesareverycomplextherecouldbetoomanyscenariostoeasilymanageandtrackwithouttoolsupport.




4.6.2 Understand What is Doable

Asanagileprojectteamplansfordelivery,itisimportanttothinkaboutwhatispragmaticanddoable.Theteammustbalancecapacityanddemandwhentheyestimatetheworktobedonetodelivertheproduct.Agileprojectteamscontinuallyreviewmeasures,suchasteamcapacity,priordeliverycyclecommitmentsandactuals,andvelocitytrendstoadjustcommitmentsonanon‐goingbasis.Thisenablestheteamtoquestionwhatcanbedeliveredgiventheirknowledgeofthework‐set,andtosetappropriateexpectationsandmakebetterestimates.Understandingwhatisdoableoccursthroughoutanyagiledeliverycycle,suchasreleaseplanning,work‐aheadanalysis,orwheneverateamispullingnewbacklogitemsforconsiderationinaproductdeliverycycle.

Theentireteamusesthefollowingtechniquesasmethodstoidentifyandestimateunitsofworkthataredecomposedwithbusinessvalueinmind.


• RelativeEstimation,• PlanningWorkshop,and• RealOptions.



.1 Relative Estimation

Purpose

Accurateestimationiscriticaltoanagileteam'sproductivity,reliability,andreputation.Bybeingabletodevelopaccurateestimatesofcost,time,andeffort,theagiledevelopmentteamhastheabilitytofaithfullycommittoaprojectorworkeffort.

Estimationisateamactivity,andbusinessanalysismakesanimportantcontributionbyhelpingtheteamtobetterunderstandthecomponents,characteristics,andcomplexityofthework.




Althoughestimatesarenotalwaysvisibleinthefinalproduct,theydoaddsignificantvaluetoanagileproject.Providingcredibleestimatesallowstheprojectteamto:

• determinecostandeffort,• establishtheprioritiesoftheproject,and• committoaschedule.

Onagileprojectsestimationisnotrestrictedtobeinganinitialplanningactivity,itisfrequentlyundertakenearlyintheprojectduringtheinitialstoryidentificationactivitiesandestimatesarerefinedandimprovedthroughconstantfeedbackintheongoingiterationplanningactivities.

Description

EstimationisdiscussedatlengthintheBABOK®Guideversion2.0(9.10Estimation).HerewebuildontheinformationintheBABOK®Guideandsummarizetherelativeestimationtechniquesthatcanbeappliedintheagiledevelopmentenvironment.

Uniquetoagileapproaches,estimatingisprogressiveandoccursinalignmentwithiterations.Nooneexpectsearlyestimatestobeasaccurateaslatterestimates.Improvementoccursovertimeastheteamsbuildconfidenceintheircapacityandcapabilities.

Inadditiontothebasicapproachofestimatingbasedonhistoricalknowledge,agileestimatorsfrequentlyapplyarelativeestimatingmodelinwhichteamsdevelopnarratives(stories)thatdefineuserneedsandbenefits.Thesestoriesareanalyzedbytheteamandnumericvaluesareappliedtoeachstory(storypoints).Storypointsarenormallyusedasanabstractmeasurementthatprovidesanumericvaluetoastory;someteamsandorganizationsuseidealdeveloperdays(IDDs)insteadofrelativepoints,althoughmanycommentatorsrecommendagainstthisapproach.

Astorypointisarelativenumberassignedtoeachstorythatdefinestheestimatedeffortateamwillhavetoapplytodeliverthestory.Storypointsareusuallybasedonwhattheteamknowsaboutthestoryinfourkeyareas:

• Knowledge:Howmuchinformationdoestheteamhave?• Complexity:Howdifficultistheimplementationlikelytobe?• Size:Howbigisthestory?Howlongwillittake?




• Uncertainty:Whatvariablesandunknownfactorsmightimpactthestory?

Thetotalnumberofstorypointsdelivered(totheagreedDefinitionofDone)withinanygiveniterationisconsideredtobetheteam'svelocity,orhowmuchateamaccomplishedwithintheiteration.Overseveraliterationsteamswillhaveabetterunderstandingoftheiractualvelocity.Thiswillallowthemtomakebetterinformedestimatesandcommitmentsinsubsequentiterations.

Thereareseveralwaystogetstartedwithstorypointestimation.Theagileestimatorcanbeginwith

• anorderofmagnitude,• agivensetofresourcesandafixediteration,or• ateambasedestimationofthetimerequiredforasampleofstoriesofdifferentsizes,andthenextrapolatefromtheretoestimatetheworkthatcanlikelybedoneinaniteration.

Usage Consideration

Advantages• Relativeestimationisasimple,reliablemethodologythatfitswellwithagilepractices.Itishighlyadaptiveandislikelytobecomeincreasinglyaccuratethroughoutsuccessiveiterations.

• Theplanningpokertechniqueisahighlycollaborativeprocessthatisbasedonconsensusandwilllikelyhaveapositiveimpactondevelopmentteams.Itbuildsuponthewisecounselto“asktheteam.”

Disadvantages• Relativeestimatesarebasedonhistoricaldata,andaccuracyisdependentuponthesimilarityofnewstoriestostoriespreviouslydelivered.Ifnewstoriesdifferradicallyfrompreviousstories,itispossiblethattheaccuracyoftheestimatemaydecrease.

• Theaccuracyofvelocityisdependentontheknowledgeandexperienceofthedevelopmentteamworkingtogether.Anychangestoteamcompositionwillimpactvelocityandthereforefutureestimates.

• Planningpokerandrelativeestimationarenottheonlyapproachestoestimationandnotallteamsestimatetheirworkbeforestarting.Thereareotherapproacheswhicharenotdefinedindetailhere,andothermetricswhichareoftentracked.




.2 Planning Workshop

Purpose

Toenabletheteamtodeterminewhatvaluecanbedeliveredoveranagreedtimeperiod.

Typicallytherearetwolevelsofplanningworkshop:

• onethatcoversthecurrentreleaseoftheproductandtakesplacepriortothestartofiterations,and

• amoredetailedworkshopthatfocusonworktobedoneduringtheiteration.

Description

Aplanningworkshopisexecutedwhentheteamneedstoarriveatacommitmenttosomesetoffunctionalitythattheyfeelreasonablyconfidenttheycancompleteoveranagreedtimeperiod.

Thereleaseplanningworkshopproducesthereleaseplanshowingtheintendedsequenceofdeliveryofuserstoriesoverthewholerelease.

Theiterationplanningworkshopisperformedatthebeginningofeachiteration,butmayalsooccurwhenevertheteamisneartocompletingtheirbacklogofworkorthatbacklogneedstobeordered.Itisimportantthattheteamunderstandsandfocusesontheiterationobjectives,thevalueassociatedwithaparticularMMF,businessissues,storydecomposition.Priortotheworkshop,thereisapre‐planningstagethatinvolvesanalysistogetareasonablegaugeofthesize,scope,andcomplexityofeachbacklogitemthatwillbebroughttotheiterationplanningworkshop.

Inagileapproachesplanningworkshopsneedtobeperformedonafrequentandregularbasisastheorderinwhichworkismeanttobeperformedisregularlyalteredandupdated.Thisallowstheteamandcustomerstochangetheprioritiesofoutstandingworktoincorporatefeedbackorchangingbusinessneeds.

InKanban,theamountofworkbeingperformedbytheteamislimitedbyrestrictingthenumberofworkitemsthatcanbeinanyworkflowstate,notbasedoniterations.




Elements

Estimated and Ordered Backlog

Typicallybasedonuserstories,itisthemaininputfortheplanningmeeting.

Team Velocity

Priorvelocity(throughputcapacityofbacklogitems)iscriticaltoenablingtheteamtoschedulearealisticamountofwork.WhenusingKanban,work‐in‐progress(WIP)limitswillbeusedtomanagethisworkloadinstead.

Iteration Goal or MMF Set

Manyteamssetanoverallgoalfortheiterationtohelpguidetheselectionoffeatures.Thisisasubsetofthereleasegoal.Itisanobjectivethatwillbemetthroughtheimplementationoftheproductbacklog.

Requirement Selection

Atthebeginningofthemeetingtheiterationgoalandthehighestpriorityfeaturesareselectedfromthereleaseplanbytheproductowner,productchampion,oracustomerbasedonbusinessvalueandteamvelocity.

Non-Feature Selection

Thebacklogcanalsobecomposedofnon‐featureitems(elementsnotrelatedtoaproductincrement)identifiedasnecessarytoachievetheiterationgoalordeliveranMMF.Forexample,therecanbebugstobefixed,systemorenvironmentsetup,researchinitiatives,managementworkitems,oranyotheractivitythataddvaluetotheproject.

Task Planning

Theteamcanchoosetobreakthefeatureandnon‐featureitemsdownintotasks.Taskstypicallyrangeinsizefrom4hoursto2days,withmosttaskscapableofbeingdeliveredwithinaday.


Advantages• Customer,productowner,anddevelopmentteamcancommunicateandcollaboratefrequentlyaboutproductvisionandevolution.

• Customerandproductownercanguidetheprojectnotjustatthestartbutateveryiteration.




• It'seasiertounderstand,estimate,andplanthescopeofsmalliterationsinsteadofthescopeofbigreleases.

• Planscanbechangedinadvancebasedonfeedbackfromincrementaldeliveryofworkingsoftware.

• Iterationplanningcanfacilitatevisibilityofthewholeprojectandsynchronizationbetweenmultipleteams.

Disadvantages• Itisnecessarytogetallpeopletogetherinordertoavoidinterruptionsandrework,especiallywhenworkingwithdistributedorconcurrentteams.

• Iftheproductisnotwellunderstoodduringtheiterationplanningworkshop,it'spossibletoresultinasuboptimalplan.

.3 Real Options

Purpose

Anapproachtohelppeopleknowwhentomakedecisionsratherthanhow.Theapproachhelpsyouunderstandwhetheryouhaveacommitmentoranoption.

Description

Thecoreconceptbehindrealoptionsisthatyoushoulddelaymakingadecisionoracommitmentinaprojectuntilthelastresponsiblemoment,whenthedecisionreallyneedstobemade.Therealoptionapproachhasthreesimplerules:

• optionshavevalue,• optionsexpire,and• nevercommitearlyunlessyouknowwhy.

Thefirstandthirdruletellyoutoavoidcommitmentsandkeepyouroptionsopen.Thesecondruletellsyoutounderstandwhenanoptionexpiressothatyoucanactivelymanagewhetheryouchoosethatoptionorletitlapse.Asthereisvalueinoptions,youshouldseektoextendthematurityoftheoptions.

Realoptionsaddresspeople'saversiontouncertaintybyprovidingtheconditionswhenacommitmentshouldbemade(theoptionexpiry)ratherthansimplysuggestingthattheywait.

Themostcommonusageofrealoptionswithinagileprojectsisthewayinwhichbusinessinvestorschosewhichitemtoinvestinnext.




Traditionally,investorsprioritizetheirrequirementsforanextendedperiodoftime.Withrealoptions,theyonlyprioritizeuntilthenextinvestmentdecisionpoint.OnScrumprojectsthisoccursduringthenextsprintplanningsession.InKanban,itoccursthenexttimecapacitybecomesavailabletoworkonsomethingnew.

Realoptionssupportagileapproachesbyallowingustoreducethenumberofdecisionswehavetoconsideratanyonetimeanddelayingdecisionsaboutthedetailofrequirementsaslongaspossible.Thisisachievedbytreatingthedetailofrequirementsasoptionsandthecommitmentpointiswhenweelaborateindetail.

Elements

Options and Commitments

Realoptionsforcesyoutoidentifywhetheryouhaveoptionsornot,andalsoforcesyoutoidentifythecommitmentsyouaremaking.

Examplesofoptionsinclude:

• Auserstory:anoptiontoimplementapieceoffunctionality.Theoptionexpireswhenthebusinessneedchanges.

• Ahotelreservation:anoptiontostayatthehotel.Theoptionnormallyexpiresat6p.m.onthedayofthestayatwhichpointyouarecommittedtopayingforthehotelroom.

• Abusinesscard:theoptiontocontactthepersonwhogivesyouthecard.Theoptionexpireswhenthepersonchangescontactdetails.

Optionsarethingsyoucanchosetodoornotdo.Ifyouarecommittedtodoingsomethingandthereisonlyoneway,thenyoudonothaveoptions.Oftenthereisapenaltyassociatedwithfailingtomeetacommitment.

Someexamplesofcommitmentsinclude:

• Usingtheorganization'sstandardsoftwaredevelopmentlanguagetobuildaproduct.

• Turninguptoworkontime.Failuretomeetthiscommitmentmayresultinterminationofyourcontractofemployment.

• Deliveringitemsfromthebacklogthatyouhavecommittedtodeliver.Failuretomeetthiscommitmentwillreducetrustanddamagetheteam'sreputationwithcustomers.




Examplesofthingsthatarenotoptions.

• Thingsyoucannotdo.• Thingsyoucannotafford.• Thingsyoucannotdointime.• Thingsyoucannotbuyorsell.• Thingsyoudonothavethetoolsfor.

Options Expiry

Realoptionsforcesustounderstandwhenouroptionsexpireorwhenwenolongerhaveachoice.Wehaveanoptionuptotheexpirydatebutnotafterit.Infinancialoptions,theexpirydateoftheoptionisexplicitlystatedasaseriesofdate/times.Inrealoptions,theexpirydateisconditional.

Determinationofwhenanoptionexpiresisthemostimportantaspectofrealoptions.Withoutthisknowledgeyouareblindinyourdecisionprocess.Youeithermakedecisionstoosoonortoolateandyoudonotknowwhich.

Example

Youhaveauserstoryinthebacklogwhichisduetobedeliveredinthenextiteration.Priortotheiterationplanningworkshopyoucanelaboratethestorytoacceptancecriteriatoensurethereissufficientunderstandingthatthepieceoftheproductcanbebuilt.Notdoingthestoryelaborationcouldresultinsurpriseswhentheworkisstartedonthestorywhichmayresultintheteambeingunabletomeettheircommitmentsforthecurrentiteration.

Asoptionshavevalue,pushingtheexpirydatebackaddsvaluetoyourprojectandallowsyoumoreflexibility.Theconceptofthe“lastresponsiblemoment”iskey‐makingdecisionstooearlyrestrictsourchoices,anddeferringthemtoolongcanresultinreworkorotherwaste.

Right / Wrong / Uncertain

Arationaldecisionprocesswouldorderourpreferenceasbeingright,thenuncertain,andfinallywrong.Observingpeople'sbehaviourthoughtheirpreferenceisright,wrong,andthenuncertain.

Ifyouasksomeonetodeferadecision,theyarefacedwithunboundeduncertaintyandasaresulttheyarelikelytomakeadecisionbasedontheinformationtheyhavenow.Thisemotionalcommitmentthenmakesithardertochangethedecisionasfurtherinformationarrives.




Realoptionssuggestsusingboundeduncertainty.“Makethedecisionwhen...”Specifytheconditionswhenthedecisionshouldbemade.

Specifyingtheconditionswhenacommitmentshouldbemadeallowsthedecisionprocesstobemanaged.Aseniormanagercanasktheirassistanttomonitortheconditionsonhisbehalf.

Feature Injection

Featureinjectionisacollectionoftraditionalbusinessanalysistechniquesthathavebeencombinedtoallowabusinessanalysttoperformanalysisinafastandeffectivemanner.Thisspeedthenallowsinvestmentcommitmentstobedeferredbecausethisreducesthelengthoftimethatanalysistakes.

ThespeedoftheprocessisduetofollowingtheRealOptionsprocess.Theanalysisstartswiththeoutputandthenworksbackthroughtheprocesstotheinputs.Itthenconsidershowdifferentexamplesaffecttheprocess.

Therearethreestepstotheprocess:

1. Identifythebusinessvaluewhichspecifiestheoutputs/outcomesrequiredfromthesystem/process.

2. Injectthefeaturesthatworkoutwhichprocessesandinputsarerequiredtoproducetheoutputs/outcomes.

3. Usemodelstoidentifyalltheexamplesthatproduceadifferentbehaviourinthesystem/process.


Advantages• RealOptionssimplifydecisionmakingbyprovidingasimplesetofprinciplestofollow.

• RealOptionsmakedecisionmakingfastasyouonlyfocusontheimmediatedecisionsanddeferprioritizationuntilalaterdatewhencomplexityisresolved.

• RealOptionsinformwhen,nothow,toconstructdecisions,whichmakesthembroadlyapplicableasanapproach.

• RealOptionsoptimizeprocessesbyforcingtheconsiderationofthedecisionpointsandtheinformationarrivalprocess(whendataarrivesandwhetheritarrivesbeforethedecision).




Disadvantages• RealOptionscanbecounter‐intuitiveastheyrequireustoanalyzesystemsfromtheoutputstotheinputs.

• RealOptionsarenotasimpleprocesstobefollowedbyrote.Theyareathinkingtoolthatrequirespracticeandstudy.

4.6.3 Stimulate Collaboration and Continuous Improvement

Agileapproachesemphasizetheimportanceofcontinualcollaborationbetweenmembersoftheprojectcommunity.Itistheroleofthebusinessanalysttocreateanenvironmentwhereallprojectstakeholderscancontributetotheoverallprojectvalue,ideallyinfacetofacefacilitatedworkshops.Therealityformanyprojectsisthattheyaredistributedintermsofteam,time,andgeography.Facilitationskills,inconjunctionwiththetechniquesoutlinedinthissection,enablescollaborationforbothlocalanddistributedteams.Thetechniquesinthissectionentailworkingtogetheringroupstocreateasharedunderstanding.Thiscollaborativepointofviewpervadesanagileproject,andisnotlimitedtoanyspecifictechnique.

Oneofthefundamentalprinciplesofallagileapproachesistheneedforcontinuousimprovement,notjustoftheproductunderdevelopmentbutoftheprocessusedbytheteamtodelivertheproduct.Thisisachievedthroughbothstructuredandunstructuredfeedbackonacontinuousbasis.Forexample,theretrospectiveisanopportunityfortheteamtoexaminetheirprocessesandproducttoidentifyopportunitiesforimprovement.Healthycollaborativeteamshavethetrustandsafetynecessarytotransparentlyidentifyopportunitiesforimprovement.


• CollaborativeGamesand• Retrospectives.






.1 Collaborative Games

Purpose

Collaborativegamesarenotusedstrictlybyagileteams,althoughtheyareprevalentinagilepracticesbecausetheyemphasizetheconceptsofteamworkandcollaborationwhicharehighlyvaluedbyagilepractices.Collaborativegameshelpagroupofpeoplepromoteacommonunderstanding,gaininsightintoaproblem,orinspirenewideasaboutsolvingaproblem.

Description

Collaborativegamesrefertoseveralstructuredtechniquesinspiredbygameplayanddesignedtofacilitatecollaboration.Eachgameincludesrulestokeepparticipantsfocusedonaspecificobjective.Thegamesareusedtohelptheparticipantssharetheirknowledgeandexperienceonagiventopic,identifyhiddenassumptions,andexplorethatknowledgeinwaysthatmaynotoccurduringthecourseofnormalinteractions.Thesharedexperienceofthecollaborativegameencouragespeoplewithdifferentperspectivesonatopictoworktogethertobetterunderstandanissueanddevelopasharedmodeloftheproblemorofpotentialsolutions.

Collaborativegamesoftenbenefitfromtheinvolvementofaneutralfacilitatorwhohelpstheparticipantsunderstandtherulesofthegameandhelpstoenforcethem.Thefacilitator'sjobistokeepthegamemovingforwardandtohelpensurethatallparticipantsplayarole.

Collaborativegamesalsousuallyinvolveastrongvisualortactileelement.Activitieslikemovingstickynotes,scribblingonwhiteboards,assemblingthings,ordrawingpictureshelpovercomeinhibitions,fostercreativethinking,andthinklaterally.

Elements

Purpose

Gamesalwayshavesomedefinedpurpose,typicallytodevelopabetterunderstandingofaproblemortostimulatecreativesolutions.Theparticipantsinthegameneedtounderstandthatpurpose,andthefacilitatorwillhelpkeepthemmovingtowardit.

Process

Gamesalsohaveaprocessorrulesthattheyfollowtokeepthegamemovingtowarditsgoal.Often,eachstepinthegameistimelimited.Gamestypicallyhaveatleastthreesteps:




1. anopeningstep,wheretheparticipantsgetinvolved,learntherulesofthegame,andstartgeneratingideas,

2. theexplorationstep,whereparticipantsengagewithoneanotherandlookforconnectionsbetweentheirideas,testthoseideas,andexperimentwithnewones,and

3. aclosingstep,wheretheideasareassessedandparticipantsworkoutwhichideasarelikelytobethemostusefulandproductive.

Outcome

Finally,attheendofacollaborativegame,thefacilitatorandparticipantswillworkthroughtheresultsofthegameanddetermineanydecisionsoractionsthatneedtobetakenasaresultofwhattheparticipantshavelearned.


Itisnotpracticaltoelaborateonthemanycollaborativegamingtechniquesandtheirusageconsiderationsinthisdocumentbutthefollowingexamplesmayprovideastartingpoint.

TABLE 4.5 Examples of Collaborative Games

Advantages• Mayrevealhiddenassumptionsordifferencesofopinion.• Encouragescreativethinkingbystimulatingalternativementalprocesses.

• Challengesparticipantswhoarenormallyquietorreservedtotakeamoreactiveroleinteamactivities.

Disadvantages• Theplayfulnatureofthegamesmaybeperceivedassillyandbeuncomfortableforparticipantswithreservedpersonalitiesorculturalnorms.

Game Description ObjectiveProduct Box

Participants construct a box for the product as if it was being sold in a retail store.

Used to help identify features of a product that help drive interest in the marketplace.

Affinity Map

Participants write down features on sticky notes, put them on a wall, and then move them close to other features that appear similar in some way.

Used to help identify related or similar features or themes.

Fishbowl Participants are divided into two groups. One group of participants speak about a topic, while other participants listen intently and document their observations.

Used to identify hidden assumptions or perspectives.




• Gamescanbetimeconsumingandmaybeperceivedasunproductiveespeciallyifobjectivesoroutcomesareunclear.

• Groupparticipationcanleadtoafalsesenseofconfidenceinconclusionsreached.

.2 Retrospectives

Purpose

Theobjectiveofaretrospectivemeetingisforateamtocometogetherinordertoreflectonwhatithasdonewell,whatitcoulddobetter,andtoreachagreementonhowanyimprovementswillberealizedforboththeproductandtheprocessestheyusetocreatetheproduct.Retrospectivesareheldatkeymilestonesintheproductlife‐cycle,normallyattheendofeveryiteration,andateveryreleasesothatlearningscanbequicklyembeddedintheprocessesandpracticesgoingforward.

Description

Theretrospectiveprovidesanopportunityforallmembersoftheteamtoreflectonthemostrecentdeliveries.Theretrospectiveshouldincludethewholeteam.Itiscommonfortheretrospectivetobesplitintotwoparts.Thefirstpartinvolvingthewholeteamandthesecondparttodiscusstechnicalaspectsoftheprojectthatonlyaffectpartoftheteam.

Theretrospectiveshouldbefocusedonidentifyingissueswiththeprocess.Itshouldidentifyprocessimprovements,andnotbepersonalinanysense.Akeyelementofaretrospectiveisthattheteamfeelssafetodiscussanyissuethatconcernsthem.

Itmaybeusefulforretrospectivestobefacilitatedbyaneutralfacilitatorratherthanbyamemberoftheteam.

Wherefixediterationcyclesarenotbeingused,itisagoodideatoscheduleregularretrospectivessotheteamcanexaminetheirprocesses.

Elements

Preparation

Theteampreparesideasfromtherecentiterationthatmaybeanalyzedintheretrospective.




Safety Check

Theteammustagree,together,totrusteachotherandtobelievethateverycommentorsuggestionisintendedforthesolepurposeofimprovingtheteam'sperformance.

Identify the Issues

Therearemanymechanismstoidentifyissuestodiscuss.Oneofthemostcommonisforallteammemberstowriteupthingsthatwentwell,thingstoimprove,andthingsofinterestonpost‐itnotes.Colourcodingthenotesandapplyingthemtoavisualtime‐lineassistinaddingunderstandingtotheemergingpicture.

Choosing Future Actions

Oncealltheideashavebeendiscussedtothesatisfactionoftheteam,thefacilitatoraskstheteamtodecidewhichsolutions/improvementstheywanttofocusonnext.Theteamthenidentifieswhichimprovementswillbeaddressedandassignsresponsibilitytoanindividualteammemberwhoensuresthesolution/improvementisimplemented.


Advantages• Anexcellentwayfortheteamtofindacollectivevoicearoundopportunitiesforteamimprovement.

Disadvantages• Teammembersmayfeelobligedtopretendthattheytrusteachother,eventhoughtheydonot.

• Retrospectivesareonlyofvalueiftheteamactsuponthelearningfromthesessiontoimprovetheprocess.

• Mostideasraisedintheretrospectiveareknowntoatleastonememberoftheteam.Amatureteamshouldbeaddressingissuesastheyariseratherthanbatchingthemuptobehandledinaretrospective.

• Ifissuesraisedintheretrospectivearenotaddressed,thereisarisktoteammoraleandmotivation.

4.6.4 Avoid Waste

Agileapproachesemphasizethedeliveryofworkingsoftwaretothecustomer.Businessanalysisworkaddsvaluebyensuringthattheneedsofthecustomerareunderstoodandthattheteamdeliverswhat




thecustomerreallyneed.Anyactivitythatdoesnotcontributedirectlytothisgoal,orthatthecustomerwouldnotbewillingtopayfor,iswaste.

Wasteeliminationisanissuethathasbeentreatedwithgreatemphasisbytheagilecommunity.Itisamind‐setoriginatedfromLeanasaneffectivewaytoincreasetheprofitabilityofanybusiness.Leanthinkingconsidersavaluestreamashavingtwocomponents:

• valueaddingactivities,and• muda(theJapanesewordforwaste).

TheaimofLeanthinkingistoremovethemuda,orwaste,fromthevaluestream.Wasteisfurthersub‐dividedintotwocomponents:

• thoseactivitiesthathavevaluebutdonotcontributetothefinalproductdirectly,and

• thoseactivitiesthatdonotaddvalueatall.

Theaimistoremovecompletelythoseactivitiesthatdonotaddvalue,andminimizethoseactivitiesthatdonotcontributetothefinalproductdirectly.

Thefollowingprinciplesarehelpfulwhenworkingtoidentifywasteinanybusinessanalysisactivity:

• Avoidproducingdocumentationbeforeitisneeded.• Ensurecommitmentsaremetandtherearenoincompleteworkitemsthatadverselyimpactdownstreamactivities.

• Avoidreworkbymakingcommitmentsaslateaspossible.• Trytoelicit,analyze,specify,andvalidaterequirementswiththesamemodels.

• Analysismodelsshouldbeassimpleaspossible.Donotincludeinformationthatisnotdirectlyusefultoastakeholder.

• Workincloseproximitytothecustomersanddevelopmentteambecauseunnecessarymotionorwork‐a‐roundsthatsubstituteface‐to‐faceconversationsarealsowaste.

• Keepcontinuousattentiontotechnicalexcellence.Qualitydefects(suchasunclearrequirements)resultinreworkandareoneofthemostundesirableformsofwaste.


• LightweightDocumentation.





.1 Lightweight Documentation

Purpose

Ensurethatalldocumentationproducedisintendedtofulfillanimpendingneed,hasclearvalueforstakeholders,anddoesnotcreateunnecessaryoverhead.

Description

Lightweightdocumentationisaprinciplethatgovernsalldocumentationproducedinanagileproject.Theteamshouldaimtoproduceaslittledocumentationaspossible,allofwhichshouldbeofvalue.Thevalueofdocumentationshouldbeexplicitandclear.Inaheavilylegislatedenvironment,suchashealth‐care,compliancedocumentationhasvalueandisnotwaste.

Thecontextplaysanimportantfactorintheamountofdocumentationrequired.Someprojectsaremandatedtoproducedocumentationbyexternalentities(forexample,regulators).Documentationmayalsobeneededtoprovidealong‐termrecordofdecisionsreachedbytheteamorfunctionsimplementedintheapplication.Thisdocumentationcanbewrittenafterthesoftwareisdeveloped,whichensuresthatitactuallymatcheswhattheteamdelivered.

Itisworthconsideringthatifadocumentisvaluableenoughtobecreated,itisprobablyimportantenoughtobeautomatedsothatitispartofthelivingcodebase.Thisconsiderationhasledtotheriseofautomatedacceptancetestingandbehaviourdrivendevelopmentthatallowsbusinessanalyststoworkwithqualityassuranceprofessionalstocreateexecutablespecificationintheformofexamples.

ThisapproachcomesdirectlyfromtheAgileManifestowhichsays“Workingsoftwareoverextensivedocumentation”.Itisoftenmisinterpretedasmeaningnodocumentation.Instead,documentationshouldbebarelysufficienttomeettheneedsoftheteam.


Advantages• Reducesamountoftimespentwritingdocumentation.




• Reduceseffortspentreadingandreviewingdocumentation.• Reducesnumberofdraftsofdocuments.• Allreviewerscanfocusonkeyissuesratherthanextraneousdetails.

• Training(knowledgetransfer)isdonetosuiteachpersonratherthanusingthedocumentation.

• Thedocumentationlivesintheformofautomatedexamples.

Disadvantages• Producinglightweightdocumentationmaycauseconflictwithgroupswhoenforcecorporateprocessstandards.

• Somemaymisunderstandtheprincipleasmeaningnodocumentation.

• Someproducedocumentationthatisnotsufficientforanexternalentity.



AappendixGlossary

Acceptance CriteriaRequirementsthatmustbemetinorderforasolutiontobeconsideredacceptabletokeystakeholders.Acceptancecriteriacanrefertoarequirementofanygranularity,product,ordeliverycycle.

Acceptance Test Driven Development (ATDD)Involveswritingoneormoretests(or“customertests”)foracustomer‐centricfeature,beforethesolutionhasbeendeveloped.

Agile ManifestoAstatementoftheprinciplesthatunderpinAgileSoftwareDevelopment.ItwasdraftedfromFebruary11ththrough13th,2001.

Agile RetrospectiveRetrospectivesareavariationofprojectretrospectiveswherebytheretrospectiveworkshopisconductedatregularintervalsthroughoutthedeliveryprocess,suchasaftereachiterationand/orrelease.

Anti-patternAcommonlyused,yetineffective,processorpractice.

BacklogAwishlistofrequestsforfeaturestobeincludedinaproduct.

Backlog ItemAnelementthatbelongstoabacklog.Itcanbeafeature,abugfix,adocument,oranyotherkindofartifact.

Behavior Driven Development (BDD)Arequirementselicitationandspecificationtechniquethatenhancesthecommunicationbetweenbusinessusersandthedevelopmentteambyusingrealexamples.

Burndown ChartUsedtotracktheworkremainingovertime.WorkremainingistheYaxisandtimeistheXaxis.AlsoseeReleaseBurndownChart.

Business ValueInmanagement,businessvalueisaninformaltermthatincludesallformsofvaluethatdeterminethehealthandwell‐beingofthefirminthelong‐run.Inagiledevelopment,businessvalueisrelatedtoalldeliverablesthatincrease/protectrevenueorreduce/avoidcostsinabusiness.

CeremoniesControlledprocessesanddocumentsthatconstituteeventsandoutputsinanygivenapproach.Ahighdegreeofceremonyfrequentlyimpliesahighdegreeofcontrolandtraceability.Basedonthejust‐in‐time



andjust‐enoughmodel,agileprojectsgenerallyhavealowerdegreeofceremony.Agileceremoniesincludeiterationplanning,dailymeetings,andretrospectives.

Class-Responsibility-Collaboration (CRC) CardsAbrainstormingtoolusedinthedesignofobject‐orientedsoftware.

Daily MeetingOneachdayofaiterationtheteamholdsmeetings.Thismeetingisusedtosettheprioritiesandcontextforthedailywork.

Daily Scrum MeetingSeeDailyMeeting.

Daily StandupSeeDailyMeeting.

Delivery TeamAcross‐functionalteamofskilledindividualswhobringavarietyofexpertisetobearontheprocessofbuildingasoftwareproduct.

ElicitationAnactivitywithinrequirementsdevelopmentthatidentifiessourcesforrequirementsandthenuseselicitationtechniques(forexample,interviews,prototypes,facilitatedworkshops,documentationstudies)togatherrequirementsfromthosesources.

EpicApieceoffunctionalitythatenablesausertoachieveaclearlyidentifiedbusinessobjective.Epicsareoftenlargecomponentsofworkthatare

decomposedintosmallerstoriesandfeatures.Anepichelpstiefeaturesandstoriesbacktoavalue‐addedbusinessobjective.

Feature Adiscreetpieceoffunctionalitythathasmeasurablebusinessvalue.Afeatureisoftendeliveredthroughthedevelopmentofanumberofuserstories.

Iteration BurndownSeeProductBurndownChart.

Iteration PlanningTheprocessofassigninguserstoriestoparticulariterationsbasedonresources,effort,andpriority.

Just-in-time RequirementsRequirementsthatdefineonlywhatisneededforthecurrentiterationandonlytothelevelofdetailrequiredfortheteamtodelivertheitem.

Minimal Marketable Feature (MMF)Acoherentportionoffunctionalitythatiscapableofreturningvaluewhenreleasedonitsown.Thiscouldbeanepicorastory,butisanylevelofdetailthatisminimallyrequiredtocreateameaningful,valuablereleaseforthecustomer.

Minimal Viable Feature (MVF)Commonlyusedwithnewproducts.AlsoseeMinimalMarketableFeature.



On-site CustomersThetermusedfortheindividualresponsiblefortherelativeprioritiesforthesolutionrequirementsintheExtremeProgrammingapproach.

PersonaFictionalcharactersorarchetypesthatexemplifythewaythattypicaluserswillinteractwithaproduct.

Plan-drivenAsoftwaredevelopmentapproachthatfollowsanorderlyseriesofsequentialstages.Requirementsareagreedupon,designiscreated,andthenthecodeisdevelopedandtested.

Product Backlog ItemAproductbacklogitem(PBI,backlogitem,oritem)isaunitofworksmallenoughtobecompletedbyateaminoneiteration.

Product ChampionSeeProductOwner.

Product OwnerTheroleontheteamthatrepresentstheinterestsofallstakeholders,definesthefeaturesoftheproduct,andprioritizestheproductbacklog.

Alsoreferredtoasproductchampion,businessvoice,andcustomervoice.

Product RoadmapAlongterm/longrangeplanninghorizonfeaturestodelivervisionandvalue.

Progressive ElaborationTheactofcontinuallydefiningrequirementswithsuccessivelygreaterlevelsofdetailasneededthroughthelifeoftheproductorthefeaturewithinaproduct.

Rapid Application Development (RAD)Agenerictermreferringtoanynumberoflighter‐weightapproaches,usingfourth‐generationlanguagesandframeworks(suchaswebapplicationframeworks),whichacceleratetheavailabilityofworkingsoftware.

Relative EstimationAwayofestimatingworkeffortbyidentifyingfeatures/requirementswithstoriesandthenassigningstorypointstoeachstory.Thecumulativestorypointsaretheamountofefforttoestimatetheamountofeffortrequiredtodelivereachstory.Thestorypointsarethencalculatedagainsttheteam'svelocitytocreateanestimateonhowmuchtheteamcandeliverinaparticulariteration.

Release PlanningAtthebeginningofaprojecttheteamwillcreateahigh‐levelreleaseplan.Theteamcannotpossiblyknoweverythingupfrontsoadetailedplanisnotnecessary.Thereleaseplanshouldaddress:thenumberanddurationoftheiterations,howmanypeopleorteamsshouldbeonthisproject,thenumberofreleases,thevaluedeliveredineachrelease,theshipdateforthereleases.



Scrum TeamTheteamthatbuildstheproductthatthecustomerisgoingtoconsume.TheteaminScrumiscross‐functional‐itincludesalltheexpertisenecessarytodeliverthepotentiallyshippableproducteachsprint‐anditisself‐organizing,withaveryhighdegreeofautonomyandaccountability.

Shippable Product ShowcaseAfullytestedunitofcodewhichmeetsacceptancecriteriathatisdeliveredattheendofaniteration.

Service Level AgreementsFormalagreementsthatcontractlevelofserviceandperformance.

Solution Assessment and ValidationThesetoftasksthatareperformedinordertoensurethatsolutionsmeetthebusinessneedandtofacilitatetheirsuccessfulimplementation.Theseactivitiesmaybeperformedtoassessandvalidatebusinessprocesses,organizationalstructures,outsourcingagreements,softwareapplications,andanyothercomponentofthesolution.

SprintAniterationofworkduringwhichanincrementofproductfunctionalityisimplemented.

Sprint GoalAshortdescriptionofwhatthesprintwillattempttoachieve.

Sprint RetrospectiveThemainmechanismfortakingthevisibilitythatScrumprovidesintoareasofpotentialimprovement,andturningitintoresults.

Standup MeetingSeeDailyMeeting.

StorySeeUserStory.

Story MappingAtechniquetofacilitatetheunderstandingofproductfunctionality,theflowofusage,andtoassistwithprioritizingproductdelivery(suchasreleaseplanning).Theoutputofthestorymappingexerciseisaproductcalledastorymap,whichdescribesaworkflowofuserstories.Storymapsmaybreakuserstoriesdownintotasksforeachprocessandmayrepresentthesetasksbasedonpriority.

Task BoardThetaskboardshowsalltheworktheteamisdoingduringaniteration.Itisupdatedcontinuouslythroughouttheiteration‐ifsomeonethinksofanewtasktheywriteanewcardandputsitontheboard.Eitherduringorbeforethedailymeeting,estimatesarechanged(upordown)andcardsaremovedaroundtheboard.

Team VelocityTherateatwhichateamcanconsistentlydeliversoftwarefeaturesperiteration.Typically,itcanbeestimatedbyviewingpreviousiterations,assumingtheteam



composition.anditerationdurationarekeptconstant.Itcanalsobeestablishedonaiteration‐by‐iterationbasis,usingcommitment‐basedplanning.

Theory of ConstraintsDevelopedbyDr.EliGoldratt,theTheoryofConstraints(TOC)holdsthateverysystemhasatleastoneconstraintlimitingit.TOC'sgoalistoincreaseefficienciesbyidentifyingandmitigatingtheseconstraints.

User Acceptance CriteriaTestcasesthatusersemploytojudgewhetherthedeliveredsystemisacceptable.Eachacceptancetestdescribesasetofsysteminputsandexpectedresults.

User StoryAhigh‐level,informal,shortdescriptionofasolutioncapabilitythatprovidesvaluetoastakeholder.Auserstoryistypicallyoneortwosentenceslongand

providestheminimuminformationnecessarytoallowadevelopertoestimatetheworkrequiredtoimplementit.

User Story MappingSeeStoryMapping.

Value driven developmentAprocessusedtoprioritizerequirementsorbacklogitemsbasedonbusinessvalue.

VelocitySeeTeamVelocity.

Whole Team TestingTheconceptembracedbymanyagileapproacheswheretheentireprojectteamisresponsibleforqualityassuranceandtestingthecode.



BappendixIndex

Aacceptance & evaluation criteria definition 49acceptance criteria 4, 6, 10, 13, 14, 15, 16, 22, 42, 65, 67, 69,

70, 74, 100acceptance test driven development 92acceptance tests 34, 44adaptive software development 9affinity map 104agile levels of planning 20Agile Manifesto 2, 3, 4, 53, 108agile team 4Agile Unified Process 9analyze to determine what is valuable 47, 49, 54, 77anthropomorphic data 59anti-pattern 68architecture 4ATDD 92avoid waste 47, 106

Bbacklog 11, 13, 21, 26, 30, 33, 34, 44, 58, 64, 67, 74, 85, 88,

96, 97backlog management 26, 28, 33, 38, 75, 78base lining 49BDD 31, 32, 40, 42, 90behaviour driven development 31, 32, 40, 42, 90benchmarking 49brainstorming 49burn-down 38, 39business capabilities 55business capability analysis 36, 37, 45business capability assessment 56business case 35, 37, 42, 44business conditions 21business context 21business need 4, 5, 7, 8, 14, 35, 36, 42, 55business objective 67business rule analysis 49business rules 5, 74business value 4, 10, 13, 18, 21, 38, 39, 54, 55, 56, 64, 70, 77,

78, 80, 81, 86, 101business value. 33

Ccadence 15, 19, 22, 27, 42, 43capability maps 56ceremonies 10, 15, 28

change management 13checklists 50coach 6, 16coaching 7collaboration 18, 66, 102collaborative games 27, 31, 36, 103communication 7, 8, 18, 19, 66, 68, 69component teams 43continuous improvement 38, 102coverage matrix 50cross-functional team 3, 61crystal 9current state value stream Map 60customer 16customer acceptance 41customer review 11customer value. 10

Ddaily meeting 23daily planning 15daily scrum 10, 11daily team meetings 35, 41data dictionary and glossary 50data flow diagrams 50, 69data model 5, 69, 74data modeling 50data tables 69decision analysis 50decomposition 65delivery framework 47, 89delivery team 54demographic data 59developer 16dialog hierarchy, 75dialog map 75differentiating quadrant 87discovery framework 47, 54document analysis 50DSDM 9dynamic systems development method 9dysfunctional form 83

Eelaboration 16, 27, 40, 54elicitation 38, 39, 69, 74eliciting 13



enterprise analysis 13, 21epics 17, 33, 34, 37, 39, 40, 43, 64, 65, 67, 68, 74, 79estimate 14, 79estimation 7, 50, 95excitement characteristics 83extreme programming 9

Ffacilitating 19facilitation 7, 8, 66, 68, 69, 102feasibility analysis 50feasibility studies 35feature driven development 9feature groups 66feature injection 101feature sets 39, 71feature teams 43features 37, 39, 40, 43, 44, 60, 64, 97, 101feedback 8fishbowl 104force field analysis 50functional decomposition 50functional form 83functional requirements 78future state value stream map 60

Gget real using examples 47, 49, 89grooming 22, 75

Hhealthy teams 53high-level requirements 30

IIDDs 94ideal developer days 94interface analysis 50interviews 50INVEST criteria 73iteration planning 14, 41iteration planning meetings 35iteration planning workshop 96, 100iteration review 22

Jjust-in-time 33, 39, 68just-in-time requirements 5, 7, 13

Kkanban 9, 22, 97, 99kano analysis 37, 38, 81

Llast responsible moment 100Lean 17, 107lessons learned process 50lightweight 39lightweight documentation 32, 40, 108long-lived 58low-fidelity 5, 22, 23

Mmaterial and information flow mapping 60metrics and key performance indicators 50minimal marketable feature 64, 67, 85minimal viable product 65, 67minimally marketable feature 17, 34, 65MMF 17, 34, 65, 66, 67, 79, 96, 97mock-up 31, 34, 69, 74modelling requirements 41models 31, 35, 101MoSCoW 38, 50, 84muda 107MVP 65, 67

Nnavigation flow 75negotiation 7, 8, 19non-functional requirements analysis 50

Oobservation 50operational readiness 21options expiry 100organization modeling 51organizational change 43organizational change management 68organizational readiness 43

Ppair programming 14parity quadrant 87partner quadrant 88performance characteristics 82personas 5, 27, 28, 30, 40, 59planning game 14planning poker 95planning workshop 26, 27, 28, 35, 38, 96principles 3problem or vision statement 51problem tracking 51process improvement 62process modeling 51product backlog 85product box 104product champion 97product demonstration 22product owner 6, 12, 14, 41, 44, 78, 80, 97progressive elaboration 30, 39project team 7, 9prototypes 31, 41, 64, 74prototyping 27, 51, 64, 75, 76pruning 75purpose alignment model 36, 37, 86

QQCD 9quality attribute stories 78queues 17

RRACI matrix 51real options 26, 37, 42, 98



real-time collaboration 9relative estimation 93relative points 94release backlogs 80release plan 97release planning 34, 35, 41, 55, 68, 70release planning workshop 96requirements documentation 51requirements for vendor selection 51requirements prioritization 13requirements workshops 51retrospectives 10, 11, 26, 29, 32, 41, 42, 44, 105risk 5, 9, 14, 19, 21, 27, 38, 39, 55, 56, 70, 78risk analysis 51risk management 40roadmap 8, 20, 21, 44, 56root cause analysis 51

Sscenarios 34, 40, 69, 76, 92scenarios and use cases 51scope modeling 51scrum 9, 15, 17, 18, 20, 22, 99scrum life-cycle 11scrum master 12see the whole 47, 49, 54sequence diagrams 51Service Level Agreements 18signoff 51SLA 18solution assessment and validation 13specification by example 92sprint planning 10sprint reviews 10sprints 21stakeholder Map 51stand up 10, 11stand-up 15state diagrams 51, 74stimulate collaboration and continuous improvement 47,

49, 102stories 33, 34, 40, 43, 60, 65, 66, 68, 94story decomposition 15, 16, 17, 33, 34, 37, 39, 43, 65,

79, 96story elaboration 15, 17, 68, 100story mapping 5, 17, 30, 33, 37, 39, 41, 70story maps 39story techniques 75storyboarding 40, 75strategic criteria 8structured walkthrough 51success criteria 21

survey/questionnaire 51SWOT analysis 51system goals 67systems thinking 54

Ttask definitions 69team capacity 93team velocity 97technical design 3technical writing 4test driven development 14, 90testing 3themes 34, 37, 40, 67Theory of Constraints 17think as a customer 47, 49, 54, 64threshold characteristics 82timeboxing/budgeting 51tracker 16transformation processes 62transition requirements 43

UUI design 3understand what is doable 47, 49, 93use cases 5, 34, 64, 66, 75, 78user acceptance tests 67, 72, 74user stories 11, 14, 15, 16, 20, 33, 34, 39, 52, 64, 65, 67,

70, 75, 78, 85, 97user story 30, 34, 40, 41, 44, 67, 72, 99

Vvalue 9, 43, 44, 53, 54, 56, 61, 64, 72, 80, 85, 97, 107,

108value stream mapping 29, 45, 60variance analysis 52velocity 93, 95vendor assessment 52voting 52

Wwho cares? quadrant 88whole team testing 14WIP 17, 97work in progress limit 17work items 64work queues 17work-in-progress 97

XXP 9, 17, 20



CappendixBibliography

ThefollowingworkswerereferencedbycontributorstotheAgileExtensiontotheBABOK®Guide.Incaseswheremultipleeditionsofaworkwereconsulted,onlythemostrecenteditionislisted.

Inadditiontotheworkslistedhere,manyothersourcesofinformationonbusinessanalysiswereconsultedbycontributorsandreviewersorotherwiseorinfluencedthedevelopmentofTheAgileExtensiontotheBABOK®Guide,includingarticles,whitepapers,websites,blogpostings,onlineforums,seminars,workshops,andconferences.

Withonlyaveryfewexceptions,theideasandconceptsfoundintheAgileExtensiontotheBABOK®Guidewerenotcreatedoriginallyforororiginaltoit.TheAgileExtensiontotheBABOK®Guideisasynthesisofyearsofresearchintohowagiledevelopmentmethodologiesareutilizedandmethodsthatcanbeusedtoidentifypotentialimprovements.Theworkslistedbelow,themselvesbuildonthethoughtsandresearchofmanyothers.

Adlin,TamaraandJohnPruitt.2010.TheEssentialPersonaLifecycle:YourGuidetoBuildingandUsingPersonas.MorganKaufmann.

Adzic,Gojko.2009.BridgingtheCommunicationGap:SpecificationbyExampleandAgileAcceptanceTesting.NeuriLimited.

Adzic,Gojko.2011.SpecificationbyExample:HowSuccessfulTeamsDelivertheRightSoftware.ManningPublications.

Ambler,Scott.IntroductiontoUserStories.AgileModelling.http://www.agilemodeling.com/artifacts/userStory.htm.

Anderson,David.2010.Kanban:SuccessfulEvolutionaryChangeforYourTechnologyBusiness.BlueHolePress.

Arthur,Jay.2006.LeanSixSigmaDemystified:ASelf‐TeachingGuide.McGraw‐HillProfessional.

Berenbach,Brian,DanielJ.Paulish,JuergenKazmeier,andArnoldRudorfer.2009.Software&SystemsRequirementsEngineering:InPractice.McGraw‐HillOsborneMedia.

http://www.agilemodeling.com/artifacts/userStory.htm





Chelimsky,David,DaveAstels,BryanHelmkamp,andDanNorth.2010.TheRSpecBook:BehaviourDrivenDevelopmentwithRspec,Cucumber,andFriends.PragmaticBookshelf.

Cohn,Mike.2004.UserStoriesApplied:ForAgileSoftwareDevelopment.Addison‐WesleyProfessional.

Cohen,Mike.2006.AgileEstimatingandPlanning.PrenticeHall.

Cooper,Alan.2004.TheInmatesareRunningtheAsylum.Sams‐PearsonEducation.

Cottmeyer,MikeandV.LeeHenson.2009.TheAgileBusinessAnalyst.VersionOne,WhitePaper.http://www.agiledad.com/Documents/BAWhitepaperJune.pdf.

Courage,CatherineandKathyBaxter.2005.UnderstandingYourUsers:APracticalGuidetoUserRequirementsMethods,Tools,andTechniques.ElsevierScienceandTechnologyBooks,Inc.

Derby,EstherandDianaLarsen.2006.AgileRetrospectives:MakingGoodTeamsGreat.PragmaticBookshelf.

DSDMConsortium.2003.DSDM:BusinessFocusedDevelopment,SecondEdition.PearsonEducation.

Evers,Marc.September23,2009.WorkingwithUserStoryMapping.Dreamfeed:Marc’sWeblog.http://blog.piecemealgrowth.net/working‐with‐user‐story‐mapping/.

ExtremeProgramming.September28,2009.ExtremeProgramming:AGentleIntroduction.http://www.extremeprogramming.org/index.html.

Goldratt,Eliyahu.2004.TheGoal:AProcessofOngoingImprovement.NorthRiverPress.

Gottesdiener,EllenandMaryGorman.August2010.SlicingRequirementsforAgileSuccess.EbgConsulting.http://ebgconsulting.com/Pubs/Articles/SlicingRequirementsForAgileSuccess_Gottesdiener‐Gorman_August2010.pdf.

Gottesdiener,Ellen.February4,2009.TheAgileBusinessAnalyst:EyesforWaste.Modernanlyst.com.http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/811/The‐Agile‐Business‐Analyst‐Eyes‐for‐Waste.aspx.

Gottesdiener,Ellen.2005.SoftwareRequirementsMemoryJogger.GoalQPCInc.

Gray,Dave,SunniBrown,andJamesMacunafo.2010.Gamestorming:APlaybookforInnovators,Rulebreakers,andChangemakers.O'ReillyMedia.

Highsmith,Jim.2009.AgileProjectManagement:CreatingInnovativeProducts(2ndEdition).Addison‐WesleyProfessional.

Hohmann,Luke.2006.InnovationGames:CreatingBreakthroughProductsThroughCollaborativePlay.Addison‐WesleyProfessional.

http://www.agiledad.com/Documents/BAWhitepaperJune.pdf



http://blog.piecemealgrowth.net/working-with-user-story-mapping/



http://www.extremeprogramming.org/index.html

http://ebgconsulting.com/Pubs/Articles/SlicingRequirementsForAgileSuccess_Gottesdiener-Gorman_August2010.pdf



http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/811/The-Agile-Business-Analyst-Eyes-for-Waste.aspx





IIBA(2009).AGuidetotheBusinessAnalysisBodyofKnowledge®(BABOK®

Guide),Version2.InternationalInstituteofBusinessAnalysis.

Jonasson,Hans.2008.DeterminingProjectRequirements.CRCPress.

Karol,RobinandBeebeNelson.2007.NewProductDevelopmentforDummies.JohnWiley&Sons.

Kent,Stuart.June30,2004.Storyboarding.MSDNBlogsStuartKent’sBlog.http://blogs.msdn.com/b/stuart_kent/archive/2004/06/30/169599.aspx.

Kerth,Norman.2001.ProjectRetrospectives:AHandbookforTeamReviews.DorsetHouse.

Kim,W.ChanandReneeMauborgne.2005.BlueOceanStrategy.HarvardBusinessPress.

King,James.December28,2010.Estimationtoolkit:Someusefultechniques.InfoQ.com.http://www.infoq.com/articles/estimation‐toolkit.

LeanEnterpriseInstitute.PrinciplesofLean.http://www.lean.org/whatslean/principles.cfm.

Leffingwell,Dean.2011.AgileSoftwareRequirements:LeanRequirementsPracticesforTeams,Programs,andtheEnterprise.Addison‐WesleyProfessional.

LencionimPatrick.2006.Silos,PoliticsandTurfWars:ALeadershipFableAboutDestroyingtheBarriersThatTurnColleaguesIntoCompetitors.Jossey‐Bass.

Maassen,OlavandChrisMatts.June2008.RealOptionsunderlieAgilePractices.InfoQ.com.http://www.infoq.com/articles/real‐options‐enhance‐agility.

Matts,Chris.October29,2003.ZeroDocumentation.TheAgileBusinessCoach.http://abc.truemesh.com/archives/000103.html.

Matts,Chris.2009.RealOptionsatAgile2009.R.O.S.E.Comics.http://www.lulu.com/product/paperback/real‐options‐at‐agile‐2009/5949485.

ManifestoforAgileSoftwareDevelopment.http://agilemanifesto.org.

Merrifield,Ric,JackCalhoun,DennisStevens.2008.TheNextRevolutioninProductivity.HarvardBusinessReview.

Middleton,PeterandJamesSutton.2005.LeanSoftwareStrategies:ProvenTechniquesforManagersandDevelopers.ProductivityPress.

North,Dan.March2006.IntroducingBDD.DanNorth.net.http://dannorth.net/introducing‐bdd/.

Patton,Jeff.BuildingBetterProductsbyUsingUserStoryMapping.http://www.slideshare.net/nashjain/user‐story‐mapping.

http://blogs.msdn.com/b/stuart_kent/archive/2004/06/30/169599.aspx



http://www.infoq.com/articles/estimation-toolkit



http://www.lean.org/whatslean/principles.cfm

http://www.lean.org/whatslean/principles.cfm

http://www.infoq.com/articles/real-options-enhance-agility



http://abc.truemesh.com/archives/000103.html

http://abc.truemesh.com/archives/000103.html

http://www.lulu.com/product/paperback/real-options-at-agile-2009/5949485



http://agilemanifesto.org/

http://dannorth.net/introducing-bdd/

http://dannorth.net/introducing-bdd/

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.

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.

http://agileproductdesign.com/blog/the_new_backlog.html



http://www.infoq.com/interviews/patton-story-map

http://cdn.pols.co.uk/papers/cutterbusinessvaluearticle.pdf

http://cdn.pols.co.uk/papers/cutterbusinessvaluearticle.pdf

http://www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf



http://www.infoq.com/news/2009/03/story-map

http://www.infoq.com/news/2009/03/story-map

http://www.extremeprogramming.org/rules/iterationplanning.html




Dappendix Contributors

IIBA®andTheAgileAlliance®wouldliketothankthefollowingcontributorstotheAgileExtensiontotheBABOK®Guide.WithouttheireffortsandcommitmenttheAgileExtensiontotheBABOK®Guidewouldnotbepossible.

Reviewers

IIBA®andTheAgileAlliance®wouldliketorecognizeandthankthemanypeoplewhoprovidedfeedbackthroughthepublicreviewofAgileExtensiontotheBABOK®Guide.YourfeedbackandguidancehelpedshapethisVersion1ofAgileExtensiontotheBABOK®Guide.

• KevinBrennan• SusanBlock• DavidC.Cook• PeterGordon• SteveErlank• EllenGottesdiener• ShaneHastie

• BrianHemker• MarshaHughes• ChrisMatts• AliMazer• DavidMorris• LuizClaudio

Parzianello• CarolScalice

• PaulStapleton,Editor

• DennisStevens• PascalVan

Cauwenberghe

ww.iiba.org

International Institute of Business

Analysis (IIBA)

InternationalInstituteofBusinessAnalysis(IIBA)isanindependentnon‐profitprofessionalassociationdedicatedtopromotingthebusinessanalysisprofessionworldwide.Astheglobalthoughtleaderforbusinessanalysis,IIBA®isdedicatedtothedevelopmentandmaintenanceofstandardsforthepracticeofbusinessanalysisandforthecertificationofpractitioners.OneofthemaingoalsoftheassociationistohelpBAsdeveloptheirskillsandadvancetheircareers.

IIBAhascreatedAGuidetotheBusinessAnalysisBodyofKnowledge®(BABOK®)Guide,thecollectionofknowledgewithintheBAprofession,reflectingthecurrentgenerallyacceptedpractices.

Membership in IIBAMembershipbenefitsinclude:

• TheBABOK®Guide,theinternationallyrecognizedstandardfortheBAprofession

• OnlineLibrarywithaccessto300businessbooks,areferencelibraryatyourfingertips

• BACompetencyModelandtheBACompetencyAssessmenttoevaluateyourBAskills

• Webinarsdeliveredbyindustryleaders,providingcurrent,relevantandactionableinformation

• DiscountedexamfeesfortheCertificationofCompetencyinBusinessAnalysis™

(CCBA®)andCertifiedBusinessAnalysisProfessional™(CBAP®)designations

• EligibilitytojoinalocalChapter• JobsearchcapabilitiesusingtheCareer

Centre

IIBA Certification

Certification of Competency in Business Analysis™ (CCBA®)

TheCCBA®designationisaprofessionalcertificationforBApractitionerswhowanttoberecognizedfortheirexpertiseandskillsbyearningformalrecognition.

Certified Business Analysis Professional™ (CBAP®)

TheCBAP®designationisaprofessionalcertificationforindividualswithextensivebusinessanalysisexperience,theelite,seniormembersoftheBAcommunity.

FormoreinformationvisitIIBA.org/Certification.

IIBA ChaptersOver100IIBAChaptersworldwideprovidenetworkingandprofessionaldevelopmentopportunitiestobusinessanalystsatthelocallevelthroughactivities,meetings,andeducationalprograms.VisitIIBA.org/Chapters.

ForcompleteinformationvisitIIBA.org.

ww.iiba.org

The Agile Alliance

TheAgileAllianceisanon‐profitorganizationwithglobalmembership,committedtoadvancingAgiledevelopmentprinciplesandpractices.AgileAlliancesupportsthosewhoexploreandapplyAgileprinciplesandpracticesinordertomakethesoftwareindustrymoreproductive,humaneandsustainable.Weshareourpassiontodeliversoftwarebettereveryday.

Agilemethodshaveproventheireffectivenessandaretransformingthesoftwareindustry.Asagilemethodsevolveandextend,AgileAlliancefostersacommunitywhereorganizationsandindividualsfindwaystotransitiontoandadvanceAgilepractices,regardlessofmethodology.

TheAgileAlliancewebsiteoffersaninformationhubwherememberscanaccessawidevarietyofresources—anarticlelibrary,videos,presentations,localusergrouplistingsandlinkstoadditionalagileresources.

AgileAllianceorganizesthelargest,mostdiverseandcomprehensiveagileconferenceseachyear.Conferenceparticipantslearnfromhundredsofsessionsspanningtheentireagileorganizationandlife‐cycle,makebusinessconnections,andconversewithagilethoughtleaders,practitioners,andauthors.

Inadditiontothesemajorconferences,AgileAllianceprovidesfinancialandorganizationalsupporttoscoresoflocal,regionalandspecialinterestconferencesandusergroupsworldwide.

TheAgileAllianceoperatesontheprinciplesoftheAgileManifesto.http://www.agilemanifesto.org

TheAgileAlliancewebsiteis:www.agilealliance.org.

Agile Extension to the BABOK Guide - Agile Alliance

Documents

Transcript of Agile Extension to the BABOK Guide - Agile Alliance