Top Banner
International Institute of Business Analysis TM IIBA ® The Agile Extension to the BABOK ® Guide is a collaborative effort by the International Institute of Business Analysis and the Agile Alliance. November 2011 Draft for Public Review The Agile Extension to the BABOK ® Guide
128
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: The Agile Extension

IIBA®

TheAgileExtensionInternationalInstitu

November2011

International Institute of Business AnalysisTM

The Agile Extension to the BABOK®Guide

totheBABOK®GuideisacollaborativeeffortbytheteofBusinessAnalysisandtheAgileAlliance.

DraftforPublicReview

Page 2: The Agile Extension
Page 3: The Agile Extension

Agile Extension to the BABOK® Guide

November 2011 Draft for Public Review

www.iiba.org

Page 4: The Agile Extension

InternationalInstituteofBusinessAnalysis,Toronto,Ontario,Canada

© InternationalInstituteofBusinessAnalysis.Allrightsreserved.

Thisdocumentisprovidedtothebusinessanalysiscommunityforeducationalpurposes.IIBA®warrantsthatitissuitableforanyotherpurposeandmakesnoexpressedorimpliedwarrantyofanykindandassumesnoresponsibilityforerrorsoromissions.Noliabilityisassumedforincidentalorconsequentialdamagesinconnectionwithorarisingoutoftheuseoftheinformationcontainedherein.

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

TheAgileAlliance®andtheAgileAlliancelogoarearegisteredtrademarksownedbyTheAgileAlliance.

NochallengetothestatusorownershipoftheseoranyothertrademarkedtermscontainedhereinisintendedbytheInternationalInstituteBusinessAnalysis.

ThisdraftoftheAgileExtensiontotheBABOK®Guideisprovidedtothecommunityforreviewandfeedbackandmaynotbeusedforanyotherpurpose.Inordertoprovidefeedback,pleaseenteryourcommentsonourfeedbackwebform.

Page 5: The Agile Extension

Table of Contents

Chapter 1: Introduction to the Agile Extension 1

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

Chapter 2: Business Analysis in Agile Life-cycles 7

Scrum .............................................................................................................. 7Backlogs ........................................................................................................................... 8Sprint Planning and Execution ...................................................................................... 8Roles and Responsibilities .............................................................................................. 9Business Analysis in Scrum ............................................................................................ 9Techniques .................................................................................................................... 11

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

Kanban.......................................................................................................... 14Queues .......................................................................................................................... 15The Kanban Board ....................................................................................................... 15Roles & Responsibilities ............................................................................................... 16Business Analysis in Kanban....................................................................................... 16

Comparison of Agile Life-cycles ................................................................. 18Selecting an Agile Methodology or Framework......................................................... 19

Agile Levels of Planning .............................................................................. 20Agile Levels of Planning ............................................................................................... 20

Chapter 3: Knowledge Areas 25

Mapping Techniques to Knowledge Areas ............................................... 25

November2011DraftforPublicReview i

Page 6: The Agile Extension

Business Analysis Planning and Monitoring ............................................................. 25Elicitation ...................................................................................................................... 28Requirements Management and Communication................................................... 30Enterprise Analysis....................................................................................................... 32Requirements Analysis ................................................................................................ 34Solution Assessment and Validation ......................................................................... 36Business Analysis Techniques Mapped to Agile Business Analysis Guidelines ...... 39

Chapter 4: Techniques 43

A Context for Agile Business Analysis ....................................................... 43 Guidelines for Agile Business Analysis ..................................................... 44 A Note on Agile Extension Techniques ..................................................... 44 See The Whole ............................................................................................. 45

Business Capability Analysis....................................................................................... 46Personas ....................................................................................................................... 49Value Stream Mapping................................................................................................ 51

Think as a Customer ................................................................................... 55Story Decomposition ................................................................................................... 56Story Elaboration ......................................................................................................... 59Story Mapping.............................................................................................................. 61User Story ..................................................................................................................... 64Storyboarding............................................................................................................... 67

Analyze to Determine What is Valuable.................................................... 70Backlog Management.................................................................................................. 70Business Value Definition............................................................................................ 73Kano Analysis ............................................................................................................... 74MoSCoW Prioritization ................................................................................................ 77Purpose Alignment Model........................................................................................... 79

Get Real Using Examples ............................................................................ 81Behaviour Driven Development ................................................................................. 82

Understand What is Doable ....................................................................... 84Estimation..................................................................................................................... 85Planning Workshop ..................................................................................................... 87Real Options ................................................................................................................. 89

Stimulate Collaboration & Continuous Improvement............................ 93Collaborative Games ................................................................................................... 94Retrospectives............................................................................................................... 96

Avoid Waste.................................................................................................. 98Lightweight Documentation........................................................................................ 99

ii The Agile Extension to the BABOK® Guide

Page 7: The Agile Extension

appendix A Glossary 103

appendix B Bibliography 111

appendix C Contributors 115

November2011DraftforPublicReview iii

Page 8: The Agile Extension

iv The Agile Extension to the BABOK® Guide

Page 9: The Agile Extension

chapter 1

Introduction to the Agile Extension

®

1.1 What is the Agile Extension to the BABOK Guide?

TheAgileExtensiontotheBABOK®Guidedescribesbusinessanalysisareasofknowledge,theirassociatedactivitiesandtasks,andtheskillsnecessarytobeeffectiveintheirexecutionwithintheframeworkofagilesoftwaredevelopment.

ThepurposeoftheAgileExtensionistoactasabusinessanalysisprimerforagilesoftwaredevelopmentmethodologiesandprovidebusinessanalysispractitionerswith:

• anintroductiontoagilepracticesforbusinessanalysis,• anoverviewofbusinessanalysistechniquesforagile

practitioners,• asetofdefinitionsoftypicalworkingpracticesusedbybusiness

analystsworkingonagileprojects,and• anoverviewofthenewandchangedroles,skills,and

competenciesforbusinessanalysis.

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

AstheAgileExtensionhighlights,anymemberofanagileteammayengageintheprocessofbusinessanalysis.Tothatend,eachpersononanagileteamwillbenefitfromhavingasetofpracticesandtoolsinwhichtheycanselectfromwhileworkinginanyoneofthedifferentflavorsofagile.

IntheAgileExtension,wehavecalledparticularattentiontothemind‐setabusinessanalysispractitionermusthaveinordertoeffectivelycontributetodeliveryofongoingvaluetostakeholders.Wehavealso

November2011DraftforPublicReview 1

Page 10: The Agile Extension

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

describedanumberoftechniquesnotfoundintheexistingBABOK®

Guide,andexpandedonothersthatneededtobedescribedingreaterdetail.Manyoftheapproachesdescribedhere,andthemind‐setwedescribe,willprovevaluabletobusinessanalysisinanymethodologyandenvironment.Businessanalystsshouldalwaysworktoensurethatrequirementsarealignedwithorganizationalgoalsandobjectivesandthatallstakeholdershaveasharedunderstandingofthosegoals,objectives,andrequirements.Theymustalsoworktomanagerisksandvalidatethattherequirements,ifdelivered,willcreaterealvalueforstakeholders.Agilemethodologiescanhelpusfindnewwaystodothesethingsthatsupportcontinuousdeliveryofworkingsoftware,buttheresponsibilitytodothesethingsisinherenttotheprofessionofbusinessanalysis.

1.2  What does Agile Mean for Business Analysis?

Muchlikeothermethodologies,businessanalysisiscentraltothesuccessofagileprojects.Businessanalysisisnecessarytoenableadiversegroupofcustomerstospeakwithasinglevoice.Thisworkmaybedonebyoneofmoremembersofanagileteam.

Intheagileworld,softwarerequirementsaredevelopedthroughcontinualexplorationofthebusinessneed.Requirementsaregatheredandrefinedthroughaniterativeprocessofplanning,definingacceptancecriteria,prioritizing,developing,andreviewingtheresults.Throughouttheiterativeplanningandanalysisofrequirements,businessanalysispractitionersmustconstantlyensurethatthefeaturesrequestedbytheusersalignwiththeproduct’sbusinessgoals,especiallyasthebusinessgoalsevolveandchangeovertime.

Agilebusinessanalysisisprimarilyaboutincreasingthedeliveringofbusinessvaluetothesponsorsandcustomersoftheproject/productbeingdeveloped.AgilebusinessanalysisalignswiththevaluesandprinciplesoftheAgileManifesto(www.agilemanifesto.org):

• Wevalueindividualsandinteractionsoverprocessesandtools.• Ourhighestpriorityistosatisfyourcustomerthroughearly

andcontinuousdeliveryofvaluablesoftware.• Workingsoftwareistheprimarymeasureofprogress.

Agilebusinessanalysisisaboutensuringtherightinformationisavailabletothedevelopmentteamintherightlevelofdetailattherighttimesotheycanbuildtherightproduct.

2 The Agile Extension to the BABOK® Guide

Page 11: The Agile Extension

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

Thetechniquesofbusinessanalysisdonotchangedramaticallyintheagileenvironment.However,thetimingandhowtheyareuseddochange.Artifactssuchaspersonas,datamodels,storymaps,andbusinessrulescontinuetobeemployed,butarekeptaslight‐weightaspossible.Low‐fidelityartifacts,suchasdiagrams,maps,andlists,providemorevaluetoanagileprojectthanlong,textualrequirementdescriptionsorspecifications.Low‐fidelityartifactsaredevelopedforthesolepurposeofbuildingthesoftwareforaspecificiterationandonlyneedtobeintelligibletotheteamduringthecourseoftheiteration.Long‐livedartifacts,ontheotherhand,areintendedtobeutilizedbeyondthescopeofdevelopment.Long‐livedartifactsmayincludethebusinesscase,charter,anddocumentationthatisusedtocommunicatewhatthesoftwaredoesandwhyitdoesit.

Agileofferstheopportunityforbusinessanalysistobenefitfromthefrequentfeedbackprovidedbythebusiness.Byreviewingtheresultsofsuccessiveiterationswiththebusinessstakeholders,analystshavetheopportunityto

• refinetheproduct’srequirementstoensuretheymaintaincohesionwiththebusinessneedsfortheproduct,and

• identifyandmitigateriskearlyintheproject.

Forthemostpart,inagileprojects,highriskitemsareaddressedinearlyiterations.Thisallowstheteamtomitigateissuesandthepossiblereworkrequiredifriskitemsarenotaddresseduntillaterintheproject.Facilitatingriskdiscoveryandassistingtheteaminretainingfocusedoneffectiveriskmitigationiscentraltotheanalyst’sroleonanagileteam.

Iterativedevelopmentprocessesprovideopportunitiesforincreasedefficienciesintheworkofbusinessanalysis.Inwaterfallprojects,requirementsaredevelopedintheirentiretypriortothedevelopmentphase.Asriskelementsareuncoveredandbusinessneedsevolve,certainrequirementsmaychangeorbeeliminatedoutright;makingtheworkeffortputintothoserequirementswasted.Byprovidingjust‐in‐timerequirements,thereislessreworkofrequirementsbecauseonlytherequirementsrequiredforthecurrentreleasearedefinedindetailanddeveloped.

November2011DraftforPublicReview 3

Page 12: The Agile Extension

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

1.3 What does Agile Mean for Business Analysts?

Theearlystagesofagile’sevolutionfrequentlyreliedonasingleindividualbeingabletomakeallthedecisionsregardingthedevelopmentofthesoftware.Asagileprojectsgrowinsizeandbreadth,andbecomeadoptedbylargerandmorediverseorganizations,theroleofbusinessanalysthasbecomeavitalcontributor.Theanalystplaysadefiningroleincreatingasinglevisionfortheproductoutofadiversesetofneedsandwishesfrommultiplestakeholders.

TheAgileManifestousestheterm“developers”todescribetheteamwhoworkonbuildingtheproduct.Thisisacross‐functionalteamofskilledindividualswhobringavarietyofexpertisetobearontheprocessofbuildingasoftwareproduct.Theskillsthatdevelopersrequiretodothisincludebusinessanalysis,technicaldesign,programminginvariouslanguagesandtools,testing,UIdesign,technicalwriting,architectureandwhateverelseisneededtoproduceworkingsoftware.Workingsoftwareisaproductwhichisintheproductionenvironmentdeliveringvalueforourcustomers.

ThereareavarietyofwaysabusinessanalystcanbeengagedonanAgileproject:

• Insomeprojectsadedicatedbusinessanalystroleisunnecessary.Thisisnottosaythatbusinessanalysisisnotconductedduringthecourseoftheproject,onlythatitmaybedonebyanymember,ormembers,oftheoveralldevelopmentteam.

• Inmorecomplexenvironmentstheanalystmightbethefacilitator,bringingdivergentbusinessstakeholderstogetherandhelpingthemspeakwithasinglevoicesotheprojectteamarenotconfusedbycontradictoryandconflictingperspectives.

• Theanalystmightactastheproductowner/customerrepresentativewheretheyareempoweredbythebusinesstomakedecisionsonproductfeaturesandpriority.

• Theanalystcouldactasasurrogateproductowner,insituationswherethebusinessproductownernotavailable.

• Theanalystmightactasthesecondincommandtoabusinessproductownerwithlimitedavailability.

• Ananalystcouldtaketheroleofbusinesscoachinanenvironmentwherethebusinessproductowneriscompetentandcommitted,buthaslimitedITprojectexperienceandtherestofthedevelopmentteamarelackingindomainknowledge.

4 The Agile Extension to the BABOK® Guide

Page 13: The Agile Extension

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

Irrespectiveofjobtitles,businessanalysisisaboutensuringtheprojectisabletodeliverthemaximumvalueforcustomersandadaptingtotheevolvingbusinessneeds.

Thetechniquesutilizedinagilemethodologiesdonotrepresentamajorshiftforbusinessanalysts.TheycontinuetoutilizemanyofthetoolsandtechniquesdefinedinAGuidetotheBusinessAnalysisBodyofKnowledge®(BABOK®Guide).Whathaschangedisthetimingandtheusageofthesetechniques.Therigorsanddemandsofagileprojectsalsorequirebusinessanalyststoutilizeanddevelopskillsthattheymaynothavepreviouslyexercisedatahighlevel.Inanagileenvironment,thesuccessofthebusinessanalystreliesincreasinglyonsuchinterpersonalskillsascommunication,facilitation,coachingandnegotiation.Theseskillsarecertainlycentraltothesuccessofananalystinanyenvironment;however,duetotheinter‐connectednessofagileteams,iftheseskillsarenotbeingeffectivelyutilized,thenumberofrequeststhatcanbeadequatelyunderstandandprioritizeddecreases,resultinginfeweritemsmakingitintothesolutionimplementationforagivenrelease.

Analystsarerequiredtoapproachrequirementsfroma360degreeperspective.Theyarerequiredtoworkwiththebusinesssponsoronastrategiclevel,anddefinehowtheproposedproductorfeaturealignswiththeorganizationsportfolioandstrategy.Theymustthenworkwiththebusinessandprojectteamtobreakthisvisiondownintorequirementsthatsupporteffectiveandaccurateestimation.Inanagileprojectthisisdoneforeachiterativerelease,asopposedtothesinglerequirementsphasethatexistsinplan‐drivenmethodologies.Theanalystdeliversjust‐in‐time,detailedrequirementstothedevelopmentteamsotheycanbuildonlywhatisrequiredforaspecificiteration.

Businessanalystsplayakeyroleinfacilitatingasharedunderstandingofthebusinessneedfortheprojectwithallstakeholders.Itistheroleofthebusinessanalysttoensurethereisashared,agreeduponvisionfortheproductacrosstheentiredeliveryteam.Intheagileenvironment,understandingandsynthesizingperspectivesalongsidetheabilitytoholdsuccessfulconversationsreplacetheneedforformal,detailed,longtermartifactssuchasrequirementdocuments.

Oneofthekeyelementsforabusinessanalystworkinginanagileenvironmentistheabilitytousefeedbacktodrivechange.Itisincumbentontheanalysttoconstantlyreviewrequirementswiththe

November2011DraftforPublicReview 5

Page 14: The Agile Extension

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

businessstakeholdersandensurethatanyshiftsinbusinessneedsareaccuratelyreflectedinfutureiterationsoftheproduct.

1.4 What makes a Business Analyst Successful on an Agile Team?

Theverynatureofagilemethodologiesrequiresallteammemberstobeoperatingataveryhighlevelofcompetency,skill,andeffectiveness.Thisisespeciallytrueforbusinessanalysts.Tobeproductiveonanagileteam,businessanalystshavetobeontopoftheirgame.Onsuccessfulagileteams,thebusinessanalystisanintegralcomponentofthedeliveryteam.Theyareactiveparticipants,ifnottheactualfacilitatorsofplanning,analyzing,testing,anddemonstratingactivities.

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

6 The Agile Extension to the BABOK® Guide

Page 15: The Agile Extension

chapter 2

Business Analysis in Agile Life-cycles

Agileisatermusedtodescribeanumberofiterativedevelopmentmethodologiesthathavedevelopedovertime.Commontraitsamongstagilemethodologiesincludefrequentproductreleases,highlevelsofreal‐timecollaborationwithintheprojectteamandwithcustomers,reducedtimeintensivedocumentation,andregular,recurringassessmentsofvalueandrisktoallowforchange.Itisimportanttonotethatthoughallagilemethodologiesareiterative,notalliterativemethodologiesareagile.Agilemethodologiesareasubsetofiterativesoftwaredevelopment.AfewexamplesofagilemethodologiesincludeScrum,ExtremeProgramming(XP),Kanban,Crystal,DynamicSystemsDevelopmentMethod(DSDM),FeatureDrivenDevelopment,andAdaptiveSoftwareDevelopment,tonameafew.Eachmethodologyhasitsownuniquesetofcharacteristicsthatallowteamstoselectacertainmethodologythatbestsuitstheprojectathand.Itiscommonforprojectteamstoblendcharacteristicsfrommorethanoneagilemethodologybasedonuniqueteamcomposition,skills,experience,operatingenvironment,andotherfactors.

Inordertoeffectivelymanage,elicit,analyze,document,communicate,andvalidaterequirements,businessanalystsmustbeabletounderstandthecharacteristicsofthespecificagilemethodologytheyareworkingwith.WhilewedescribeafewofthepredominantagilemethodologiesinthisAgileExtension,beforestartinganagileprojectitisimportanttospendsometimeresearchingthevariousmethodologiesandwhatisdifferentabouteach.

2.1 Scrum

Scrumisoneofthemostpredominantagileprocessframeworksinusetoday.IntheScrumframework,workonaprojectisperformedinaseriesofiterations,calledsprints,whichgenerallylastfrom2to4weeks.Attheendofeachsprint,theteammustproduceworkingsoftwareofahighenoughqualitythatitcouldpotentiallybeshippedorotherwisedeliveredtoacustomer.WithintheScrumframework

November2011DraftforPublicReview 7

Page 16: The Agile Extension

Scrum Business Analysis in Agile Life-cycles

therearefourformalmeetings,knownasceremonies:sprintplanning,thedailyscrum,sprintreviews,andsprintretrospectives.

2.1.1 Backlogs

IntheScrumframeworkaproductbackloglistsalloftherequirementsforasolution,includingbothcustomerandtechnicalrequirements.Thebacklogservesasawishlistfortheproduct.Astheteamcollaborateswiththecustomerfortheproject,thebacklogispopulatedtokeeptrackofeachrequest.Thisbacklogisconstantlyprioritized,suchthatatanygiventimeitcanbeusedtoidentifyhighpriorityrequestsforthesolutionbeingdeveloped.Atthebeginningofeachsprint,inthesprintplanningceremony,theteamreviewstheprioritizedproductbacklogandidentifiesthehighest‐priorityitemsthatcanbecompletedwithinthesprintperiod.Theselecteditemsarethenplacedonasprintbacklog.Thesprintbacklogoutlinesthesprint'sgoalsandthesetoftasksrequiredtoachievethosegoals.

2.1.2 Sprint Planning and Execution

Duringthesprint,theteamrefinestheirunderstandingoftheselecteditemsandworkstoensurethattheyarecompletedwithindefinedtimelimitofthesprint.Assprintsareexecuted,theteammeetsonceperday(referredtoasthedailyscrummeeting)tobrieflydiscusswhattheyareworkingonandidentifyanyblockersthatmaypreventthemfromcompletingtheirwork.Attheendofthesprint,theteamdeliversworkingandtestedsoftwarethatfullyimplementstheselectedbacklogitems.Thesprintisthenclosedoffwithacustomer,orsprint,reviewandaretrospective.Duringthecustomerreview,ademonstrationofthesoftwareisprovidedandthecustomerprovidesfeedback.Duringtheretrospective,theteammeetsandcollaboratestofindwaystoimproveboththeproductandtheirprocessesusedtodelivertheproduct.Boththecustomerreviewandtheretrospectivemayidentifyadditionitemsthatfeedintotheproductbacklog.Theseitemsarethenusedtoreprioritizetheproductbacklogforthenextsprintplanningsession.

8 The Agile Extension to the BABOK® Guide

Page 17: The Agile Extension

Business Analysis in Agile Life-cycles Scrum

Thefollowingillustrationdemonstratesatypicalscrumlife‐cycle.

FIGURE 2.1 ScrumLife‐cycle

2.1.3 Roles and Responsibilities

InScrum,therearethreeroles:

• ProductOwner.Theproductownerisresponsibleformaintainingthelistofworktobeperformedandperformingmostbusinessanalysisactivities.Itisimportanttonotethattheproductownerisnotnecessarilyabusinessanalyst,rathertheindividualontheteammostresponsibleforwhathasbeenconsideredtraditionalbusinessanalysisactivities.

• ScrumMaster.ThescrummasterisresponsibleformanagingtheScrumprocessandmanaginganyblockersthatmaypreventtheteamfromaccomplishingwork.

• TheTeam.Theteamisresponsiblefordevelopinganddeliveringtheproduct.

2.1.4 Business Analysis in Scrum

Scrumdoesnotaddressbusinessanalysisactivitiesindetailandmanyoftheseactivitiesoccurasimplicitstepsinthescrumframework.Thefollowingillustrationshowsthetypicalscrumlifecyclewithbusinessanalysistechniquessuperimposed.

November2011DraftforPublicReview 9

Page 18: The Agile Extension

Scrum Business Analysis in Agile Life-cycles

FIGURE 2.2 BusinessAnalysisinScrum

Thebuildingandmaintenanceoftheproductbacklogisasignificantbusinessanalysisactivitythatfallsexplicitlyoutsidethescopeofthescrumframework(althoughothermethodologieshaveaddressedthis).Thebacklogisbuiltthroughacombinationofenterpriseanalysiswork(identifyinggapsandnewcapabilitiesrequiredtoaccomplishorganizationalgoals,anddefiningtheirvaluetotheorganization)andsolutionassessmentandvalidation(identifyingwaysinwhichtheexistingsolutioncanbeenhancedtobetterdeliverbusinessvalue).

Withinasprint,businessanalysisactivitiesfocusondefiningtherequirementsforthebacklogitemsbeingworkedonandtheacceptancecriteriaforthoseitems.Thismethodisfrequentlyreferredtoasjust‐in‐timerequirementsgathering;developingonlywhatisrequiredforthecurrentsprintandonlydonetothelevelofdetailrequiredtoenabletheteamtobuildtheproductandacceptancecriteria.Intraditionalmethods,requirementsdocumentationisfrequentlyusedasthedocumentationforthesolution.InScrum,asinmostotheragilemethods,documentationiscreatedaftertheproductisbuilttocapturetheteam’sknowledge,notdefineanexpectedordesiredoutcome.Mostfrequentlythebacklogdocumentationcreatedduringeachsprintservesassufficientdocumentationfortheproject.

10 The Agile Extension to the BABOK® Guide

Page 19: The Agile Extension

Business Analysis in Agile Life-cycles Extreme Programming (XP)

2.1.5 Techniques

BacklogManagement:Backlogmanagementistheprimarymethodofhandlingbothrequirementsprioritizationandchangemanagementinmostagilemethods.Analternativetobacklogmanagementisakanbanboard(see“TheKanbanBoard”onpage15).

Retrospectives:Retrospectivesareacommonpracticeusedbyagileteamsseekingtoimprovetheirwaysofworking.Businessanalystsshouldlookforfeedbackontherequirementstheyprovidetotheteamandhowandwhenthoserequirementsareprovidedinordertofindwaystoimprovetheirprocesses.

2.2 Extreme Programming (XP)

ExtremePrograming(XP)beganbeingusedbydevelopmentteamsinthemid‐1990s.Likeotheragilemethodologies,XPisiterativeinnatureandprovidessmallreleasesattheendofeachiteration.XP’sprimaryfocusisonthetechnicalaspectsofagilesoftwaredevelopmentandisbasedon12practicesinfourcategories:

TABLE 2.1 Extreme Programming Categories 

2.2.1 User Stories

XPusestheconceptofuserstoriesasacentralmechanismtodefinerequirements.UserstoriesaresimilartotheconceptoftheproductbacklogfoundinScrum.Theyarecreatedbyusersofthesystemtodefinefeaturesandfunctionalitytobeincludedinthesolution.Userstoriesdonotcontaingreatdetailandareusedto

• prioritizeworkintoiterations,• identifyriskassociatedwitharequest,• estimatetheeffortrequiredtodelivertherequest,and

Fine Scale Feedback Continuous ProcessShared Understanding Programmer Welfare

• Pair Programming• Planning Game• Test Driven

Development• Whole Team

Testing

• Continuous Integration

• Re-factoring• Small Releases• Coding Standards

• Collective Code Ownership

• Simple Design• System Metaphor

• Sustainable Pace

November2011DraftforPublicReview 11

Page 20: The Agile Extension

Extreme Programming (XP) Business Analysis in Agile Life-cycles

• establishaconversationbetweentheteamandtheproductowneraroundthesubjectoftherealbusinessneed,inordertocreateacommonunderstandingofwhathastobedone

2.2.2 Release Planning and Execution

XPreliesonthreelevelsofplanning:

• releaseplanning,• iterationplanning,and• anddailyplanning.

Areleaseplanidentifiesthenextsetofusablefeaturethatcouldmakeuparelease.Thereareoftenseveraliterationsworthofworkbecausetheproductisrelease‐ready.Iterationplanningservestoplaneachincrementaliterationthatwillultimatelyresultinareleasableproduct.Finally,indailyplanningtheteamplansouteachday'sactivitiestoensuretheteamisonscheduleandidentifyrisksthatmayhavearisen.

InXP,releaseplansareusedtotrackanddescribewhatfeaturesorfunctionalityistobedeliveredineachproductrelease.Thereleaseplanissimilartotheconceptofthesprintbackloginthescrumframework.Iterationplanningmeetingsarethenusedasavehicleforteamcollaborationinplanningthecomingiteration.Astheteamworkstoscheduletherelease,theuserstoriesareorderedbasedonthemostimportantfeaturestothecustomer,ensuringthatthemostimportantfeaturesarealwaysdeliveredfirst.Onajust‐in‐timebasis,storiesaredecomposedintotheirgranularfunctionalrequirementsinatechniqueknownasstorydecomposition.Then,throughstoryelaboration,theteamidentifiesthedetaileddesignandacceptancecriteriaforthestory.

Whileaniterationisunderway,XPisalsosimilartoScruminthatitutilizesdailymeetingsasthekeycommunicationvehiclefortheteam,calledthedailystand‐up.Thisdailystand‐upmeetingisusedtofacilitatedailyplanningactivitiesandreviewprogresssincethepriorday'sstand‐up.Inpractice,teamsemployingtheXPmethodologyfrequentlycombinesuchelementsascadence,roles,andceremonies(suchassprintplanningandsprintreviews)fromthescrumframework.

12 The Agile Extension to the BABOK® Guide

Page 21: The Agile Extension

Business Analysis in Agile Life-cycles Extreme Programming (XP)

ThefollowingdiagramprovidesanoverviewoftheXPmodel.

FIGURE 2.3 ExtremeProgrammingModel

2.2.3 Roles and Responsibilities

InExtremeProgramingtherearethreekeyroles.

• Customer.Thecustomercreatesandprioritizestheuserstoriesandpreformsriskanalysis.

• Developer.Thedevelopercommunicatesdirectlywiththecustomerandbuildsonlywhatisnecessarytodeliveroneachiteration.

• Tracker.Thetrackerkeepstrackofthescheduleandthemetrics.

2.2.4 Business Analysis in XP

WhileXPdoesfocusonvaluedrivendevelopment,itdoesnotexplicitlyaddressbusinessanalysisactivities.XPreliesonthefundamentalassumptionthatthecustomerroleisfilledbyasmallnumberofpeoplewhoknowwhatthemostvaluablefeatureswillbe.WhenXPisappliedatalargerscale,orwithcustomerswhodonothaveaclearvisionoftheincrementalvalueoffeatures,abusinessanalystaddssignificantvalueinfacilitatingandnegotiatingwithstakeholderstoreachasharedunderstandingofwhatthemostvaluabledeliverableswillbe.Abusinessanalystcanalsocontributebyfacilitatingstorymapping,atechniqueinwhichagraphicalrepresentationofstoriesalongatimecontinuumiscreated.Thestorymapisusedtoidentifyrisksanddependenciesamongstandbetween

November2011DraftforPublicReview 13

Page 22: The Agile Extension

Kanban Business Analysis in Agile Life-cycles

theuserstoriestooptimizethevaluedeliveredbyeachincrementalstoryimplementation.

IntraditionalXP,theuserstoriesarecreatedandmanageddirectlybytheuser.Thiscanleadtounfilteredrequirementsthatareatriskforconstrainingasolutionwithoutconsiderationforrootcauseorapplicabilitytoothercustomergroups.Businessanalysisskillscanbeusedtoensureunderlyingproblemsarebeingaddressedinawaythatworksformost,ifnotall,ofthestakeholdersontheproject,aswellasensurethoroughacceptancecriteriahavebeencollectedforeachuserstory.Onprojectswherethereisadedicatedbusinessanalyst,thispersonmayactasabrokerorfilterfortheuserstoriesthataregeneratedbythecustomer,oftenperformingthestorydecompositionandelaborationactivities.

2.2.5 Techniques

UserStories:Userstoriesidentifywhichrolesthestoryprovidesvalueandthereforeidentifythestakeholderswhocanelaborateonthatvalue.

StoryMapping:Storymapsshowrelationshipsbetweenuserstoriesandlargeractivitiesthattheusermustbeabletoaccomplish.

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

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

2.3 KanbanScrumandXPareframeworksthatdefinesetsofroles,ceremonies,andpracticesforproducedelivery.Inthecontextofsoftwaredevelopment,Kanbanisamethodologyformanagingtheflowofworktoallowforevolutionarychange.WithrootsintheTheoryofConstraintsandleanproductdevelopment,Kanbanhasfourkeyprinciples:

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

14 The Agile Extension to the BABOK® Guide

Page 23: The Agile Extension

Business Analysis in Agile Life-cycles Kanban

Unliketheotheragileframeworksthatwehavediscussed,Kanbandevelopmentdoesnotrequirefixediterations.Workmovesthroughthedevelopmentprocessasacontinuousflowofactivity.AkeyfeatureofKanbanistolimittheamountofworkunderwayatanyonetime.Inthismethodologytheteamonlyworksonafixednumberofitemsatanyonetimeandworkmayonlybeginonanewitemwhenitisrequiredtomaintainflowdownstreamandafterthepreviousitemhasbeencompleted.

2.3.1 QueuesKanbanreliesontheuseofworkqueuestomanagetheflowofactivitiesthatmusttakeplacetodeliveraworkingproduct.Theformatandcontentforworkqueuesislessprescriptiveinthismethodologythanotherswehavelookedat,onlynotingthatitshoulddescribetheworktobecompletedorderedinrelativeprioritytodelivertheproduct.Forthisreason,theKanbanmethodologyisoftencombinedwithmethodssuchasScrum,wherethebacklogisusedastheimplementationforthequeue.Whenanewfeaturerequestisreceived,itisassessedforrelativepriorityandurgencyandthenplacedintothequeueinitsrelativeposition,maintainingtheorderbypriority.

AnalogoustotheScrumtechniqueofgroomingtheproductbacklog,Kanbandescribesatechniquecalledgroomingthequeue.Groomingthequeueisaperiodicexercisewheretheprojectteamscopesthefeatureswaitinginthequeuetoseeiftheyaretoolargeoroutofscopefortheupcomingrelease.Foritemsthataretoolargetobecompletedbeforeaplannedreleasedate,theprojectteamwillbreaktheitemdown(decomposesit)intosmallerchunksofwork,decidingwhichwillbeincludedinthereleaseandwhichwillnot.Theteamthenreassessesthepriorityoftheitemsinthequeueandreordersthemasneededtomaintainacontinuous,prioritizedflowofwork.

2.3.2 The Kanban BoardThetermkanbanactuallytranslatestosignboardorbillboard,anditreferstothekanbanboardusedbyteamstomanagetheirwork.Inkeepingwiththeprincipletovisualizethework,thekanbanboardisavisualdepictionoftheflowofworkthroughthesoftwaredevelopmentprocess.Thefollowingillustrationshowsanexampleofatypicalkanbanboard.

November2011DraftforPublicReview 15

Page 24: The Agile Extension

Kanban Business Analysis in Agile Life-cycles

FIGURE 2.4 TypicalKanbanBoard

ThegoalofaKanbansystemistoallowworkloadstobedrivenbydemand,orpriority,tocreateacontinuousflowofworkthatavoidsbottlenecksatanyonepointintheprocess.Thismethodlimitstheamountofworkinprogressbyworkingononethingatatimeuntilitiscompletedbeforestartingthenexttask.Whenabottleneckoccurs,itisexpectedthattheentireteamwillcometogethertoremovetheblockagetohelpkeepworkmovingthroughtheflow.Thekanbanboardenablestheteamtomanagetheflowofwork,identifyingpotentialblockagesandensuringthatthenextiteminthequeueisalwaysreadyandwaitingtobeworkedon.Followingthismethodalsoexposesopportunitiesforprocessimprovementbymakingitpossibletoeasilyseewheredelaysareoccurringinthedevelopmentprocess.

2.3.3 Roles & ResponsibilitiesKanbandoesnotincludedefined,mandatedrolesorbusinessanalysismethods.Likeanyagilemethod,itdoesstrivetobreakdownworksuchthatindividualworkitemscanbeimplementedinarelativelyshortperiodoftime.TheKanbanmethodalsoattemptstobringtheprojectteamtogetherbyincreasingcommunicationandcollaboration,enablingtheteamtoworktogetherasacollectiveandcohesiveunit.

2.3.4 Business Analysis in KanbanBusinessanalysis,likeallactivitiesintheKanbanmethod,occursinaconstantandcontinuousflowthroughthelifeofaproject.Inordertomaintainaprioritizedqueueofwork,businessanalysistechniquesare

16 The Agile Extension to the BABOK® Guide

Page 25: The Agile Extension

Business Analysis in Agile Life-cycles Kanban

usedtoelicitnewproductfeatures.Requirementsanalysismethodsarethenusedtoprioritizetherequirementsbasedonbusinessvalue,whilealsocontinuouslyusingstandardbusinessanalysistechniquesforscopingtheproductandmanagingthequeueofrequirements.

WhenplanningandmanagingtasksintheKanbanmethod,ServiceLevelAgreements(orSLA’s)areusedtomaintaintheestimatesforhowlongafeatureorchunkofworkwilltaketobecompleted.InKanban,thisestimateincludestheplanningandanalysisactivitiesthattakeplacebeforesoftwaredevelopmentbegins.Thismethodforcesabusinessanalysttofocusonplanningandmonitoringactivities,enablingconstantrevisionandrefinementofestimatesaseachnewrequestenterstheanalysisportionofthecycle.

InaKanbanproject,thebusinessanalystonlybeginstodefinerequirementsforanewworkitemwhenthequeuestepsforward.Atthatpointthedevelopmentteambeginstoworkononeofthecompletedrequirements,whilethebusinessanalysisbeginscollectingrequirementsforthenextiteminthequeue.Aparticularlyefficientbusinessanalystmaybeabletodefinerequirementsforasystemfarfasterthanthoserequirementscanbedevelopedandtested,whilealessefficientbusinessanalystwillnot.Byopenlyandvisiblymanagingtheworkoftheprojectteam,theseinefficiencieswillsurfaceasprocessimprovementopportunities.Thiswillhelptomitigatetheriskrelatedtothetimingofbusinessanalysisactivities,enablingthebusinessanalysttomanagetheriskearlyintheprocess.

November2011DraftforPublicReview 17

Page 26: The Agile Extension

Comparison of Agile Life-cycles Business Analysis in Agile Life-cycles

2.4 Comparison of Agile Life-cyclesDespitepossessinguniquecharacteristicsanddifferentiators,agilemethodologiesandframeworksgenerallysharesomecommontraits.Thesecommoncharacteristicsareillustratedbelowinadepictionofagenericagilelifecycle.

FIGURE 2.5 GenericAgileLife‐cycle

Regardlessoftheagilemethodologyused,successfulagileprojectsfollowtheconsistentplanningrhythmorcadenceofStrategy,Release,Iteration,Daily,andContinuous(see“AgileLevelsofPlanning”onpage20).Thiscadenceiscombinedwiththenotionoffrequentandflexiblereleaseschedulesthatallowforhighcustomerinvolvementwithrapidfeedbackandfrequentproductassessments.

18 The Agile Extension to the BABOK® Guide

Page 27: The Agile Extension

Business Analysis in Agile Life-cycles Comparison of Agile Life-cycles

Thefollowingtableprovidesasummarycomparisonoftwomajoragileframeworksthathavebeenoutlinedinthischapter,ScrumandXP.

TABLE 2.2 Comparison of Agile Life‐cycles

TheKanbanmethod,oftenusedtosupplementframeworkssuchasScrumorXP,describesitsownrhythmorcadenceofworkprogression.Kanbanfailstoprescriberolesandresponsibilitiesforprojectteammembersortorecommendspecificdocumentationneedsfortheprocess.ThismakesKanbanacommoncontenderforblendedmethodologies.Itisimportanttonotethatitisverycommonforprojectteamstoblendcharacteristicsoftwoormoreagileframeworksandmethodologiestocreateabestfitfortheirteamandorganizationalcontext.

2.4.1 Selecting an Agile Methodology or Framework

Withthevarietyofagilemethodologiesavailable,thequestionarises,howdoteamschoosewhichmethodologybestsuitestheirproject?Thefollowingquestionsareexamplesofhigh‐levelquestionsthatcanhelpguidethischoice.

• Fromhowmanystakeholdersdoyouneedtoelicitrequirements?

• Wherearethesestakeholderslocated?Willtheybeatthesamesiteastheprojectteam?

• Willyoursoftwareapplicationbeintegratedwithothersystems?Ifso,howmanyandhowsoon?

• Arethereanyculturalororganizationalconstraintsthatwilllimitthenumberorfrequencyofproductreleasestheteamcanmake?

Characteristic Scrum XP

TypesofProjects All <20People;Non‐Life‐CriticalFunctions

PrioritizationValues Customer‐Driven Customer‐Driven

LevelofDocumentation Anythingofvalue Aslittleaspossible

•     Typical Management Docs BurndownChart Tasklist

•     Typical Requirements Docs ProductBacklog,SprintBacklog

FeatureCards

•     Typical Architecture Docs ArchitectureModelClass‐Responsibility‐Collaboration(CRC)Cards

•     Typical Test Docs

Models/Architecture High‐LevelModelsPrototyping

SketchesClass‐Responsibility‐Collaboration(CRC)Cards

November2011DraftforPublicReview 19

Page 28: The Agile Extension

Agile Levels of Planning Business Analysis in Agile Life-cycles

Theanswerstothesefundamentalquestionswillhelptoguidethechoiceofagilemethodologythatshouldbeused.Inturn,thechosenflavorofagilewilldrivethemanagementofstakeholders,thetempoofwork,thedurationofwork,documentation,analysis,andotheraspectsofthebusinessanalyst'sworkonaproject.

Whileweprovidesomeinsightintoseveralmethodswithinthischapter,therearemanyagilemethodologiesandframeworksavailabletochoosefrom.Westronglyrecommendthatyouresearchtheseagileframeworksandmanyotherstohelpyouunderstandhowtheyaredifferentandtheprosandconsofeachimplementation.Thiswillhelpyourteamtobestunderstandwhichwillfitprojectteamneedsmostappropriately.

2.5 Agile Levels of Planning

Duetothefluid,dynamicnatureofagilemethodologies,itisimportanttounderstandwhenandhowtoapplydifferentplanningtechniquesandtheappropriatelevelofdetailforeachlevelofplanning.Itisimportanttonotethatmanyofthetechniquesusedinanagileenvironmentaresimilartotraditionaltechniques,whatisdifferentishowandwhenanalystsapplythesetechniques.Just‐in‐timeandjustenoughrequirementsthatareconsistentlyvalidatedbythebusinessarecentraltotheanalyst'sroleinagilemethodologies.

Whenundergoingplanningexercisesintheagileworlditishelpfultoconsiderhowtheanalyst'srolediffersfromtraditionaldevelopmentmethodologies.Inagiletheroleoftheanalystiscentraltothevalueoftheproject.Theanalystholdsakeyroleinmaximizingvaluebyfacilitatingtheinteractionswithalltheprojectstakeholders.Exceptionallyhighcommunication,facilitation,andnegotiationskillsareanimportsetoftoolsforanalystsintheagileenvironment.

2.5.1 Agile Levels of Planning

Asmentionedintheprevioussection,ComparisonofAgileLife‐cycles(see“ComparisonofAgileLife‐cycles”onpage18),successfulagileprojectsfollowaconsistentplanningrhythmorcadenceofstrategy,release,iteration,daily,andcontinuous.Throughthecadence,therequirementsfortheprojectareprogressivelyelaboratedtoanappropriatelevelofdetail.Ateachstepstableconceptsarecaptured,contextiscaptured,andlearningopportunitiesareidentified.Oneofthekeystoagileistoperformasufficientlevelofanalysisateach

20 The Agile Extension to the BABOK® Guide

Page 29: The Agile Extension

Business Analysis in Agile Life-cycles Agile Levels of Planning

planninglevel.Toomuchanalysisupfrontcanresultincreationofdocumentsthataresubjecttochange,requirethebusinessusertoexplaintheirneedsmultipletimes,andmaynotbenecessarytoachievethegoalsoftheproject.Toolittleanalysisupfrontcanresultinirresponsiblecommitments,rework,andalackoffocusoncustomervalue.

2.5.1.1 Strategy

Projectsandproductdevelopmenteffortsstartwithavisionofthebusinessdirectionorneed.Thevisionincludesthewhat,why,andsuccesscriteriafortheeffort.Thevisionisoftenassociatedwitharoadmap.Theroadmapincludesthehigh‐levelscopeandmayincludeaninitialarchitecture.Inadditiontoactivitiessuchasestablishingavision,scope,androadmap,thestrategyworkonanagileprojectincludestheinitialcreationofafeaturerequestlist.Forexample,inScrumthisentailsseedingtheinitialrequestsinaproductbacklogor,inXP,userstores.Thisisanalogoustopre‐projectelicitationofbasicstakeholderrequirementsthatareusedtofacilitatediscussionsonscopingandphasinginnon‐agileprojects.

Atastrategiclevel,thepersonwhoownstheproductorisleadingtheinitiativehelpsthedeliveryteamto

• understandthecontextofthesolutionneeded,• identifythestepstorealizethevision,• prioritizethework,• assessthetechnicalimpactontheroadmap,and• facilitateobtainingestimatesforthereleases.

Muchlikeanyproject,strongenterprisebusinessanalysisskillsarerequiredtoeffectivelyplanastrategyforanagileproject.Insomeways,youcouldarguethattheseskillsbecomemoreimportantinagilemethodologies.Thisisbecausewithoutdirectionbasedonbusinessvalueandaclearlydefinedscopeandaudience,agileprojectsareatriskfordeliveringincrementalfeaturesthatnevercometogethertocreateend‐to‐endvalueforanyonecustomergroup.Withoutaroadmapandsuccesscriteriafortheproduct,agileprojectscouldconceivablygoonforever,possiblywastingtime,money,andotherresourcesintheprocess.

November2011DraftforPublicReview 21

Page 30: The Agile Extension

Agile Levels of Planning Business Analysis in Agile Life-cycles

2.5.1.2 Release

Releaseplanningisthephasewherethepersonwhoownstheproductgroupsactivitiesandallocatesthemtoteams.Teamsworkondefiningenoughdetailtoresponsiblycommittosomerangeofscopefortherelease.Teamsshouldreleasewhenthebenefitsofdeliveryoutweighthecostsassociatedwithrelease.Thereleaseisdefinedbyadate,strategictheme,andplannedfeatureset.Releasedatescanbelinkedtoevents,likeconferencesorcompliancerequirement.Inthereleaseplanningphasethescopeisfixedandtheprioritizedlistoffeaturerequests,suchasaproductbacklog,isusedasthebasisforplanning.

2.5.1.3 Iteration

Manyagileteamsworkinfixedtimewindowscalledsprintsoriterations.Aniterationplanningeventisheldatthestartofeachiteration.Priortothatiterationplanningmeeting,theitemsinthefeaturerequestlistthatarebeingconsideredfortheiterationneedtobesufficientlyunderstood,thusenablingtheteamtoresponsiblymakeacommitment.InScrumthisisknownasgroomingthebacklog.Incontinuousflowmodels,likeKanban,thefeaturerequestlistisstillgroomedbeforeitiscommitted,buttheplanningcadenceisbasedondemand,notonadefinedtimeperiod.Onsometeams,thecustomerorowneroftheproductcollaborateswiththedeliveryteamtogroomtherequestlistpriortoiterationplanning,whileotherteamsuselow‐fidelityspecificationsdevelopedduringspecificationworkshopsheldpriortoiterationplanning.Thisworkiscomprisedofrequirementcommunicationandanalysis,withadditionalelicitationanddocumentationasneeded.

Initerationplanning,theworkthatwillbeperformedinthesprintisidentified,estimated,reviewed,andcommittedto.Thedeliveryteammeetswiththecustomerortheowneroftheproducttounderstandtherequirementsandacceptancecriteria,andtogainclarityonspecifications.Thisisanalogoustotheworkatraditionalbusinessanalystperformstocommunicationrequirementstostakeholders.Duringiterationplanning,thedeliveryteammayalsoestimatetheeffortrequiredtodeliverthedesiredfeatures.Thisestimationisusedwhencommittingtotheiteration.Attheendofiterationplanning,thedeliveryteamcommitstodeliveringanincrementofworking,tested,deployablecode.

Afteraniterationhasbeencompleted,aniterationrevieworproductdemonstrationisheld.Theproductdemonstrationmeetingissimilar

22 The Agile Extension to the BABOK® Guide

Page 31: The Agile Extension

Business Analysis in Agile Life-cycles Agile Levels of Planning

tolight‐weightuseracceptancetestingandisgenerallylimitedtoamaximumof4hours.

Duringtheproductdemonstration

• thedeliveryteamdemonstrateshowthecodethatwasdevelopedmeetstheacceptancecriteria,

• theowneroftheproductdetermineswhichitemsonthefeaturelisthavebeencompletedintheiteration,

• anynewrequeststhatarisefromthecustomerasaresultofviewingthelatestproductareadded,and

• theowneroftheproductanddeliveryteamreviewthestateofthebusiness,themarket,andthetechnology,andre‐prioritizethefeaturerequestlistforthenextiteration.

Aftertheiterationreviewmeeting,theprocessstartsupagain.Whileaworkingproductistheexpectedoutputofeachiteration,manyagileteamswillwaittoreleaseaproductuntilseveraliterationsworthofworkhavebeencompleted.Theteammustdeterminetheappropriatetrade‐offpointbetweenthecosttodeliverthelatestproductandtheamountofneworimprovedfunctionalitythatwillbedeliveredtothecustomerbase.Iterationsproceeduntilenoughfeatureshavebeendonetocompleteorreleaseaproduct.

2.5.1.4 Daily

Agileteamsperformdailyteammeetingstocoordinatethework.Thedailymeetingisusuallyafifteenminutemeetingdesignedtoclarifythestateofthework.

Duringthedailymeetingtheteam

• getsaglobalsnapshotoftheproject,• discoversanynewdependencies,• addressesanypersonalneedsofcommittedindividuals,and• adjuststheworkplantomeettheneedsofthedayandensure

theteamcandeliverontheIterationcommitment.

Frequentlythedialogueheldduringthesemeetinguncoversitemsthatlackofclarityorrequirefurtheranalysis.Theteamthenidentifiesaplanfordealingwiththeseimpedimentstotheproject.Thisoftenentailsassigningsomeonetodofurtherbusinessanalysisworkforelicitationandanalysisontheimpactedrequirements.

November2011DraftforPublicReview 23

Page 32: The Agile Extension

Agile Levels of Planning Business Analysis in Agile Life-cycles

2.5.1.5 Continuous

Therearemanydynamicactivities,efforts,andchallengesthatariseduringtheplanningphasesofagileprojects.Herearesomeguidingprinciplesthatthoseconductingbusinessanalystmayfindhelpful,notonlyduringtheplanningphase,butthroughtheagileproject’slifecycle.

• Startwithvalueandkeeptheteamtruetovalue.Itisvitalthattheindividualholdingthebusinessanalysisroleispayingcloseattentiontotheproject’sbusinessvalue.

• Low‐fidelityartifactsserveasanenablerofbusinessvaluebycreatingcontextandgeneratingsharedunderstanding.However,theydonotreplace,oreventakeprecedenceovereffectivecollaborationandconversation.

• Businessanalysisisaboutfacilitatingdiscussionandunderstanding.Businessanalyststypicallydonotpossessthedepthofunderstandingaboutthebusinessasdoesthebusinesssponsor,orasmuchabouttechnologyasthetechnologyteam.

• Operateinthebestinterestofthebusinessovertime.Responsiblybalancevalueandcapacity.

• Identifyandcommunicatecompetingconcernsandgapsinunderstandingbetweenthebusinessandtechnology.Ensurethatcommonunderstandingisreached.

• Resourcesarelimitedandvaluable.Alwaysassistinmaximizingeffortovertime.

• Assisttheteamtoaction.Effectivelycommunicatewhatisrequiredwhentakingthenextsteps.Ensurethatfeedbackisclearlyunderstoodandactedonbytheteam.

• Deliverincrementallyanditeratively.Dothesmallest,simplestthingthatcouldpossiblywork.Iteratetoreachminimalvalue.Progressivelyelaborateinsmallpieceswhiletestingassumptionsandarticulatingclearacceptancecriteria.

• Producethesmallestamountofdocumentationthatmeetstheneedsoftheteamanddeliveritatthelatestresponsiblemoment.

24 The Agile Extension to the BABOK® Guide

Page 33: The Agile Extension

chapter 3

Knowledge Areas

ThefollowingareasofknowledgerepresentaselectionofpopularagilebusinessanalysistechniquesidentifiedthroughthedevelopmentoftheAgileBABOK®Extension.ManyofthebusinessanalysistechniquesdescribedintheBABOK®Guidecontinuetobeusableinanagilecontext,aswell,andothertechniquesnotlistedheremayprovetobeusefulandapplicableinaparticularsituation.

3.1 Mapping Techniques to Knowledge Areas

3.1.1 Business Analysis Planning and Monitoring

BusinessAnalysisPlanningandMonitoring(Chapter2oftheBABOK®

Guide)describestheworkrequiredforabusinessanalysttodeterminetheactivitiesthatwillberequiredtoperformbusinessanalysisthroughthelifecycleofaproject.Inagiledevelopment,mostplanningisdeferreduntilworkonanactivityisreadytobegin,butsomedegreeofup‐frontplanningisusuallyrequired.

.1 Plan Business Analysis Approach (2.1)

Agilemethodologiesfallintothegeneralcategoryofchange‐drivenapproaches,asdescribedintheBABOK®Guide.Somebusinessanalysisworkwillgenerallybeperformedupfronttodefineavisionfortheproject,butdetailedanalysiswillbeperformedas‐needed.Ifitisunclearwhatproblemsthesoftwareissupposedtosolve,orthereareseveralstakeholdergroupswithconflictinginterests,itmaybenecessarytodobusinessanalysisworkpriortothebeginningofaprojecttoreachagreementonthevisionfortheproduct.

Techniques

Backlog Management:Backlogmanagementistheprimarymethodofhandlingbothrequirementsprioritizationandchangemanagementin

November2011DraftforPublicReview 25

Page 34: The Agile Extension

Mapping Techniques to Knowledge Areas Knowledge Areas

mostagilemethods.Analternativetobacklogmanagementisakanbanboard(describedunder“Kanban”onpage11).

Planning Workshop:Businessanalystsparticipateinplanningworkshopstodeterminethebusinessanalysiseffortandactivitiestosupportateamobjective.

Real Options:Realoptionanalysismayhelpdeterminewhenbusinessanalysisneedstobeconductedtoinvestigateaparticularbusinessissue.

Retrospectives:Thefeedbackfrompriorretrospectivesshouldbeconsideredwhenselectingtheapproach.

.2 Conduct Stakeholder Analysis (2.2)

Stakeholdersmaybechallengedbytherapid,iterativedevelopmentfoundinanagileprojectandtheneedtobeoncallwheneverinformationisneededbytheteam.Whatistheimpactoftheagilecadenceonthestakeholder?Howdoesprogressiveelaborationimpacttheexpectationsofthestakeholder?Canthestakeholderparticipateinupdatingtheprocesses,interactions,andproductsspecificationsduringthecourseoftheproject?

Techniques

Collaborative Games:Manycollaborativegamescanbeusedtounderstandtheperspectivesofvariousstakeholdergroups.

Personas:Personascanhelptheanalystordevelopmentteambyenablingthemtobettervisualizetheneedsofgroupswhodonothavearepresentativepresent.

.3 Plan Business Analysis Activities (2.3)

Businessanalysisactivitiesareplannedasneeded,usuallyatthestartofeachiterationorwhenanewworkitemisreadyforanalysis.Thereislessofafocusonformaldocumentation(althoughitstillcanberequiredtomeetstatutoryorregulatoryrequirements,ortocaptureknowledgedevelopedduringtheanalysisanddevelopmentprocess)andmorefocusonprogressiveelaborationofdocumentationthroughoutthelifeoftheproject.Also,muchoftheelaborationisreplacedbyinteractionsandceremonysotheseoutcomesneedtobeaccomplishedwithactivitiesaddressedinthecommunicationplan.

26 The Agile Extension to the BABOK® Guide

Page 35: The Agile Extension

Knowledge Areas Mapping Techniques to Knowledge Areas

Techniques

Planning Workshop:Decisionsregardingbusinessanalysisactivitieswillusuallybemadeduringaplanningworkshop.

.4 Plan Business Analysis Communication (2.4)

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

Techniques

Personas:Thesemayproveusefulinassessingthelikelycommunicationneedsofspecificstakeholdergroups.

.5 Plan Requirements Management Process (2.5)

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

Techniques

Backlog Management:Mostagilemethodsusebacklogmanagementtodeterminewhichrequirementsarereadytobeworkedonbythedevelopmentteam.

.6 Manage Business Analysis Performance (2.6)

Thisactivitywillbeperformedonanongoingbasisasthebusinessanalystlearnstoworkeffectivelywithstakeholdersandthedevelopmentteam.Aseveryoneinvolvedbetterunderstandshowtoworktogethertodelivervalue,thebusinessanalysisprocess,methods,ortechniquesinusemayneedtochange.Effectivebusinessanalysis

November2011DraftforPublicReview 27

Page 36: The Agile Extension

Mapping Techniques to Knowledge Areas Knowledge Areas

performancewillresultinlimitedreworkoftherequirementsdocumentation,effectiveprioritizationandscopingofrequirements,andclearcommunicationofneedtothedevelopmentteam.

Techniques

Retrospectives:Retrospectivesareacommonpracticeusedbyagileteamsseekingtoimprovetheirwaysofworking.Businessanalystsshouldlookforfeedbackontherequirementstheyprovidetotheteamandhowandwhenthoserequirementsareprovidedinordertofindwaystoimprovetheirprocesses.

Value Stream Mapping:Valuestreammappingcanbeusefulinassessinghowbusinessanalysisactivitiesarecontributingtothedeliveryofvaluetothecustomerandidentifyingactivitiesthatmaynotbeaddingvalue.

3.1.2 Elicitation

Elicitation(Chapter3oftheBABOK®Guide)describeshowbusinessanalystsworkwithstakeholderstoidentifyandunderstandtheirneedsandconcerns,andunderstandtheenvironmentinwhichtheywork.Effectiveelicitationensuresthatthestakeholders’actualunderlyingneedsareunderstood,ratherthanstatedorsuperficialdesires.Elicitationisongoingthroughouttheprojectandperformedinconjunctionwithanalysisactivities(ascomparedtotraditionalapproaches,whereitispossibletoperformelicitationasadistinctactivityorphase).

.1 Prepare for Elicitation (3.1)

Preparingforelicitationchangesduringthelifeoftheproject.Earlyon,itisdonebythebusinessanalysttocoordinatesupportingmaterialsandscheduleresourcestodefinethehigh‐levelrequirements.Astheprojectprogresses,workiscoordinatedbyprioritizationofthebacklog.Stakeholdersworkdirectlywiththedevelopers,whenpossible,toelaboraterequirements.Wherethisisnotpossible,thebusinessanalystmustactasaproxy.Thistaskrequirestheschedulingofresourcesandthecoordinationofinputstoalignwiththeprogressiveelaborationofthebacklog.

28 The Agile Extension to the BABOK® Guide

Page 37: The Agile Extension

Knowledge Areas Mapping Techniques to Knowledge Areas

Techniques

Personas:Personasmayprovideinsightintotheparticularneedsofastakeholderorthetechniquesthatwillbemosteffectiveinunderstandingthoseneeds.

User Story:Auserstorywillidentifytheroleforwhomthestoryprovidesvalue(andthereforeidentifythestakeholderswhocanelaborateonthatvalue).

.2 Conduct Elicitation Activity (3.2)

Elicitationactivitiesareconductedonafrequentbasisthroughouttheproject,possiblyevendaily.Earlyon,elicitationisperformedtodefinehigh‐levelrequirementsoravisionfortheproduct.Astheprojectprogress,stakeholdersinteractwiththedevelopmentteamdirectlyduringiterationplanninganddevelopment.Theintentofallelicitationactivitiesistogeneratejustenoughdetailtoensurethattheworkathandisperformedcorrectly.

Techniques

Behaviour Driven Development:Stakeholdersmayfinditeasiertoarticulatetheirneedsbyprovidingexamplesratherthanthroughabstractmodels.

Collaborative Games:Collaborativegamesencourageparticipantsinanelicitationactivitytocollaborateinbuildingajointunderstandingofaproblemorasolution.

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

.3 Document Elicitation Results (3.3)

Amajorvalueofdocumentationisthatitcanbeusedforlong‐termknowledgeretention.Agilemethodsaimtominimizethetimebetweenthedevelopmentofrequirementsandtheirimplementationinsoftware,reducingtheoverallvalueofthatdocumentationtotheteam.Recordsofelicitationactivitiesshouldbekepttoensurethatkeydecisionscanbeunderstoodatalaterdate,ortoensurethatregulatoryorgovernancerequirementsaremet.

November2011DraftforPublicReview 29

Page 38: The Agile Extension

Mapping Techniques to Knowledge Areas Knowledge Areas

Techniques

Lightweight Documentation:Seethissectionforguidelinesondevelopingdocumentation.Inmostcases,therewillnotbeseparatedocumentationoftheelicitationandanalysiswork.

.4 Confirm Elicitation Results (3.4)

Thiswillbeperformedbytheteamduringiterationplanning,duringthedevelopmentiteration,andatcustomeracceptance.Thecustomermaychangetheirmindaboutsomespecificelementofastoryafterseeingtheresult.Thisfeedbackbecomesaninputintotheconductelicitationactivity.

Techniques

AcceptanceandEvaluationCriteriaDefinition:Elicitationoutcomeswillfrequentlybecapturedintheformofacceptancecriteriathatwillbeusedbytheteamtoverifythatthesoftwaremeetsstakeholderneeds.

3.1.3 Requirements Management and Communication

RequirementsManagementandCommunication(Chapter4oftheBABOK®Guide)describeshowbusinessanalystsmanageconflicts,issues,andchangesinordertoensurethatstakeholdersandtheprojectteamremaininagreementonthesolutionscope,howrequirementsarecommunicatedtostakeholders,andhowknowledgegainedbythebusinessanalystismaintainedforfutureuse.

.1 Manage Solution Scope and Requirements (4.1)

Asagileprojectsunfold,thescopeisdefinedwithincreasingspecificity.Thespecificdetailsofthescopecanbefoundinthesolutionbacklog.Basedonthelevelofelaboration,thesolutionbacklogitselfmayvaryinitsownlevelofdetail.Itshouldalsobeconsideredthatthesponsormaydecidetoterminatetheprojectshouldtheydecidethatfurthereffortswillnotprovideanacceptablereturnofbusinessvalue.

Techniques

Backlog Management:Mostagileteamsusetheproductbacklogtomanagebothsolutionscopeandrequirements.

30 The Agile Extension to the BABOK® Guide

Page 39: The Agile Extension

Knowledge Areas Mapping Techniques to Knowledge Areas

.2 Manage Requirements Traceability (4.2)

Onagileprojects,everythingisconnectedbacktothestrategicthemes,epics,andstoriesthatareusedtodefinetheproject.Thisismaintainedbytheproductownerorthebusinessanalyst.

Techniques

Story Mapping:Storymapsshowrelationshipsbetweenuserstoriesandlargeractivitiesthattheusermustbeabletoaccomplish.

.3 Maintain Requirements for Reuse (4.3)

Inmatureagileorganizations,thishappensmuchthesamewayasitdoesintraditionalefforts.Thedifferenceisinthewaythatrequirementsaredocumentedattheendoftheproject.Often,thesourcecodeitselfiswrittentobeself‐documenting.

Techniques

AcceptanceandEvaluationCriteriaDefinition:Theacceptancetestsandcriteriadevelopedduringtheprojectaremaintainedtovalidateanyfuturechangestothesoftware.

.4 Prepare Requirements Package (4.4)

Thisishandledthroughscenarios,usecases,acceptancetests,andmock‐upsandmodelsassociatedwiththethemes,epics,andstoriesusedtodefinetheproject.Thisisanongoingactivitythroughthelifeofthedevelopmentofthesolution.Thespecifictechniquesusedwilldependupontheapproachchosenatthebeginningoftheproject,andwillchangebasedontheemergentunderstandingofwhatworksbestinthecontextoftheproject.

Story Decomposition:Epics,features,orminimallymarketablefeatures(MMF)tiegroupsofuserstoriestogetherintolargerpackagesthatcanbediscussedwithstakeholders.

.5 Communicate Requirements (4.5)

Requirementsarecommunicatedtodevelopersinreleaseplanningmeetingswherethemesandstoriesarereviewedandselectedforrelease.Theyarediscussedinmoredetailiniterationplanning

November2011DraftforPublicReview 31

Page 40: The Agile Extension

Mapping Techniques to Knowledge Areas Knowledge Areas

meetingswherethemodelsandspecificationsareselectedanddiscussedamongtheteamandtheproductowner.Intheseiterationplanningmeetings,risksarealsoreviewedanddiscussed.

Planning Workshop:Seethistechniqueforfurtherdetails.

3.1.4 Enterprise Analysis

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

.1 Define Business Need (5.1)

Nosignificantchanges.

Techniques

Business Capability Analysis:Abusinessneedwillusuallycorrespondtothedevelopmentofanewcapabilityortheenhancementofanexistingcapability.

Collaborative Games:Somecollaborativegamescanbeusefulinexposingunmetbusinessneeds.

.2 Assess Capability Gaps (5.2)

Nosignificantchanges.

Techniques

Business Capability Analysis:Thiscanbeusedtounderstandwhatshortcomingsexistinanexistingcapability.

.3 Determine Solution Approach (5.3)

Agiledevelopmentisasolutionapproach.Itmaybeselectedinordertoprovideafasterdeliveryofvaluethantraditionalmethods,or

32 The Agile Extension to the BABOK® Guide

Page 41: The Agile Extension

Knowledge Areas Mapping Techniques to Knowledge Areas

becausetheproblemareaneedstobeexplored.Italsosupportsincrementaldeliverysothesolutionapproachcanbeevolvedoverthecourseoftheproject.Thisapproachallowsadifferentbargaintobestruckwiththebusinessregardingdeterminingthesolution.

Techniques

Purpose Alignment Model:Thepurposealignmentmodelcanprovideguidanceregardingthebestsolutionapproachtotakeforagivenbusinessneed.

.4 Define Solution Scope (5.4)

Thescopeofagileprojectsevolvesduringthecourseoftheprojectastheteamlearnsmoreaboutwaystosolvetheproblemandthecustomerpreferencesforasolution.Thescopeisdefinedinhigher‐levelabstractions(suchasthemesandepics)andisdetailedastheprojectevolves.

Business Capability Analysis:Thescopeoftheprojectshouldberelatedtothebusinesscapabilitiesitiscreatingorenhancing.

Story Decomposition:Epicsandfeaturescanserveasthebasisfordefiningthescope.

Story Mapping:Astorymapcanbeusedtoseetherelationshipbetweenthevariousstoriesdeliveredbytheproject.

.5 Define Business Case (5.5)

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

Business Capability Analysis:Definesthecustomerandorganizationalvalueassociatedwithabusinesscase.

Kano Analysis:Identifieswhichproductfeaturesarelikelytohavethegreatestmarketimpact.

November2011DraftforPublicReview 33

Page 42: The Agile Extension

Mapping Techniques to Knowledge Areas Knowledge Areas

Purpose Alignment Model:Identifieswhatkindofinvestmentislikelytogeneratethegreatestvaluefortheorganization.

Real Options:Allowsassessmentofwheninvestmentneedstobemadeinordertoensurevalueisobtained.

3.1.5 Requirements Analysis

RequirementsAnalysis(Chapter6intheBABOK®Guide)describeshowbusinessanalystsprioritizeandprogressivelyelaboratestakeholderandsolutionrequirementsinordertoenabletheprojectteamtoimplementasolutionthatwillmeettheneedsofthesponsoringorganizationandstakeholders.Itinvolvesanalyzingstakeholderneedstodefinesolutionsthatmeetthoseneeds,assessingthecurrentstateofthebusinesstoidentifyandrecommendimprovements,andtheverificationandvalidationoftheresultingrequirements.

.1 Prioritize Requirements (6.1)

Inagile,requirementsareprogressivelyelaborated.Throughouttheelicitationtask,elicitationresultsareprogressivelybrokendownandelaborated.Ateachpointofelaborationtheconstituentpartsneedtobeevaluatedandprioritizedbasedonbusinessvaluecontributionandriskburn‐down.Inagile,thisisnotaone‐timeupfrontactivity.Thishappensthroughoutthelifeoftheprojectonallremainingworkandnewworkbroughtinfromlearningabouttheproduct.

Techniques

Backlog Management:Backlogmanagementisthestandardmethodofprioritizingrequirementsinmanyagilemethodologies.Thebacklogcanbere‐prioritizedwheneverbusinessneedschangeorarebetterunderstood.

Kano Analysis:Kanoanalysiscanprovideinsightintotherelativeimportanceoffeaturestoausergroup.

Planning Workshop:Prioritizationnormallytakesplaceduringaplanningworkshop.

Note:alsoseetheexpandedtreatmentofMoSCoW Prioritization.

34 The Agile Extension to the BABOK® Guide

Page 43: The Agile Extension

Knowledge Areas Mapping Techniques to Knowledge Areas

.2 Organize Requirements (6.2)

Inagile,itisimportanttoorganizerequirementstominimizedependenciesbetweenfeaturesets.Thisreducescomplexityandriskandimprovestestabilityatthebusinesslevelvalue.Sincerequirementsareprogressivelyelaborated,thisbigblockarchitectureresultsinthesolutionarchitecturefromabusinessstandpoint.Requirementsshouldbeorganizedaroundbusinessvalueandnottechnicalimplementations.Onlywithincomponentteams,wherethebusinessvaluearisesfromdeliveringenablingtechnology,isitappropriatetodepicttechnicalrequirements.Eventhen,theserequirementsneedtobeprioritizedandfilteredbasedonriskburndownandbusinessvaluecontribution.Storymapswithinepicsareamethodofimplementingorganizerequirements.

Techniques

Story Decomposition:Individualstoriesmaybeorganizedaroundanepicorfeature.

Story Mapping:Storymappingalsoshowshowindividualstoriesarerelatedtoorsupportoneanother.

.3 Specify and Model Requirements (6.3)

Atdifferentlevelsofelaborationtherearedifferentmethodsforspecifyingandmodellingrequirements.Theapproachshouldsupportprogressiveelaboration,beadaptabletochangebasedonlearning,andnotcausetheteamtoselectsolutionstooearly.Itshouldalsoensurethatintentandintendedbusinessvalueiscommunicatedconsistentlythroughtheelaboration.Agileteamstendtousestoriesandtasksatthelowestlevelofdecomposition.Thesestoriesandtaskscanbesupportedbydetaileddocumentationandusecases.Itisbecomingincreasinglycommonforacceptanceteststobeproducedaspartofspecifyingandmodellingtherequirements.

Techniques

Behaviour Driven Development:Concreteexamplesoffunctionalitymayhelpstakeholdersbetterspecifyandunderstandtheirneeds,ordealwithspecificscenariosthatareofgreatervalue.

Storyboarding:Usedtodescribeuserinterface(UI)functionalityandbehaviour.

November2011DraftforPublicReview 35

Page 44: The Agile Extension

Mapping Techniques to Knowledge Areas Knowledge Areas

Note:alsoseetheexpandedtreatmentofUser Storyinthisextension.

.4 Define Assumptions and Constraints (6.4)

Onagileprojects,thisishandledthroughariskmanagementapproachthattreatsrisksasstorieswithinthemes.Riskmitigationactivitiesarere‐prioritizedalongwithstoriesandburneddownandre‐prioritizedastheystoriesareperformed.Thisistypicallyproducedbythebusinessanalystandprojectmanageralongwiththeteam,prioritizedbytheproductowner,andperformedbytheteam.

User Story:Userstoriescanalsobeusedtotrackassumptionsorconstraints(particularlythelatter),althoughitneedstobecleartotheteamandstakeholdersthattheseareseparatefromthestoriesplannedfordevelopment.

.5 Verify Requirements (6.5)

Requirementsareverifiedbytheteamduringtheproject.Throughretrospectivesandoperationsreviews,theteammaydecidetomodifythelevelofdetailtorequirementsorthemethodofspecifyingandmodellingrequirementstoimprovetheperformanceoftheteam.Verificationofrequirementsusuallyisdonethroughdirectstakeholderinteractionwiththeteamasthesoftwareisdeveloped.

.6 Validate Requirements (6.6)

Requirementsareverifiedthroughoutthedevelopmentanddeliveryofthesolutionthroughcontinualinvolvementoftheproductownerandcustomer.Thishappensatreleaseplanning,iterationplanning,duringdevelopment,andatcustomeracceptance.

3.1.6 Solution Assessment and Validation

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

36 The Agile Extension to the BABOK® Guide

Page 45: The Agile Extension

Knowledge Areas Mapping Techniques to Knowledge Areas

.1 Assess Proposed Solution (7.1)

Inagileprojects,thistaskislikelytobeperformedrepeatedlyasthesolutionisbuilt.Oneofthebenefitsofagileisthatthesolutioncanbeassessedovertime.Somesolutiondecisionsmustbemadeupfront.Agilefacilitatestheconceptofrealoptionswheredesigndecisionscanbedeferreduntilthelastresponsiblemoments.Detailedunderstandingofthebusinessneedisunfoldingatthesametimeastheteam’sunderstandingofhowtosolvetheproblemisdeveloping.Witheffectiveagilearchitectureanddesign,thecostofredoingthingsthathavealreadybeendevelopedisrelativelylow.Assessingtheproposedsolutiondoesn’tbecomeacheckpointontheprojectbutanongoingassessmentagainstthebusinesscaseandcurrentstatusoftheproject.

Techniques

Real Options:Allowsforassessmentofaspectsofthesolutiontodeterminewhendecisionshavetobemaderegardingaparticularproposal.

.2 Allocate Requirements (7.2)

Onagileprojects,thisisdonebyallocatingrequirementsintofeaturethemesandcomponents.Agileteamsaresmallteamsandthisallocationshapesthedesignofthedeliveryorganizationitself.Featureteamsformaroundthefeaturethemesandcomponentteamssupportingcross‐featurethemerequirements.

Techniques

Story Decomposition:Breaksdownhigh‐levelepicsandfeaturesintosmallersupportingstories,whichcanbeallocatedtodifferentcomponents(includingprocessororganizationalchanges).

.3 Assess Organizational Readiness (7.3)

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

November2011DraftforPublicReview 37

Page 46: The Agile Extension

Mapping Techniques to Knowledge Areas Knowledge Areas

.4 Define Transition Requirements (7.4)

Thedeterminationoftransitionrequirementsoccursinanagileprojectmuchasitdoesinatraditionalproject.Theabilitytodelivervalueincrementallyopensupnewpossibilitiesfortransition.Unlikeamonolithicrelease,theorganizationalimpactcanbesmallerbutmorefrequent.Sincethecostofdevelopmentperunitislower,temporaryintegrationintoexistingsystemscanbedevelopedandmaketheneedforrunningparallelsystemslesssignificant.

Techniques

User Story:Userstoriescanbeusedfortheplanningoftransitionrequirementsandareprioritizedand/ororderedinthesamefashionasotherstories.

.5 Validate Solution (7.5)

Validationofasolutionhappensasanongoingeffortinanagileproject.Withineachiteration,thecustomerisprovideddetailedfeedbackonthecurrentrequirements.Atthecompletionofeachiterationcycle,theproductownerfacilitatesalignmentwiththecustomerneedandcontinuedalignmentwiththebusinesscase.

.6 Evaluate Solution Performance (7.6)

Uponrelease,theproductownerfacilitatesunderstandinghowwellthesolutionmeetstheneedsofthecustomerandidentifiesnewopportunitiesforimprovementandtocreateadditionalvalueforthebusiness.Theincrementalnatureofthebacklogallowsnew,highervalueitemsdiscoveredduringthisevaluationtoenterintotheexistingbacklogaheadofexistingitems.Thisisanadditionalwaythatagileshortenstimetovalue.

Techniques

Business Capability Analysis:Allowsbusinessanalystsandstakeholderstounderstandtheimportanceandrelativeperformanceofabusinesscapability.

Value Stream Mapping:Usedtoidentifythoseaspectsofthesolutionthataddvalueforcustomersandthosewhicharenon‐valueadded.Thisassessmentbecomesthebasisforongoingimprovementefforts.

38 The Agile Extension to the BABOK® Guide

Page 47: The Agile Extension

Knowledge Areas Mapping Techniques to Knowledge Areas

3.1.7 Business Analysis Techniques Mapped to Agile Business Analysis Guidelines

ThefollowingtablemapstechniquesasdescribedintheBABOK®

Guidetotheguidelinesforagilebusinessanalysispresentedinthisdocument.

TABLE 3.3 Business Analysis Techniques Mapped to Agile Business Analysis Guidelines

Business Analysis Technique

BABOK v.2 Chapter

See the Whole

Think as a Customer

Get Real with Examples

Analyze to Determine What is Valuable

Understand What is Doable

Stimulate Collaboration & Improvement

Avoid Waste

Acceptance & Evaluation criteria definition

9.1

Base lining 4.1.5.2

Benchmarking 9.2

Brainstorming 9.3

Business Rule Analysis 9.4

Checklists 6.5.5.2

Coverage Matrix 4.2.5.1

Data Dictionary and Glossary

9.5

Data Flow Diagrams 9.6

Data Modeling 9.7

Decision Analysis 9.8

Document Analysis 9.9

Estimation 9.10

Feasibility Analysis 5.3.5.2

Focus Groups 9.11

Force Field Analysis 7.3.5.2

Functional Decomposition

9.12

Interface Analysis 9.13

Interviews 9.14

November2011DraftforPublicReview 39

Page 48: The Agile Extension

Mapping Techniques to Knowledge Areas Knowledge Areas

Lessons Learned Process

9.15

Metrics and Key Performance Indicators

9.16

MoSCOW Analysis 6.1.5.2

Non-functional Requirements Analysis

9.17

Observation 9.18

Organization Modeling 9.19

Problem or Vision Statement

5.4.5.2

Problem Tracking 9.20

Process Modeling 9.21

Prototyping 9.22

RACI Matrix 2.2.5.2

Requirements Documentation

4.4.5.1

Requirements for Vendor Selection

4.4.5.2

Requirements Workshops 9.23

Risk Analysis 9.24

Root Cause Analysis 9.25

Scenarios and Use Cases 9.26

Scope Modeling 9.27

Sequence Diagrams 9.28

Signoff 4.1.5.3

Stakeholder Map 2.2.5.3

Business Analysis Technique

BABOK v.2 Chapter

See the Whole

Think as a Customer

Get Real with Examples

Analyze to Determine What is Valuable

Understand What is Doable

Stimulate Collaboration & Improvement

Avoid Waste

40 The Agile Extension to the BABOK® Guide

Page 49: The Agile Extension

Knowledge Areas Mapping Techniques to Knowledge Areas

State Diagrams 9.29

Structured Walkthrough 9.30

Survey/Questionnaire 9.31

SWOT Analysis 9.32

Timeboxing/Budgeting 6.1.5.3

User Stories 9.33

Variance Analysis 2.6.5.2

Vendor Assessment 9.34

Voting 6.1.5.4

Business Analysis Technique

BABOK v.2 Chapter

See the Whole

Think as a Customer

Get Real with Examples

Analyze to Determine What is Valuable

Understand What is Doable

Stimulate Collaboration & Improvement

Avoid Waste

November2011DraftforPublicReview 41

Page 50: The Agile Extension

Mapping Techniques to Knowledge Areas Knowledge Areas

42 The Agile Extension to the BABOK® Guide

Page 51: The Agile Extension

chapter 4

Techniques

4.1 A Context for Agile Business Analysis

ThischapteroftheAgileExtensiontotheBABOK®Guideprovidesanalystswithskillsandtoolsthatwillassisttheminexcellingintheagileworld.Inorderforthetechniquesandskillspresentedinthissectiontobeappliedwithsuccess,therearesomefoundationalprinciplesthatarerequiredtobeunderstood.Theseprinciplesbreakdownintoanumberofpracticaltechniquesthatcanbeusedbypractitionerswhentheyundertakebusinessanalysisonagileprojects.

Theprinciplesthatguidesuccessfulbusinessanalysiscanbecategorizedintotwodistinctframeworks:discoveryanddelivery.

Thediscoveryframeworkdealswiththewhat’sandthewhy’softheproduct.Effectivediscoveryisformulatedbythreeunderlyingprinciples:

• See The Whole,• Think as a Customer,and• Analyze to Determine What is Valuable.

Thedeliveryframeworkdealswiththehow’sandthewhen’softheproduct.Effectivedeliveryisformulatedbyfourunderlyingprinciples:

• Get Real Using Examples,• Understand What is Doable,• Stimulate Collaboration & Continuous Improvement,and• Avoid Waste.

Thefollowingsection,AgileExtensionTechniques,exploreseachprincipleindepthandprovidestechniquestosupporttheapplicationoftheseprinciples.

November2011DraftforPublicReview 43

Page 52: The Agile Extension

Guidelines for Agile Business Analysis Techniques

4.1 Guidelines for Agile Business Analysis

Thefollowing7guidelinesforpracticingbusinessanalysisinsideanagilecontext,arebasedonthevaluesandprinciplesoftheAgileManifestoandtheprinciplesofLean.Together,theseguidelinesembodythedisciplineofagilebusinessanalysis.Theseguidelinesprovidevaluablecontextwhenapplyingthevarioustechniquesdescribedinthischapter.

• Inanagilecontext,businessanalysisviewstheentiresystemofpeople,process,andtechnologytofindwheretruevalueliesandtohelporganizationsmaximizesthelikelihoodofdeliveringavaluableandvaluedsolution.

• Agileanalysispaysspecialattentiontothevoiceofthecustomertounderstandtheirvaluesandexpectations.

• Toconfirmwhatisvaluable,itiscommontouseconcreteexamplestobothelicitandvalidateproductneeds.

• Technologystakeholdersareempoweredbyeffectivelyanalyzedneeds.Ithelpsthemdeterminehowmuchworktheycandeliveratanygivenpointintime,identifyproductrequirementsoptions,andproviderecommendationstobusinesspartnersonsolutions.

• Facilitativetechniquesenableefficientandeffectivecollaborationandaccelerateateam'sabilitytodefineanddeliverproducts.Trustandsafetyareintegraltohealthyteam'sandallowsthemtotransparentlyidentifyimprovementopportunities.Improvingbothproductandprocessisimperative;thereforeagileteamscontinuallyseektoalwaysgetbetter.

• Alwaysbeonthelookoutfor,andavoid,anythingwasteful.

Adoptingtheseguidelinesrequiresleveraging,extending,andadaptingfoundationalbusinessanalysistechniques.“BusinessAnalysisTechniquesMappedtoAgileBusinessAnalysisGuidelines”onpage39foramatrixofbusinessanalysistechniquesthatmayapplyinanagilecontext.

4.1 A Note on Agile Extension Techniques

Agilebusinessanalysisisstillinarelativelyearlyphaseofdevelopment.Assuch,thetechniquesusedbybusinessanalyststosupportagileteamsarealsoinastateofflux.Webelievethatthe

44 The Agile Extension to the BABOK® Guide

Page 53: The Agile Extension

Techniques See The Whole

techniquesdescribedherehaveprovenvalueinsupportingagilebusinessanalysis,butwedonotclaimthatthislistisall‐inclusiveorinanywaycanonical.Thetechniquesherewereselectedbasedontheexperiencesoftheteammembers,andrepresentbothexpansionstoexistingcontentintheBABOK®Guideandnewtechniquesnotdescribedinthecurrentversion.FutureversionsoftheAgileExtensionwilllikelyincludenewtechniques,anditisalsopossiblethatsomeofthetechniqueslistedherewillberemoved.

Inaddition,manyofthetechniqueslistedheremayproveusefultobusinessanalysispractitionerswhoarenotworkingonagileteams.

4.1 See The Whole

SeetheWholeisaconceptthatdescribestheneedtolookataproblemoropportunityinthecontextofthebigpicture,focusingonthebusinesscontextandwhyaprojectisbeingundertaken.Itdescribesnotjustwhatasystemis,buthowitwillbeused.Itisimportanttoassesshowthesolutionachievessomethingofvalueforitsrecipients.Thevaluecontextforthesolutioniscreatedbyunderstandingboththesolutionandthestakeholders,andthenarticulatingwhotheyareandhowtheywillfindvalueinthesolution.

Onagileprojectsthereisahighriskofgettingmiredinthedetailsoneachiteration.Whendevelopingthebusinesscaseforasolutionandperformingiterationandreleaseplanningactivities,itisimportanttomaintainthefidelityofthecontext.Bydoingso,thecontextguidesthenextlevelofelaboration.Bythinkingaboutthestrategicoutcomeforthesolution,thedeliveryteammovesfromordertakerstoagroupthatdeliversbusinessvaluewithlesscodebloat,scopecreep,andnever‐endingprojecttimelines.Seeingthewholecreatessituation,appropriatecontextandasharedunderstandingofthebusinessproblemthatneedstobesolved,whichinturnwillguidedecisionmaking.

Thefollowingsectionsdescribecommonlyusedtechniques.

• Business Capability Analysis• Personas• Value Stream Mapping

November2011DraftforPublicReview 45

Page 54: The Agile Extension

See The Whole Techniques

4.1.1 Business Capability Analysis

.1 Purpose

Provideaframeworkforproductscopingandreleaseplanningby:generatingasharedunderstandingoftheoutcomesofabusinessorproduct,identifyingalignmentwithastrategyandspecificperformancegaps,andprovidingascopeandprioritizationfilterthatisstableandlowfrictiontomaintainovertime.

.2 Description

Businesscapabilitiesdescribetheabilityofabusinesstoactonortransformsomethingthathelpsachieveabusinessgoalorobjective.Manyproductdevelopmenteffortsareanattempttoimprovetheperformanceofabusinesscapabilityortodeliveranewbusinesscapability.Businesscapabilityanalysisistheanalysisoftheperformanceandriskassociatedwithasetofbusinesscapabilitiestoidentifyspecificperformancegapsandtoprioritizethesebasedonbusinessvalueandrisk.

.3 Elements

Capabilities

Capabilitiesaretheabilitiesinabusinesstoperformortransformsomething.Capabilitiesshoulddescribethepurposeoroutcomeoftheperformanceortransformation,nothowtheperformanceortransformationisperformed.Itdescribesthewhat,asopposedtothehow.Forexample,sendingafaxisnotacapability;notifyingthecustomeristhecapability.

Using Capabilities

AmodelofBusinessandCustomerValue:Businessvalueissomethingthatincreasesorprotectsrevenue,reducesorpreventscost,improvesservice,achievescompliance,orpositionsthecompanyforthefutureinalignmentwiththebusinessstrategy.Notallcapabilitieshavethesamelevelofvalue.Forexample,whiledistributingpayrolltoemployeesisimportanttoacompany,itislikelyneitherofhighbusinessnorcustomervalue.Inotherwords,thismaynotbeacapabilitythataddsvalueforthecompanytobuildandmaintaininternally.Therearevarioustoolsthatcanbeusedtomake

46 The Agile Extension to the BABOK® Guide

Page 55: The Agile Extension

Techniques See The Whole

businessandcustomervalueexplicitinacapabilityassessment.Inadditiontothesetools,balancedscorecardscanbeusedasamodelofbusinessvalue.

Performance Expectations

Sincecapabilitiesidentifytheabilitiesrequiredtoperformortransformsomething,capabilitiescanbeassessedtoidentifyexplicitperformanceexpectations.Whenacapabilityistargetedforimprovement,aspecificperformancegapcanbeidentified.Whiletheperformanceofeverycapabilitycanbeimproved,theperformancegapisthedifferencebetweenthecurrentperformanceandthedesiredperformancegiventhebusinessstrategy.

Risk Model

Risksintheperformanceofthecapabilityfallintothefollowingcategories:

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

Strategic Planning

Businesscapabilitiesforthecurrentstateandfuturestateofanorganizationcanbeusedtodeterminewherethatorganizationneedstogoinordertoaccomplishtheirbusinessstrategyandimperatives.Asaresultofperformingabusinesscapabilityassessment,thereisgenerallyasetofrecommendationsorproposalsforsolutionsthatneedtobeputinplace.Thisinformationformsthebasisofaproductroadmapandservesasaguideforreleaseplanning.

Capability Maps

Frequently,organizationsusecapabilitymapstoprovideagraphicviewofelementsinvolvedinbusinesscapabilityanalysis.Thefollowingillustrationdemonstratesoneelementofacapabilitymapthatwouldbepartofalargercapabilitiesgrid.

November2011DraftforPublicReview 47

Page 56: The Agile Extension

See The Whole Techniques

FIGURE 4.6 SampleCapabilityMap

.4 Usage Considerations

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

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

48 The Agile Extension to the BABOK® Guide

Page 57: The Agile Extension

Techniques See The Whole

Advantages• Theadvantagesofcapabilityanalysisarethattheyresultina

sharedarticulationofoutcomes,strategy,andperformance.Thesehelpcreateveryfocusedandalignedinitiatives.Themodelworksverywellwithagileteamsbutitalsohelpsidentifyopportunitiesthatarenottechnologybased,includingprocess,talent,anddataimprovements.

• Thecapabilityanalysishelpsaligntheseinitiativesacrossmultipleaspectsoftheorganization.

Disadvantages• Thismodelrequiresanorganizationtoagreetocollaborateon

thismodel.• Whenthismodeliscreatedunilaterallyorinavacuumitfailsto

deliveronthegoalsofalignmentandsharedunderstanding.• Themodelalsorequiresabroad,cross‐functionalcollaboration

indefiningthecapabilitymodelandthevalueframework.

Implications for Agile

Agilemethodologiescreateaframeworkthatfacilitatesfrequentre‐assessmentofbusinessneedsandvalue.Thedirectionofthebusinessandthegapsrequiredforthebusinesstomeetitsobjectivesmustberevisitedforeachreleaseplanningsession,whichgenerallyoccursevery2‐4weeksinmostagilelifecycles.Thismeansthatanagileprojectteammustmaintainaconstantviewofthebusinesscapabilitiesthatarerequiredforthebusinesstobesuccessful,particularlythosethatareinscopefortheproductbeingdelivered.

BusinessValue:SeeKano,PurposeAlignment,BalancedScorecard,Moscow.

4.1.2 Personas

.1 Purpose

Usercentereddesignpracticesoftenusepersonasasapowerfulandsimpletooltohelpdesignsoftwarethatuserswillenjoyandbenefitfrom.

November2011DraftforPublicReview 49

Page 58: The Agile Extension

See The Whole Techniques

.2 Description

Personasarefictionalcharactersorarchetypesthatexemplifythewaythattypicalusersinteractwithaproduct.Theyareoftenusedinagilemethodstounderstandvaluefromtheperspectiveofaparticularcustomerandallowateamthatmaynothavedirectaccesstoacustomerrepresentativetobetterunderstandtheirneeds.Workcanthenfocusonthefeaturesofgreatestvaluetoaparticularpersona.

.3 Elements

Apersonashouldbedescribedasthoughtheyarearealperson.Personasmayprovideaname,personality,family,workbackground,skilllevel,preferences,behaviorpatterns,andpersonalattitudes.Itisalsoagoodpracticetoincludeapictureandwriteashort“dayinthelife”narrativethathelpstheteamvisualizetheuser.

.4 Usage Considerations

Usepersonaswhenyouwanttogetadeeperunderstandingofkeystakeholdersthanonegenerallygetsfromatraditionalroleoractordescription.Personashelpdriveproductsthatarefitforpurposeandhighlyusable,becausetheyarepatternedafterthesubtlequalitiesofrealpeoplethatwillinteractwiththesystemsandhowtheydotheirjob.

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

Personasarethenrankedtoidentifyafewkeytargetsthatwillrealizethemostbenefitfromthesystemdesign.Whendesignconsiderationsaremade,theimpacttheywillhaveonthetargetedpersonasshouldbetakenintoconsideration.

“Afrequentmistakeistodesignforsomeonewhoisclosetotheproductbutisnottheactualuser…theITmanagerwhopurchasedtheproductwillrarelybetheonetoactuallyuseit.”(Cooper,1999)

50 The Agile Extension to the BABOK® Guide

Page 59: The Agile Extension

Techniques See The Whole

Advantages• Personashelpteammembersshareaspecific,consistent

understandingofvariousaudiencegroups.Dataaboutthegroupscanbeputinapropercontextandcanbeunderstoodandrememberedincoherentstories.

• Proposedsolutionscanbeguidedbyhowwelltheymeettheneedsofindividualuserpersonas.Featurescanbeprioritizedbasedonhowwelltheyaddresstheneedsofoneormorepersonas.

• Provideahuman“face”soastofocusempathyonthepersonsrepresentedbythedemographics.

Disadvantages

• Personasarefictionalsothereisoftenatendencytocreatepersonasthatembodytraitsthatarecommontomostusers,butindoingsocreatingagenericuserthatisnotdistinctorrealistic.Thiscanleadtosoftwarethatisdesignedtobeeverythingtoeveryone.

• Personasmaynotbeagoodsubstituteforarealuser,iftheyareavailable.Personascandistanceateamfromausercommunity.

4.1.3 Value Stream Mapping

.1 Purpose

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

.2 Description

Valuestreamrepresentstheflowofmaterialandinformationrequiredtobringaproductand/orservicefromrawmaterialtothecustomer.Valuestreammap(VSM)isagraphicalrepresentationthatcapturesasnapshotofthevaluestream.

Thetwomaintypesofvaluestreammapthatarewidelyusedare:

• CurrentStateValueStreamMap:Depictsavaluestreamasitisappliedbythosewhoareresponsibleforcarryingit.Itis

November2011DraftforPublicReview 51

Page 60: The Agile Extension

See The Whole Techniques

usuallyusedasastartingpointforanalysisofanexistingprocesstoidentifyimprovementopportunities.

• FutureStateValueStreamMap:Derivedfromthecurrentstateanditshowswhatthevaluestreamwilllooklikeaftertheimplementationoftheimprovements.

Inanagileenvironment,thisdiagramisusuallysimpleanddrawnonawhiteboard.Itcanbeusedtohelpre‐engineerbusinessprocessestooptimizeuseofsoftware.Itcanalsobeusedtore‐engineerandtunethesoftwaredevelopmentprocessitself,forexample,toreduceleadtimefromproductdiscovertorelease.

.3 Elements

Thefollowingisabroaddescriptionforoneapproachtobuildingavaluestreammap.

Prepare• Gathercross‐functionalteam.Intheagileworldthisshould

includepeoplewithbusinessdomainknowledgeandtechnicalteammembers(suchasdevelopers,testers,andarchitects).Oftensomeoneactingasthebusinessanalystwillfacilitatethesession.

• Assignavaluestreammapowner.Ideallythisissomeonewhohasadeepunderstandingofthecurrentprocess.

• Selectaproduct,aproductfamily,oraservice,anddefinethescopeofthevaluestreammap.

• Inthecontextofagileprojects,valuestreammappinglooksattheflowofinformationneededtocompleteabusinessprocessfromend‐to‐endandthehand‐offsbetweenrolesand/ororganizationalunitsinthatprocess.

Create Current State

Thecurrentvaluestreammapcanbecapturedfollowingthesesteps:

• Observeorsimulatevaluestream.Followaproduct(orproductfamily)pathbystartingattheendclosesttothecustomerandrecordtheprocessworkingyourwaybackwardstothebeginning.Simulatingthevaluestreamcanbedoneindifferentways.Teammembersmightstartwiththestepstheyareresponsiblefor,oritcanbeachievedinagroupworkshopwiththecrossfunctionalteam.

52 The Agile Extension to the BABOK® Guide

Page 61: The Agile Extension

Techniques See The Whole

• Drawthevaluestreammap.• Capturetheinformationflow.Theinformationthatisvitalfor

thevaluestreamtofunction.Informationflowincludes(butnotlimitedto)thingssuchasorders,schedules,inventorytime,changeovertime,cycletime,andnumberofoperatorsinvolved.

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

• Validatethevaluestreammap.Theinitialdraftofthecurrentvaluestreammapmustbevalidatedbeforeproceedingtotheimprovementphase.Teammemberscanusedirectobservationoftheworkplaceforthispurpose.

Analyze Current State

ThecurrentvaluestreammapcanbeanalyzedasdescribedinRootCauseanalysisoftheBABOK®Guide(9.25RootCauseAnalysis)toidentifyvalueaddedsteps(suchastransformationprocesses)fromthosethatarenon‐valueadded(suchasexcessiveinventories).

Thenon‐valueaddedstepscanbeanalyzedfurthertodeterminewhichonesarenecessary(suchasmeetingregulatoryrequirements)andwhichonesareunnecessary(suchasexcessivepaperwork).

Create Future State

Thefuturestatevaluestreammapcanbedrawnasfollows:

• Identifyimprovementareas.Unnecessarynon‐valueaddedstepsarethesourceofwasteand,assuch,theycanbeeliminated.Teammemberscanmarktheseareas(suchasreducingleadtime)onthecurrentvaluestreammap.

• Capturethefuturestatevaluestreammap.Drawthevaluestreammapthatshowswhatthevaluestreamwilllooklikeafteryouhaveeliminatedthewaste(unnecessarywaittime,excessiveadministrativepaperwork,highinventories).

Oncethefuturestateiscaptureditwillbeusedasthetargetstateoftheimprovementinitiative.

November2011DraftforPublicReview 53

Page 62: The Agile Extension

See The Whole Techniques

Implement Process Improvement • Identifysupportingmaterialrequiredforimplementingthe

improvementsuchastrainingandchangeover.• Implementtheimprovementfollowingoneofthewell‐known

businessprocessmethodologiessuchas,butnotlimitedto,LeanorSixSigma.

Inanagileproject,valuestreammappingwillbemostutilizedwhenimplementingprocessimprovement.Oftenthechangestobemadeinthebusinessprocesswillrequirechangestoorimplementationofsupportingsoftwareproducts.Therequirementsforthesechangesorenhancementsbecomebacklogitemsthatfeedintoanagileinitiative.

Oncetheimprovementismade,thefuturestatebecomesthecurrentvaluestreammapanditcanbeusedasastartingpointforanotherimprovementcycle.

Thefollowingisanexampleofavaluestreammap.

FIGURE 4.7 ValueStreamMap

54 The Agile Extension to the BABOK® Guide

Page 63: The Agile Extension

Techniques Think as a Customer

.4 Usage Considerations

Advantages• Morecomprehensivethanaprocessflowdiagram.• Providesablueprintforimplementingimprovement.• Establishesasharedunderstandingofprocesswastesand

bottlenecks.• Providesacommonvisuallanguagefordiversestakeholders.

Disadvantages• Noteasytoconstructincomparisonwithothervisualmodeling

techniques.• Canlookdauntingbecauseofalltheinformationcaptured.• Mappingparalysis.Itiseasytogetcaughtmakingthevalue

streammapcompleteandperfectinsteadofproceedingtotheimprovementstage.

• Doesn’tworkwellinknowledgebasedornon‐linearwork.• Leadstodisruptiveor“re‐engineering”approach.Doesn’twork

wellwithongoingimprovementefforts.

4.1 Think as a Customer

Thinkinglikeacustomerisakeycomponentofagilebusinessanalysis.Thecustomeristhepersonwhogetsvaluefromtheproductwearebuilding.Westartwithahighlevelviewofcustomergoalsandprogressivelydecomposetheseintoamoreandmoredetailedunderstandingofthespecificneedsthattheproductmustmeet.

Agileprocessesincorporatefeedbackloopstocontinuouslyvalidatethisunderstanding.Asproductdeliveryprogresses,thecustomerandteamunderstandingoftheneedswillevolve,itisimportantthatthesechangesinfluenceanddefinetheworkoftheteamgoingforward.

Agileanalysisslicesthedeliveryintothesmallestpracticalincrementsthatdeliverbusinessvalueoverthelifeoftheproject.

Itisimportantthatagileanalysisstartwithaholisticperspective,inordertohelptheteamunderstandtheoverallproductthatneedstobedelivered.Theteamcollaborateswiththecustomertoconsidertheuserexperienceexpected.

November2011DraftforPublicReview 55

Page 64: The Agile Extension

Think as a Customer Techniques

Agoalofanalysistoensurethevoiceofthecustomer,especiallytheend‐user,iselicitedandexpressedintheproduct.

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

Thefollowingsectionsdescribecommonlyusedtechniques.

Thetechniqueslistedbelowarebasedonuserstories:

• Story Decomposition• Story Elaboration• Story Mapping• User Story

Atechniqueforprototypingauserinterfaceandusingthattodefinedetailedrequirementsis

• Storyboarding

4.1.1 Story Decomposition

.1 Purpose

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

Thistechniqueprovidesastructurefordefiningthevariouselementsofrequirementsatprogressivelysmallerlevelsofgranularity,startingwiththebroadsystemcontextanddrillingdowninmultiplelevelstoeventuallydefinethedetailedacceptancecriteriaforindividualuserstories.

.2 Description

Themostcommonagileapproachtostorydecompositioncanbedescribedas“breadth‐before‐depth”:startwithaveryhighlevelpictureofwhatbusinessgoalsneedtobeachieved,decomposethose

56 The Agile Extension to the BABOK® Guide

Page 65: The Agile Extension

Techniques Think as a Customer

intosmallercomponentsthatprovideincrementsofvaluablefunctionality(sometimescalledminimallymarketablefeaturesetsorMMFs),splitthecomponentsintouserstories,andeventuallyelaboratetheuserstorieswithacceptancecriteria,see“StoryElaboration”onpage59.Astorythatistoolargeorinsufficientlyunderstoodtoelaborate,estimate,ordeliverasastoryissometimescalledanepic.Epics,whenused,arelaterdecomposedintosmallerstories.

FIGURE 4.8 StoryDecomposition

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

November2011DraftforPublicReview 57

Page 66: The Agile Extension

Think as a Customer Techniques

Thefollowingtabledescribesthedifferentlevelsofstorydecomposition.

TABLE 4.4 Story Decomposition

.3 Usage Considerations

StoryDecompositionisundertakenprogressively.Oneofthemostsignificantdifferencesbetweenagileprojectsandwaterfallprojectsisinthedefinitionofdetailedrequirements.Inagileprojects,theinitialanalysisactivitieswillidentifythegoals,MMFs,andmostoftheepics.Theinitialsetofuserstories(probablyforthefirstreleaseoftheproduct)willbedoneintheprojectinitiationactivities.Thereisaclearunderstandingthatthesestoriesarelikelytochangeandthattheteams’understandingoftherequirementswillevolveovertime.Therefore,decomposingtothelowestlevelofdetailislikelytobeawastefulactivityearlyintheproject.

Advantages• Thisdecompositiontechniquehelpsavoidthecommon

problemofgettinglostinthedetailoftheuserstoriesandlosingthebig‐picturecontext.

• Itisimportantthatteammemberskeeptheproject’sgoalsandobjectivesinmind,andwhileusingthedecompositionapproachtheyareabletotraceimplementedorrequestedfunctionalitybacktothedrivingbusinessobjectives.

Level Description System Goals The system goals are the highest level of business requirements.  They

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

MMF/Component MMF stands for Minimum Marketable Feature. These are logical groupings of functionality and capabilities the delivered product needs to provide to be worth releasing. Often these will form the “themes” for a single release and serve to provide a big-picture context for the product being developed.

Epic A piece of functionality that enables a user to achieve a clearly identified business objective. Often epics are at the level of elementary business processes---a piece of work undertaken by one person, at one time, in one place that delivers on a specific operational objective. 

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

Acceptance Criteria

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

58 The Agile Extension to the BABOK® Guide

Page 67: The Agile Extension

Techniques Think as a Customer

• BreakingtheproductintoMMFsandepicshelpswithrelease‐levelplanning,providesvisibilityintothedevelopmentproject,andhelpscoordinateexternalprogramactivitiessuchasorganizationalchangemanagementandusertraining.

Disadvantages

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

4.1.2 Story Elaboration

.1 Purpose

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

.2 Description

Storyelaborationisthelowestlevelofstorydecompositionandtheprocessbywhichthestorysentenceisintobrokendownintopiecesofwork.Thisisoftendonebysomeoneontheteamwhohasstrongbusinessanalysisskills,particularlywithfacilitationandcommunication.Storyelaborationisthetechniquethroughwhichdetailedrequirementsareelicitedandcommunicatedtotheprojectteam.

Duringeachrelease(iteration/sprint),theteamthatworksonastoryschedulestimetoexpandonthestorytounderstandthedetail.Often(butnotalways)thisiscompletedinashortworkshopwiththeprogrammerswhowillworkonthestory,thebusinessSME/customerwhoneedsthestory,thepersonwhowilltestthestory,andsomeoneactingasabusinessanalysttofacilitateandchallengethestory.Typically,storyelaborationisundertakenafewdaysaheadofthedevelopmentofthestory.

Storyelaborationisacommunicationtechniquethathelpsensurethecorrectproductisbuilt.Inanagileproject,thedetailedrequirementsareproducedbystoryelaboration.However,asopposedtowaterfallapproaches,andconsistentwiththejust‐in‐timephilosophyofagile,

November2011DraftforPublicReview 59

Page 68: The Agile Extension

Think as a Customer Techniques

thedetailedrequirementsdefinedduringstoryelaborationcontainonlytherequirementdetailsforthepieceofworkthatistobecompletedinthecomingrelease.

.3 Elements

Theresultofstoryelaborationisasharedunderstandingamongtheparticipantsofwhatthestorymeansandwhatshouldbedeliveredtoachievethe“Done”stateforthisstory.Theroleofthebusinessanalystindevelopingandcommunicatingdynamicrequirementsnecessitatesahighdegreeofskillinbothfacilitationandcommunication.

Theoutputsofeffectivestoryelaborationdescribeand/ordocumentthetasksthatenabletheteamtosuccessfuldelivertheupcomingiteration.Theseoutputsmayinclude

• detailedrequirementsfortheupcomingrelease,• taskdefinitionsandbreakdowns,• examplesandscenariosthatexplainthecustomer'sintentfor

thestory,• low‐fidelitymodelsthatclarifythetechnicalorprocessdesign

(forexample,datamodels,dataflowdiagrams),• screenorreportmock‐ups,• acceptancecriteria(testdesignspecifications)toclarifyhow

thestorywillbetested,ofteninthe<given><when><then>formatofbehaviordrivendevelopment,and

• otherartifactsthatwillbeusefulinthedevelopmentandtestingofthisstory.

.4 Usage Considerations

Advantages• Themajoradvantageofstoryelaborationisthatitavoids

wastefulrequirementselicitation,andpotentiallydocumentationaswell.Byelaboratingonrequirementsonlyastheyareneeded,theteamavoidstheworkofelicitingrequirementsforfeaturesthatmayneverbebuiltorthatwillneedtobechangedbythetimetheyarereadyforimplementation.

60 The Agile Extension to the BABOK® Guide

Page 69: The Agile Extension

Techniques Think as a Customer

Disadvantages• Forthosewhoarerelativelynewtoagilemethodologies,itcan

bedifficulttodeterminethebesttimingforconductastoryelaboration.Ifconductedtooearly,theinformationmaynolongerbecorrectforthegivenreleaseandwillneedtobere‐elicited.However,whencollectedtoolate,itcandelayprojectteamprogressiontodevelopment.

• Anotherchallengetoimplementingstoryelaborationistheabilitytoelicittheappropriatelevelofdetailsuchthattherequirementscanbedeveloped,tested,andcomparedtoacceptancecriteria.

Timing

Storyelaborationshouldbedoneonanas‐needed,just‐in‐timebasisforstoriesthathavebeendeterminedtobeinscopefortheupcomingrelease.Theprojectteamshouldnotinvestigatestoriesforfurtherelaborationiftheyhavenotbeenplannedforthereleaseinquestion,astheinformationcollectedmaybestaleandoutofdate.

4.1.3 Story Mapping

.1 Purpose

Storymappingprovidesavisualandphysicalviewofthesequenceofactivitiestobesupportedbyasolution.Itusesatwo‐dimensionalgridstructuretoshowsequenceandgroupingsofkeyaspectsoftheproductonthehorizontaldimension,withdetailandpriorityofstoriesontheverticaldimension.

.2 Description

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

Astorymapisdesignedtobeaninformationradiator,usedtovisualizeaproduct'srequestsinthecontextofusageandpriority.Thestorymapisoftenplacedondisplayfortheprojectteamduringreleaseplanningsessions.Byanalyzingthestorymap,theteamcanmorereadilyidentifydependenciesgeneratedasaresultofthe

November2011DraftforPublicReview 61

Page 70: The Agile Extension

Think as a Customer Techniques

intendedflowthroughtheuserstories.Themapcanalsobeusedforriskassessmentandmanagementbyexamininghowthestorieswillneedtoworktogetherinthecontextofdeliveringbusinessvalue.

Thefollowingillustrationisanexampleofastorymap.

FIGURE 4.9 StoryMap

.3 Elements

Thestorymaphasacentralbackboneofelementsthatwillmakeuptheproduct.Abovethisbackbonearethelargefeaturesets(activities)thatneedtobedeliveredoverthelifeoftheproject.Thebackboneisasequentialsetofoperator/customertasksthatneedtobeenabledbythesoftware.Belowthebackbonearethedetailedstoriesthatimplementthespecificpiecesoffunctionalitytoenablethetaskstobeaccomplished.

Process

Theprocessofbuildingastorymapcanbedescribedasaseriesofsteps.

1. Identifythekeyactivitiestheproductmustsupport,writingeachactivityonaseparatecardoradhesivenote.Useonecolorfortheactivitycards.

62 The Agile Extension to the BABOK® Guide

Page 71: The Agile Extension

Techniques Think as a Customer

2. Sequencetheseinorderofusage,fromlefttoright.Whilethesequenceinwhichactivitieswillbeperformedwillvary,therewillbeacommon“day‐in‐the‐life‐of”sequencewhichcanbeused.Theseactivitieswillnormallybetoolargetoimplementinasingledevelopmentiteration.

3. Oncetheactivitiesareinalogicalorder,definetheindividualtasksthatmakeuptheactivities.Thesetasksshouldbeadiscretepieceofworkforsomeoneoperatingtheproduct.Writeeachtaskonasepa‐ratecardoradhesivenote,usingadifferentcolorfromtheactivities.

4. Placethetasksonasinglerowinlogical,sequentialorderunder‐neaththeactivities.Again,therewilloftennotbeastrictsequencewhichmustbefollowedeverytime,buttherewillbeacommonlog‐icalorderinwhichtasksaredone.Thisisthesequenceofthetasksonthemap.

5. Validatetheactivitiesandtaskswithdomainexpertsandotherstakeholders.Askthequestion:dotheyconstituteacompletepic‐tureofwhattheproductneedstodeliver?Updateandamendtheactivitiesandtasksasneeded.

6. Addsub‐tasksbelowthetasks,againusingadifferentcolorcardoradhesivenote.Thesewilloftencoverthealternativewaysofunder‐takingataskordealwithexceptionsorpotentialproblemswhenperformingatask.Addthesebelowthetaskinatop‐to‐bottomlogi‐calorderbasedonuserpriority.Thesesub‐tasksareattheleveloftheuserstoryandtherewillbemanyofthem.Viewingthetoprowofsub‐tasksacrossthemapprovidesaviewofthelikelyminimumviableproduct,thesetoffeatureswhichmustbedeliveredfortheproducttohaveanyvalueatalltothebusiness.Thishorizontalviewoftheuserstoriesprovidesalogicalstartingpointforreleaseanditerationplanning,asthevertIcalpositionofauserstoryshowsitsrelativepriorityintheoverallpicture.

7. Validatethestorymapwithstakeholdersandupdateitasneeded.8. Keepthestorymaptogethertoprovideabig‐pictureviewofthecompleteproduct.Indicatewhenstoriesarecompletedonthestorymapsooverallprogressisclearlyvisible.

.4 Usage Considerations

Advantages• Whenthelargercontextofaproductisnotaccountedfor,agile

projectscanbesubjecttogettingmiredinthedetailswithaninabilitytoeffectivelystringcomponentstogethertocreateend‐to‐endbusinessvalue.Storymappinghelpsavoidthe

November2011DraftforPublicReview 63

Page 72: The Agile Extension

Think as a Customer Techniques

commonproblemofgettinglostinthedetailoftheuserstoriesandtheriskoflosingthebig‐picturecontext.

Disadvantages• Storymappingcanbecomecumbersomewheretheproductis

verylargeandmayrequirebuildinganumberofstorymapsthatcoveralargeprogramofwork.Whilestorymapsillustrateaflow,theydonotanalyzeorillustratedependenciesbetweenrequirements(thoughtheycanbeusedtohelpfacilitatethatanalysis).

4.1.4 User Story

UserStoriesaredescribedindetailintheBABOK®Guide(9.33UserStories).Thisinformationfoundherereflectsandexpandsonthatinformationinthecontextofagiledevelopmentmethodologies.

.1 Purpose

Auserstoryrepresentsasmall,concisestatementoffunctionalityneededtodelivervaluetoaspecificstakeholder.

Userstoriescanbeused:

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

.2 Description

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

64 The Agile Extension to the BABOK® Guide

Page 73: The Agile Extension

Techniques Think as a Customer

indexcardorstickynote.Storiesmayalsoberecordedinanelectronicsystem.

Userstoriescapturestakeholderneedsusingshort,simpledocumentationandinviteexplorationoftherequirementsthroughconversations,tests,and/orsupplementalrequirementsrepresentations,asneeded.Theyareconciseandeasytochangeasstakeholderneedsarebetterunderstoodorasthoseneedsevolve.

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

.3 Elements

Title (optional)

Thetitleofthestorydescribesanactivitythattheuserwantstocarryoutwiththesystem.Typically,itisanactive‐verbgoalphrase,similartothewayusecasesaretitled.

Description

Thereisnomandatorystructureforuserstories,however,themostpopularformatincludesthreecomponents:

• auserroleorpersona[WHO],• anecessaryaction,behaviour,orfeature[WHAT],and• thebenefitorbusinessvaluereceivedbytheuserwhenthe

storyisimplemented[WHY].

Usageexample:

“Asa<role>,Ineedto<behavior>sothat<businessvalue>”

Analternativeformat,preferredbythosewhopracticebusinessanalysisinAgiledevelopmentis:

“Inorderto<businessvalue>,asa<role>,Ineedto<behavior>

Thiscanonicalformatcanalsobeusedforstoriesprovidedfromotherproductorprojectconstituents.Forexample:

November2011DraftforPublicReview 65

Page 74: The Agile Extension

Think as a Customer Techniques

“AsaSecurityOfficer,IneedtoonlyallowauthorizeduserstoaccessthexyzfunctionalitysoIcaninsureweenforceabcsecuritydirective”.

Conversation

Userstoriesserveasareminderthattheteamneedstoexploreandunderstandthefeaturedescribedinthestoryandthevaluethatitwilldelivertothecustomer.Thestoryitselfdoesn'tcaptureeverythingthereistoknowaboutthecustomerneed,andtheinformationinthestorywillbesupplementedbyfurthermodelingasthestoryisdelivered.

Acceptance Criteria

Whenauserstoryiswelldefinedandunderstood,itisaccompaniedbyacceptancecriteria.Acceptancecriteriadefinetheboundariesofauserstoryandhelpproductowners,customers,orbusinessanalyststoanswerwhattheyneedtoprovidevaluewiththeproduct.

Acceptancecriteriahelpdevelopersidentifywhentostopaddingmorefunctionalityandtoderivetestsforverificationandvalidationpurposes.Acceptancecriteriaaretypicallyaddedjustbeforeplanningorjustintimeduringdevelopment.Theycanalsobedevelopedasastorybecomeswellunderstoodtoenablethedevelopmentteamtoverifythatthesolutionwillmeettheuser’sneeds.

Acceptancecriteriaareoftenbuiltshortlypriortoorinparallelwiththeimplementationoftheuserstory.

.4 Usage Considerations

Advantages• Tiedtosmall,implementable,andtestableslicesof

functionalityfacilitatingrapiddeliveryandfrequentcustomerfeedback.

• Easilyunderstandablebystakeholders.• Canbedevelopedthroughavarietyofelicitationtechniques,

includingbutnotlimitedtofacilitatedworkshops,contextualinquiry,andotherethnographicelicitationtechniques.

• Userstoriesaresimpleenoughthatpeoplecanlearntowritetheminafewminutes,beingcarefulaboutalwaysdeliverbusinessvalue.

66 The Agile Extension to the BABOK® Guide

Page 75: The Agile Extension

Techniques Think as a Customer

• Theprocessofcollaboratingondefiningandexploringstoriesbuildsteamcommitmentandsharedunderstandingofthebusinessdomain.

• Storiesinviteconversationforfurtherdecompositionandexploration.

Disadvantages• Thisconversationalapproachcanchallengetheteam,since

theydonothavealltheanswersanddetailedspecificationsupfront.

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

• Large,chunkystories(epics)canbevagueanddifficulttousewithoutbreakingthemdownintosmallstories.

• Storiesspawnmorestoriesviadecompositionsotheinformationmustbeorganizedtoensureitiscurrentandrelevant(calledpruningorgrooming).

• Thecollectionofstoriesneedstobemanaged(forexample,withbacklogmanagement).

• Storiesrequirecontextorline‐of‐sight.Iftheteamdoesn’ttracestoriesback(throughvalidation)orsupplementthemwithhigher‐levelanalysisandvisionartifacts,thentheteamcanlosesightofthebigpicture.

• Somepractitionerscanbeconfusedamongstuserstories,usecase,andstoriestechniques.

4.1.5 Storyboarding

.1 Purpose

Storyboardingisusedinconjunctionwithothertechniquessuchasusecases,userstories,andprototypingtodetailvisuallyandtextuallythekeyeventssummingupdifferentinteractionsofuserswiththesystemorbusiness.

Storyboardingserves

• toelicit,elaborate,organizeandvalidatetherequirements,• tocommunicatetodeveloperswhatneedstobebuilt,

November2011DraftforPublicReview 67

Page 76: The Agile Extension

Think as a Customer Techniques

• toshowdifferentvariationsoftheproposedsolution,and• asaninputtotests.

.2 Description

Storyboards(alsoknownasdialogmap,dialoghierarchy,ornavigationflow)userepresentativeimagesandtexttodescribeatask,ascenario,orastory.Itcanalsobeusedwithprototypingtechniquetorepresentpartsofthesystemthatarewellunderstoodorexpensiveandunnecessarytoproduceviaformalprototypes.

Whenusedtodescribetheinteractionwiththesystem,thestoryboardshowshowscreenswilllookandhowtheywillflowfromonetoanother.Whenusedtodescribebusinessorganization,thestoryboardshowstheinteractionwithabusinessprocesssuchasbackoffice.

Storyboardscanbedevelopedusingwhite‐boardsandstickynotesorusingCASEtools.

Storyboardsarecommoninmanyanalysisanddevelopmentmethodologies,andareaformofprototyping(seetheBABOKGuide,9.22Prototyping).However,asagilemethodsfavourthedevelopmentofworking,usablesoftwareoverthrowawayprototypes,storyboardingisausefultoolforunderstandinghowpeoplewillactuallyusethesystem.

.3 Elements

Storyboardscanbecreatedinaworkshopenvironmentwithrelevantstakeholders.

Preparation

1.Identifymainscenarioswithinthescopeoftheproject.Thiscanbedrivenfromusecasesoruserstoriesorcanbeidentifiedinacustomervisitoraninformation‐gatheringsessionwithexperts.

2.Selectthescenariosthatneedtohaveastoryboarddeveloped.Whilesomescenariosneedtobedetailedinastoryboard,othersareobviousandcanbeomittedsuchasalternatescenariosandexceptions.

3.Identifyparticipantsandschedulethesession.

68 The Agile Extension to the BABOK® Guide

Page 77: The Agile Extension

Techniques Think as a Customer

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

Session

1.Haveattendeescreateillustrationsforthestoryboardsoftheselectedscenarios.

2.Enhancestoryboardillustrationswithtextualinformationsuchasoptionalinteractions,unavailableinteractions,furtherstakeholderrequestsnotassociatedwiththeprimaryscenario,andgeneralnotesassociatedwithaspecificstep.

3.Makesureeachstoryboardstandsonitsownbyaddingrequiredexplanationsastext.

Wrap up• Attheendofthesession,thebusinessanalystreaches

consensusonthehighlevelflowofthedevelopedstoryboards.

Aftertheworkshop,thebusinessanalystmightusecompanytemplatestoformallydocumenttheoutcomeofthesession,addingadditionalelementstothestoryboardssuchasstoryboardidentification,description,user,trigger,input,output,andissues.ThebusinessanalystmayalsouseCASEtoolstocreaterepresentativescreensthatwillbeusedforlatervalidation.

.4 Usage Considerations

Advantages• Intheearlystagesoftherequirementsgatheringprocess,

storyboardingcansignificantlyreduceabstractnessbroughtbyothertechniquessuchasusecasesanduserstories.

• Storyboardscanbeproducedquicklyandataverylowcostcomparedtoothertechniquessuchasprototypes.

• Theintuitivenatureofthestoryboardencouragesstakeholderparticipation.

Disadvantages• Differentlookandfeelthanthefinalproduct.• Easytogetboggeddownonhow,ratherthanwhy.

November2011DraftforPublicReview 69

Page 78: The Agile Extension

Analyze to Determine What is Valuable Techniques

4.1 Analyze to Determine What is Valuable

Theagileapproachisdistinctinthatvalueiscontinuouslyassessedandprioritizedtoensurethatthemostvaluableworkisdeliveredatanypointintime,alwaysusingtheendcustomerperspective.Itisalsoimperativetoquestionthepurposebehindrequirements,challengingthoserequirementsthatdonotsupportthebusinessgoals.Agilepracticesenabletheartofmaximizingtheamountofworknotdone,somethingessentialtodelivervaluablesoftwareearlyandcontinuously.Thetechniquesoutlinedinthissectionfacilitatethevaluationofproductneedsonanon‐goingbasis.

Thefollowingsectionsdescribecommonlyusedtechniques.

• Backlog Management• Business Value Definition• Kano Analysis• MoSCoW Prioritization• Purpose Alignment Model

4.1.1 Backlog Management

.1 Purpose

Thebacklogisawishlistofrequestsforfeaturestobeincludedinaproduct,andisthemainmechanismformanagingrequirementsonanagileproject.

.2 Description

Theproductbacklog,whichderivedfromtheScrumframeworkisleveragedinmanyblendedagilemethodologies,isestablishedatthebeginningofaproject.Thebacklogisafluiddocumentthatevolvesoverthecourseoftheprojectasmoreislearnedabouttheproductanditscustomers.Theproductownerisresponsiblefororderingtheitemsonthebacklogbasedonbusinessvalue,featureimportance,orotherrelevantcriteria.Whenmanagingabacklog,itemsshouldbeorderedsuchthatthemostimportantitemsoccuratthetopofthelistandareorderedbasedondescendingpriority.InXP,thebacklogoffeaturerequestsmaybemanagedasalogofuserstories.Abusinessanalystmayactastheproductownerorsupporttheproductownerrole.

70 The Agile Extension to the BABOK® Guide

Page 79: The Agile Extension

Techniques Analyze to Determine What is Valuable

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

Thebacklogissometimesreferredtoasaportfolioofoptionsthatthebusinesscaninvestin.Othertermsusedaremasterstorylistandprioritizedfeaturelist.

.3 Elements

Items in the Backlog

Thebacklogcancontainuserstories,usecases,features,functionalrequirements,aswellasitemsthathavebeenaddedbytheteamtosupportdevelopmentoftherequirements,suchastechnicalinfrastructure.Toaidinorderingthebacklog,itemsshouldbeexpressedinsuchawaythatthebusinessvalueoftheitemsisclear.Productriskmitigationitemsmayalsogetaddedtothebacklogasstoriesorpiecesofworktobedone.

Appropriate level of detail

Itemswithhighorderinthebacklogwillbedevelopedinnear‐termreleases,sotheyneedtobedetailedenoughtoallowthedevelopmentteamtoestimatethemwithaccuracyandbeabletodecomposethemintothetasksneededtodevelopthem.Itemswithlowerprioritycanremainhigh‐levelandlesspreciseuntiltheyriseintheorderandneedtobespecifiedinmoredetail.Largeitemsinthebacklogaresometimesreferredtoasepicsorbusinessvalueincrements,andmaybebrokendownintomultiple,moregranularitemsasthebacklogiselaboratedviastorydecomposition.Someaspectsofthestorymaybeimportantnear‐termandotherslessimportant.Thisabilitytobreakstoriesdowninthebackloghelpsprotecttherateofvaluedelivery.Forexample,addinganewfeaturemayhaveinvolvedhard‐codingsomethingupfrontandaddinganewstorytothebacklogtoaddsomedynamicconfigurationabilitytotheproductlater.

Estimation Accuracy

Itemswithhighorderinthebacklogneedtobeestimatedwithenoughaccuracytousethemforplanningreleases.Itemsinlowerorderalso

November2011DraftforPublicReview 71

Page 80: The Agile Extension

Analyze to Determine What is Valuable Techniques

needtobeestimated,butwithlessaccuracysincetheyareoftenlessdetailed.Estimatesfortimetocompleteitemsisoftenmaintainwithinthebacklogitself.

Prioritization

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

Managing Changes to the Product Backlog

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

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

.4 Usage Considerations

Advantages

• Sincetherequirementsonthebacklogareorderedinimportance,theteamknowsthatwhattheyareworkingonina

72 The Agile Extension to the BABOK® Guide

Page 81: The Agile Extension

Techniques Analyze to Determine What is Valuable

giveniterationishighpriorityandwillcontributebusinessvaluetotheproduct.Thepersonontheteamresponsiblefordetailingtherequirementscanreviewthebackloganddetermineiftheitemsthatwillbedevelopedinanupcomingreleaserequirefurtheranalysisinordertoreadythemfordevelopment.Thisprocessisreferredtoasbuildingtherequirementsrunway.

• Sinceeachreleasetypicallyimplementsasmallsetofrequirements,requirementsareanalyzedindetailonajust‐in‐timebasis.Whattheteamandthestakeholderslearnabouttherequirementsdevelopedduringareleasecaninformtheanalysisofotherrequirementsinupcomingiterations.

Disadvantages• Largebacklogsmaybecomecumbersomeanddifficultto

manage.Breakingtheoverallproductbacklogintobacklogsforreleases(calledreleasebacklogs)canhelpaddressthisdisadvantage.Also,alackofdetailinthestoriesinthebacklogcanresultinlostinformationovertime.

Timing

Thebacklogisdevelopedatthebeginningofanagileproject,butitdoesnotneedtobecompleteatthistimesinceitwillcontinuetoevolvethroughouttheproject.

4.1.2 Business Value Definition

Inorderforaprojecttodelivervalue,theymustfirstbeabletoidentifywhetherarequestisactuallyvaluabletotheorganization.Withoutaclearunderstandingofbusinessvalue,itispossiblefortheprojecttodeliversomethingthatsoundsvaluablebutisactuallynot.

Aprojectcreatesbusinessvaluewhenitdeliversanythingthatcontributestoanorganization'sstatedprimarygoals,forexample

• increasingorprotectingrevenue,• reducingoravoidingcosts,• improvingservice,• meetingregulatoryorsocialobligations,• implementingamarketingstrategy,and• developingstaff.

November2011DraftforPublicReview 73

Page 82: The Agile Extension

Analyze to Determine What is Valuable Techniques

Oftenprojectscreateoptionsforthebusinesstoexploit.Forexample,theoptiontosell1000itemsofaproductaday.

Businessvalueshouldbeexpressedintheformofamodelratherthananabsoluteamount.Theevolutionofthebusinessvaluemodelwilldevelopunderstandingofwhytheprojectisneeded.Themostimportantaspectofdevelopingabusinessvaluemodelistheconversationthatgeneratesthesharedunderstanding,ratherthanthemodelandthenumbersthatthemodelproduces.

Examplesofbadbusinessvaluestatementsare:

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

Noneoftheseshowalignmentwiththegoalsoftheorganization.

Anexampleofagoodbusinessvaluestatementis:

Thisprojectwillgenerateanadditional$20millioninprofit.Themodelisbasedonthefollowingassumptions:

• Wemaintain25%ofthesalesofexistingproductXYZ($150millionayear).

• Thetotalcostofdesigning,producing,andmarketingtheproductis$7.5million.

• Ourproductisfirsttomarket.• Weareabletoreleasetheproductinthespring.

Thisstatement,inmodelform,conveysunderstandingofwhytheprojectisneededandwouldlikelypromotevaluableconversationthatgeneratesasharedunderstandingoftheproject.

4.1.3 Kano Analysis

.1 Purpose

Kanoanalysishelpsanagileteamunderstandwhichproductcharacteristicsorqualitieswillprovetobeasignificantdifferentiatorinthemarketplaceandhelptodrivecustomersatisfaction.

74 The Agile Extension to the BABOK® Guide

Page 83: The Agile Extension

Techniques Analyze to Determine What is Valuable

.2 Description

Kanoanalysisismostusefulinhelpingtosupportagiledevelopmentforcommercialproducts.Itassistsinidentifyingfeaturesthatwillhavethegreatestimpactoncustomersatisfaction,eitherbecausetheyareexceptionallyimportantorbecausetheirabsencewillcauseintensedissatisfaction.Thishelpstheteamdeterminewhichfeaturesaremostimportanttoimplementbeforereleasingaproducttomarket.

Kanoanalysisratesproductcharacteristicsontwoaxes:

• theextenttowhichthefeatureisimplementedintheproduct,and

• thelevelofcustomersatisfactionthatwillresultfromanygivenimplementationlevel.

Theresultinggraphisplottedona2×2matrix.Basedontheresultingprofile,theproductcharacteristicshouldfallintooneofthreecategories:

• thresholdcharacteristics,• performancecharacteristics,and• excitementcharacteristics.

Thisanalysiscanthenbeusedtotryandidentifycharacteristicsthatwillgivetheproductauniquepositioninthemarketplace.

.3 Elements

Threshold Characteristics

Thresholdcharacteristicsarethosethatareabsolutelynecessaryforstakeholderstoconsideradoptingaproduct.Theirabsencewillcauseintensedissatisfactionbut,astheyrepresentminimumacceptancecriteria,theirpresencewillnotincreasecustomersatisfactionbeyondacertainlowlevel.Thechallengewithelicitingrequirementsforthesefeaturesisthatpeopleexpectthemtobepresentandsotendnottothinkaboutthemunlessexplicitlyasked.

Performance Characteristics

Performancecharacteristicsarethoseforwhichincreasesinthedeliveryofthecharacteristicproduceafairlylinearincreasein

November2011DraftforPublicReview 75

Page 84: The Agile Extension

Analyze to Determine What is Valuable Techniques

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

Excitement Characteristics

Excitementcharacteristicsarethosethatsignificantlyexceedcustomerexpectationsorrepresentthingsthatthecustomerdidnotrecognizewerepossible.Theirpresencewilldramaticallyincreasecustomersatisfactionovertime.Asthesecharacteristicsarenotmetbyanythingcurrentlyonthemarket,stakeholderswillnottendtothinkaboutrequirementsthatdescribethem.

.4 Usage Considerations

Inordertodeterminethecategorytowhichacharacteristicorfeaturebelongs,customerscanbesurveyedusingtwoformsofaquestionaboutthefeature:thefunctionalformandthedysfunctionalform.

Functionalform:Howdoyoufeelifthisfeatureorcharacteristicispresentintheproduct?

Dysfunctionalform:Howdoyoufeelifthisfeatureorcharacteristicisabsentintheproduct?

Possibleanswerstoeachquestionformare:

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

Determiningthecategoryisbasedonmappingtheanswerstobothformsofthequestiontothefollowinggrid.Thetoprowrepresentstheanswerstothedysfunctionalformofthequestion.Theleftcolumnrepresentstheanswerstothefunctionalformofthequestion.

76 The Agile Extension to the BABOK® Guide

Page 85: The Agile Extension

Techniques Analyze to Determine What is Valuable

TABLE 4.5 Kano Analysis Questions Grid

E=Exciters

P=Performance

T=Threshold

I=Indifferent(Doesnotfitintooneofthe3categories)

QorR=QuestionableorReversed(theanswerdoesn'tmakesense)

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

4.1.4 MoSCoW Prioritization

.1 Purpose

Toidentifythemostcriticalsetoffeaturesorstoriesthatwilldeliverbusinessvalue.

.2 Description

MoSCoWisamethodtoprioritizestoriesinincrementalanditerativemethodsandisdescribedintheBABOK®Guide(6.1PrioritizeRequirements).MoSCoWprovidesawaytoreachacommonunderstandingonrelativeimportanceofdeliveringastory.Allstories

Like Expect Neutral Live With Dislike

Like Q E E E P

Expect R I I I T

Neutral R I I I T

Live With R I I I T

Dislike R R R R Q

November2011DraftforPublicReview 77

Page 86: The Agile Extension

Analyze to Determine What is Valuable Techniques

inthebacklogarevaluable,butoftennotallofthemcanbedeliveredatthesametime.MoSCoWprovidesamechanismforprioritizingstoriesinabacklogacrossmultiplereleases.Prioritizationisimportantforanysoftwaredevelopmentmethod,butagilemethodscannotsucceedwithoutconstantandfrequentprioritizationofwork.

MoSCoWgetsitsnamefromanacronymformedbythefollowingclassificationsofpriority:Musthave,Shouldhave,Couldhave,andWouldlike.Theletteroisaddedtomaketheacronympronounceable.Theclassificationsareasfollows:

• MustHave.Thesearestoriesthatmustbedeliveredforthecurrentbusinessproblemtobeaddressed.Mustcansarethoughtofasaminimalusablesubset.

• ShouldHave.Thesearestoriesthatarecriticaltothesuccessoftherelease.ShouldstoriesareasimportantasMuststoriesbutmaynotbetime‐criticalormayhaveaworkaround.

• CouldHave.Thesearestoriesthatlesscritical.• WouldLike.Thesestorieswilllikelynotbeincluded,butmight

eventually.

.3 Elements• ProductBacklog:Acollectionofuserstoriesdescribingthe

desiredfunctionalityofaproduct.• Strategy:Anunderstandingoftheoutcomesforaninitiative.• CustomerPreference:Clarityonwhatismostimportanttothe

customer.

.4 Usage Considerations

MoSCoWisusefulwhentryingtoprioritizeabacklog.Unlikesomeprioritizationmethods,thismodelhelpsdifferentiatebetweenasetofusefuluserstoriestothosespecificallyfocusedonanoutcome.

Advantages• MoSCoWiseasytodescribeandtypicallyispowerfulin

prioritizingbacklogs.

Disadvantages

• MoSCoWcanbesubjective.Ifthereisnoteffectivecollaborationwiththebusiness,thismethodofprioritizationcanbeinaccurate.

78 The Agile Extension to the BABOK® Guide

Page 87: The Agile Extension

Techniques Analyze to Determine What is Valuable

• Onaprojectwhereabusinessvalueincrementsapproach(MinimumMarketableFeatures)isused,theteamshouldonlydeliverMustHavesintheincrement.MoSCoWisthereforeinappropriate.

4.1.5 Purpose Alignment Model

.1 Purpose

Thepurposealignmentmodelisusedtoassessideasinthecontextofcustomerandbusinessvalue.Fromanagileperspective,themodelaidsinmakingprioritizationdecisionsandfocusinginvestmentonthosefeaturesorcapabilitiesthatareofgreatestvaluetotheorganization.

.2 Description

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

Thefollowingillustrationisanexampleofanpurposealignmentmodel.

FIGURE 4.10 PurposeAlignmentModel

November2011DraftforPublicReview 79

Page 88: The Agile Extension

Analyze to Determine What is Valuable Techniques

.3 Elements

Differentiating Quadrant

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

Parity Quadrant

Thingswhicharemissioncritical,butnotmarketdifferentiating,fallintotheparityquadrant.Thatmeansthatitisusuallysufficienttobeoperatingonparwithotherfirmsinyourindustry.Manystandardfunctions,suchasfinance,HR,payroll,andothersfallintothisquadrantformostorganizations.Activitiesinthisquadrantareimportantbuttheywillnotprovideanadvantagetothefirminrelationtocompetitorsandsoadoptionofbestpracticesisgenerallysufficient.

Partner Quadrant

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

Who Cares? Quadrant

Finally,activitieswhichareneithermission‐criticalorhelptodifferentiatetheorganizationinthemarketplacefallintothewhocaresquadrant.Astheseactivitiesdonotaddcustomervalue,andtheorganizationcanfunctionwithoutperformingthem,theyareprimecandidatestobeeliminatedandtheresourcesreallocatedtosupportmoreusefulwork.

80 The Agile Extension to the BABOK® Guide

Page 89: The Agile Extension

Techniques Get Real Using Examples

.4 Usage Considerations

Thepurposealignmentmodelisdesignedforusebyfor‐profitorganizationsthatfacecompetitioninthemarketplace.Governmentalorganizationsandno‐profitsmayfindthatmarketdifferentiationisnotasignificantdriverfortheirdecisions.Stakeholderormembervalue,oralignmentwiththeorganizationalmissionmayserveasanalternative.

Secondly,themodelprovidesguidanceonwhethersomethingshouldbeanareaofstrategicconcernbutdoesnotprovideanyguidanceonwhatstrategiesordecisionsmightbethecorrectones.

Advantages• Oneofthekeyadvantagesofthismodelisitssimplicity.Itcan

betaughttobusinesssponsorsandusersinacoupleofminutessothattheycancriticallyassessanideathemselvesratherthanthebusinessanalystdotheanalysisthatmaythenbechallenged.

• Themodeliseasytouseinafacilitatedcollaborativeenvironment.

• Itcanbeappliedallthewayupanddowntheinvestmentdecisionprocess.Fromstrategicinvestmentdowntoanindividualfeatureinasystem.

• Itisfastandentirebacklogcanbeanalyzedinlessthananhour.

Disadvantages• Itassumespositiveintentinthebusinessstrategy.Itdoesnot

incorporate“spoiler”behaviourbycorporations.

4.1 Get Real Using Examples

Inagilemethodologies,inordertoelicitandvalidateproductneedsbusinessanalysispractitionersuserealcustomerexamplestocommunicatewiththeteam,includingthecustomer.Realexamplesservetobridgeunderstandingofthecustomer'sbusinessandhowtheyseetheproductservingafuturestateneed.Analysismodelscanbeconcurrentlydevelopedandelaboratedusingthesesameexamples.Modelsmaybeusefulfortheteambutexamplesaremoreconcreteforthecustomer.Thetechniquesareusediterativelybyalternatingbetweenexamplesandanalysismodelstoexploremultiple

November2011DraftforPublicReview 81

Page 90: The Agile Extension

Get Real Using Examples Techniques

dimensions(forexample,userrole,useractions,data,businessrules)ofaproductneed.Thisisacontinuouspracticethatbuildsasharedteamunderstandingofproductneedsusefulforbothplanninganddelivery.Thesetechniquesengagecustomersinrequirementselicitation,analysis,andvalidation.

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

Thefollowingsectionsdescribecommonlyusedtechniques.

• Behaviour Driven Development

4.1.1 Behaviour Driven Development

.1 Purpose

Anapproachthatenhancesthecommunicationbetweenbusinessusersandthedevelopmentteam.

.2 Description

Traditionalbusinessanalysistechniquesofteninvolvecreatinganalysismodels,forexampleusingUMLmodels.Inadditiontoanalysismodels,agiletechniquesfavourcommunicationusingexampleswhicharemoreconcreteforthecustomer.Manypeopleareuncomfortablewithabstractionsandprefertoworkwithrealexamples.

Examplestendtobeadditiveandcanformaspecification.Theycanbeusedduringagileplanninganddeliverywork.Asmodelschange,examplescanberefinedbybuildingonpreviousexamples.Inagile,itishelpfultoiteratebetweenusingexamplesandanalysismodelsencouragingthemtofeedoffofeachother.Progressiveelaborationleadstoricherexplorationofmultipledimensions(forexample,userrole,useractions,data,businessrules)relatedtotheexample.

82 The Agile Extension to the BABOK® Guide

Page 91: The Agile Extension

Techniques Get Real Using Examples

Supplementingproductneeddiscussionswithexamplescreatesamuchmorestablesetofrequirementsthanusingamodelalone.

Forexample,ratherthan“acompanywhichsupportsmultiplebrandsfordifferentdemographicsegments”,consider“DisneyCorporationwhichhasDisneyfilmsforfamilyentertainment,Miramaxformoreadultaudiences,andMarvelforsuperheropictures.”

Inaddition,examplesfeedsmoothlyintoabehaviour/testdrivendevelopmentapproach.

.3 Elements

Examples

Examplesmayalsobeknownasscenarios.Examplesshouldnotbeartificialormadeup.Theyshouldbereallifebusinessscenariosprovidedbythebusinessusers.Businessanalysisactivitieshelptofacilitatethediscoveryoftheexamplesandensurethatthesetofexamplesiscomprehensive.Notallexamplesidentifiedwillnecessarilybewithinthescopeofadevelopmenteffort.

Behaviour Driven Development

Behaviourdrivendevelopmentprovidesasimplegrammarformatthatallowsrealscenariostobefilledin.Thistakestheform

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

Forexample,anATM

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

November2011DraftforPublicReview 83

Page 92: The Agile Extension

Understand What is Doable Techniques

Scenariosthatarewritteninabehaviourdrivendevelopmentformatspecifyingevents,conditions,andactionsareverifiable.Theycanserveasacceptancecriteriaforstories[see“StoryElaboration”onpage52]andserveastestsinsupportofAcceptanceTestDrivenDevelopment(ATDD)thatdriveacommonunderstandingofrequirementsandfutureproductneeds.

Testing

Therearenowanumberofsoftwareproductsthatwilltakeexamplesinthisformatandallowthemtobeeasilyconvertedintoautomatedtests,thusenablingmoreagiledelivery.Withacomprehensivesetofexamplesthatcanbeexecutedasautomatedtests,businessanalysisandtestingactivitiescanbemoretightlycoupled.

4.1 Understand What is Doable

Asanagileprojectteamplansfordelivery,itisimportanttothinkaboutwhatispragmaticanddoable.Theteammustbalancecapacityanddemandwhentheyestimatetheworktobedonetodelivertheproduct.Agileprojectteamscontinuallyreviewmeasures,suchasteamcapacity,priordeliverycyclecommitmentsandactuals,andvelocitytrendstoadjustcommitmentsonanon‐goingbasis.Thisenablestheteamquestionwhatcanbedeliveredgiventheirknowledgeofthework‐setandtosetappropriateexpectationsandmakebetterestimates.Understandingwhatisdoableoccursthroughoutanyagiledeliverycycle,suchasreleaseplanning,work‐aheadanalysis,orwheneverateamispullingnewbacklogitemsforconsiderationinaproductdeliverycycle.

Theentireteamusesthefollowingtechniquesasmethodstoidentifyandestimateunitsofworkthataredecomposedwithbusinessvalueinmind.

Thefollowingsectionsdescribecommonlyusedtechniques.

• Estimation• Planning Workshop• Real Options

84 The Agile Extension to the BABOK® Guide

Page 93: The Agile Extension

Techniques Understand What is Doable

4.1.1 Estimation

.1 Purpose

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

Estimationisateamactivity,andbusinessanalysismakesanimportantcontributionbyhelpingtheteamtobetterunderstandthecomponents,characteristicsandcomplexityofthework.

Althoughestimatesarenotvisibleinthefinalproduct,theydoaddsignificantvaluetoanagileproject.Providingcredibleestimatesallowstheprojectteamto:

• determinecostandeffort,• establishtheprioritiesoftheproject,and• commitmenttoaschedule.

.2 Description

EstimationisdiscussedatlengthintheBABOK®Guide(9.10Estimation).Here,webuildontheinformationintheBABOK®Guideandsummarizetherelativeestimationtechniquesthatcanbeappliedintheagiledevelopmentenvironment.

Uniquetotheagileenvironment,estimatingisprogressiveandoccursinalignmentwithiterations.Nooneexpectsearlyestimatestobeasaccurateaslatterestimates.Improvementoccursovertimeastheteamsbuildconfidenceintheircapacityandcapabilities.

Inadditiontothebasicapproachofestimatingbasedonhistoricalknowledge,agileestimatorsfrequentlyapplyarelativeestimatingmodelinwhichteamsdevelopnarratives(stories)thatdefineuserneedsandbenefits.Thesestoriesareanalyzedbytheteamandnumericvaluesareappliedtoeachstory(storypoints).Storypointscanbeabstractmeasurementsthatprovideanumericvaluetoastory,orstorypointscanbedescribedasidealdeveloperdays(IDDs).

Astorypointisanumberassignedtoeachstorythatdefinestheestimatedeffortateamwillhavetoapplytothestory.Storypointsare

November2011DraftforPublicReview 85

Page 94: The Agile Extension

Understand What is Doable Techniques

usuallybasedonwhattheteamknowsaboutthestoryinfourkeyareas:

• Knowledge:Howmuchinformationdoestheteamhave?• Complexity:Howdifficultistheimplementationlikelytobe?• Volume:Howbigisthestory?Howlongwillittake?• Uncertainty:Whatvariablesandunknownfactorsmightimpact

thestory?

Thetotalnumberofstorypointswithinanygiveniterationisconsideredtobetheteam’svelocity,orhowmuchateamcanaccomplishwithintheiteration.Afterseveraliterationsteamswillhaveabetterunderstandingoftheiractualvelocity.Thiswillallowthemtomakebetterinformedestimatesandcommitmentsinsubsequentiterations.

Thereareseveralwaystogetstartedwithstorypointestimation.Theagileestimatorcanbeginwith

• aWAG(wideangleguess),• agivensetofresourcesandafixediteration,or• anestimationofthetimerequiredforasinglestorypoint,and

thenextrapolatefromtheirtoestimatetheworkthatcanbedoneinaniteration.

.3 Usage Consideration

Advantages• Relativeestimationisasimple,reliablemethodologythatfits

wellwithagilepractices.Itishighlyadaptiveandislikelytobecomeincreasinglyaccuratethroughoutsuccessiveiterations.

• Theplanningpokertechniqueisahighlycollaborativeprocessthatisbasedonconsensusandwilllikelyhaveapositiveimpactondevelopmentteams.Itbuildsuponthewisecounselto“asktheteam.”

Disadvantages• Relativeestimatesarebasedonhistoricaldataandaccuracyis

dependentuponthesimilarityofnewstoriestostoriespreviouslydelivered.Ifnewstoriesdifferradicallyfrompreviousstories,itispossiblethattheaccuracyoftheestimatemaydecrease.

86 The Agile Extension to the BABOK® Guide

Page 95: The Agile Extension

Techniques Understand What is Doable

• Theaccuracyofvelocityisdependentontheknowledgeandexperienceofthedevelopmentteam.Anychangestoteamcompositionwillimpactvelocityandthereforeestimates.

4.1.2 Planning Workshop

.1 Purpose

Toenabletheteamtodeterminewhatworktoperformduringaniterationortodeliveraminimummarketablefeature(MMF).

.2 Description

Aplanningworkshopisexecutedwhentheteamneedstoarriveatacommitmenttosomesetoffunctionalitythattheyfeelreasonablyconfidenttheycancompleteinthenearfuture.Inmostagilemethods,thisisperformedatthebeginningofeachiteration,butmayalsooccurwhenevertheteamisneartocompletingtheirbacklogofworkorthatbacklogneedstobeordered.InKanban,theamountofworkbeingperformedbytheteamislimitedbyrestrictingthenumberofworkitemsthatcanbeinanyworkflowstate,notbasedoniterations.Businessanalystscanprovidevaluetotheteambyhelpingtounderstandandfocusontheiterationobjectives,thevalueassociatedwithaparticularMMF,businessissues,storydecomposition,andbringingtheteamtogethertodeliveranacceptableoutcome.Priortotheworkshop,thereisusuallyapre‐planningstagethatinvolvesanalysistogetareasonablegaugeofthesize,scope,andcomplexityofeachbacklogitemthatwillbebroughttotheiterationplanningworkshop.

Inagiledevelopment,planningworkshopsneedtobeperformedonafrequentandregularbasis,astheorderinwhichworkismeanttobeperformedisregularlyalteredandupdated.Thisallowstheteamandcustomerstochangetheprioritiesofoutstandingworktoincorporatefeedbackorchangingbusinessneeds.

.3 Elements

Estimated and Ordered Product Backlog

Typicallybasedonuserstories,itisthemaininputfortheplanningmeeting.

November2011DraftforPublicReview 87

Page 96: The Agile Extension

Understand What is Doable Techniques

Team Velocity

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

Iteration Goal or MMF Set

Manyteamssetanoverallgoalfortheiterationtohelpguidetheselectionoffeatures.Thisisasubsetofthereleasegoal.Itisanobjectivethatwillbemetthroughtheimplementationoftheproductbacklog.

Requirement Selection

Atthebeginningofthemeeting,basedonbusinessvalue,iterationgoal,andteamvelocity,thehighestpriorityfeaturesaretypicallyselectedfromthereleaseplanbytheproductowner,productchampion,oracustomergivendecisionmakingauthority.

Non-Feature Selection

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

Task Planning

Theteamwillbreakthefeatureandnon‐featureitemsdownintotasks.Taskstypicallyrangeinsizefrom4hoursto2days,withmosttaskscapableofbeingdeliveredwithinaday.Taskseffortcanbeestimatedinhoursforfurtherstatisticalcontrol.

.4 Usage Considerations

Advantages• Customer,productowner,anddevelopmentteamcan

communicateandcollaboratefrequentlyaboutproductvisionandevolution.

88 The Agile Extension to the BABOK® Guide

Page 97: The Agile Extension

Techniques Understand What is Doable

• Customerandproductownercanguidetheprojectnotjustatthestartbutdaybyday.

• It’seasiertounderstand,estimate,andplanthescopeofsmalliterationsinsteadofthescopeofbigreleases.

• Planscanbechangedinadvancebasedonfeedbackfromincrementaldeliveryofworkingsoftware.

• Iterationplanningcanguaranteevisibilityofthewholeprojectandsynchronizationbetweenmultipleteams.

Disadvantages• Itisnecessarytogetallpeopletogetherinordertoavoid

interruptionsandrework,especiallywhenworkingwithdistributedorconcurrentteams.

• Ifthewholeprojectisnotwellunderstoodduringtheiterationplanningworkshop,it’spossibletoresultinasuboptimalplan.

• Someapproachesconsideranalysis,design,andplanningsomeactivitiestobeexecutediniterationplanningworkshops,whichcanbeverytimeconsumingforlongiterations(3or4weeks),generatingcomplaintsfromteammemberseveniftheeventisproductive.

4.1.3 Real Options

.1 Purpose

Anapproachtohelppeopleknowwhentomakedecisionsratherthanhow.Theapproachhelpsyouunderstandwhetheryouhaveacommitmentoranoption.

.2 Description

Thecoreconceptbehindrealoptionsisthatyoushoulddelaymakingadecisionoracommitmentinaprojectuntilthelastresponsiblemoment,whenthedecisionreallyneedstobemade.Therealoptionapproachhasthreesimplerules:

• optionshavevalue,• optionsexpire,and• nevercommitearlyunlessyouknowwhy.

Thefirstandthirdruletellyoutoavoidcommitmentsandkeepyouroptionsopen.Thesecondruletellsyoutounderstandwhenanoption

November2011DraftforPublicReview 89

Page 98: The Agile Extension

Understand What is Doable Techniques

expiressothatyoucanactivelymanagewhetheryouchosethatoptionorletitlapse.Asthereisvalueinoptions,youshouldseektoextendthematurityoftheoptions.

Realoptionsaddresspeople'saversiontouncertaintybyprovidingtheconditionswhenacommitmentshouldbemade(theoptionexpiry)ratherthansimplysuggestingthattheywait.

Themostcommonusageofrealoptionswithinagileprojectsisthewayinwhichbusinessinvestorschosewhichitemtoinvestinnext.Traditionally,investorswouldprioritizetheirrequirementsforanextendedperiodoftime.Withrealoptions,theywouldonlyprioritizeuntilthenextinvestmentdecisionpoint.OnScrumprojectsthiswouldbethenextsprintplanningsession.InKanban,itwouldbethenexttimecapacitybecomesavailabletoworkonsomethingnew.

Realoptionssupportagilebusinessanalysisbyallowingustoreducethenumberofdecisionswehavetoconsideratanyonetime.

.3 Elements

Options and Commitments• Realoptionsforcesyoutoidentifywhetheryouhaveoptionsor

not,andalsoforcesyoutoidentifythecommitmentsyouaremaking.

• Therealoptionsmaterialtendstofocusonnon‐ITprojectrelatedexamples,tohelppeopleidentifytheminageneralsenseratherthanspecifyalistofcommonoptionswhicharelearnedbyrote.

Examplesofoptionsinclude:

• Ahotelreservation.Anoptiontostayatthehotel.Theoptionnormallyexpiresat6p.m.onthedayofthestayatwhichpointyouarecommittedtopayingforthehotelroom.

• Atickettoaconference,sportingevent,rockconcertortheatre.Theoptiontoattendtheeventexpiresattheendoftheevent,orsometimesearlier.

• Atravelcard.Theoptiontotravelonpublictransport.TheoptionexpiresinLondonataboutmidnight.

• Abusinesscard.Theoptiontocontactthepersonwhogivesyouthecard.Theoptionexpireswhenthepersonchangescontactdetails.

90 The Agile Extension to the BABOK® Guide

Page 99: The Agile Extension

Techniques Understand What is Doable

Optionsarethingsyoucanchosetodoornotdo.Ifyouarecommittedtodoingsomethingandthereisonlyoneway,thenyoudonothaveoptions.

Someexamplesofcommitmentsinclude:

• Oftenthereisapenaltyassociatedwithfailingtomeetacommitment.

• Payingyourtaxes.Failuretomeetthiscommitmentmayresultinfinesorworse.

• Turninguptoworkontime.Failuretomeetthiscommitmentmayresultinterminationofyourcontractofemployment.

• Deliveringitemsyouhavecommittedtodelivertootherpeople.Failuretomeetthiscommitmentwillleadtoabadreputationandmayleadtoalawsuit.

Examplesofthingsthatarenotoptions.

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

Options Expiry

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

Determinationofwhenanoptionexpiresisthemostimportantaspectofrealoptions.Withoutthisknowledge,youareblindinyourdecisionprocess.Youeithermakedecisionstosoonortoolateandyoudonotknowwhich.

Example

Youhavethechoicetoattendasportingeventat7p.m.

• Theoptiontoattenddependsonwhereyouare.Imagineyouareathomewhichis1houraway,thenyouroptiontoattendexpiresat6pm.Ifyouleaveafter6p.m.,youwillbelate.

November2011DraftforPublicReview 91

Page 100: The Agile Extension

Understand What is Doable Techniques

• Imagineyouareatworkwhichis2hoursaway,thenyouroptiontoattendexpiresat5p.m.Ifyouleaveafter5p.m.,youwillbelate.

Asoptionshavevalue,pushingtheexpirydatebackaddsvaluetoyourprojectandallowsyoumoreflexibility.

Right / Wrong / Uncertain

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

Ifyouasksomeonetomakeadecisionlaterortonottomakethedecisionnow,theyarefacedwithunboundeduncertaintyandasaresulttheyarelikelytomakeadecisionbasedontheinformationtheyhavenow.Thisemotionalcommitmentthenmakesithardertochangethedecisionasfurtherinformationarrives.

Realoptionssuggestsusingboundeduncertainty.“Makethedecisionwhen...”Specifytheconditionswhenthedecisionshouldbemade.

Specifyingtheconditionswhenacommitmentshouldbemadeallowsthedecisionprocesstobemanaged.Aseniormanagercanasktheirassistanttomonitortheconditionsonhisbehalf.

Anotherexampleofthisisthecheckoutatsupermarkets.Whendotheyopenanothercheckout?At6p.m.?At7p.m.?Theyopenacheckoutwhenthreepeoplearewaitinginthequeue.Theythenpublishthefactsothattheircustomerscanmanagetheprocessforthem.Theyreactwhencustomer'scomplainaboutthelengthofthequeueandopenupanothertill.Whenqueuelevelsdrop,theyclosetillsagainandredeploystafftoreplenishingtheshelves.

Feature Injection

Featureinjectionisacollectionoftraditionalbusinessanalysistechniquesthathavebeencombinedtoallowabusinessanalysttoperformanalysisinafastandeffectivemanner.Thisspeedthenallowsinvestmentcommitmentstobedeferredbecauseitreducethelengthoftimethatanalysistakes.

Thespeedoftheprocessisduetofollowingtherealoptionprocess.Theanalysisstartswiththeoutputandthenworksbackthroughthe

92 The Agile Extension to the BABOK® Guide

Page 101: The Agile Extension

Techniques Stimulate Collaboration & Continuous Improvement

processtotheinputs.Itthenconsidershowdifferentexamplesaffecttheprocess.

Thethreestepsoftheprocessare

1.Identifythebusinessvaluewhichspecifiestheoutputs/outcomesrequiredfromthesystem/process.

2.Injectthefeaturesthatworkoutwhichprocessesandinputsarerequiredtoproducetheoutputs/outcomes.

3.Breakthemodelwhichusemodelsidentifiesalltheexamplesthatproduceadifferentbehaviourinthesystem/process.

.4 Usage Considerations

Advantages• Realoptionssimplifydecisionmakingbyprovidingasimpleset

ofprinciplestofollow.• Realoptionsmakedecisionmakingfastasyouonlyfocusonthe

immediatedecisionsanddeferprioritizationuntilalaterdatewhencomplexityisresolved.

• Realoptionsdonottellyouhowtomakedecisions,justwhenwhichmakesthembroadlyapplicableasanapproach.

• Realoptionshelpusoptimizeprocessbyforcingustoconsiderthedecisionpointsandtheinformationarrivalprocess(whendataarrivesandwhetheritarrivesbeforethedecision).

Disadvantages• Realoptionscanbecounter‐intuitiveastheyrequireusto

analyzesystemsfromtheoutputstotheinputs.• Realoptionsarenotasimpleprocesstobefollowedbyrote.

Theyareathinkingtoolthatrequirespracticeandstudy.

4.1 Stimulate Collaboration & Continuous Improvement

Agilepracticesemphasizetheimportantofcontinualcollaborationbetweenmembersoftheprojectcommunity.Weactivelycreateanenvironmentwhereallprojectstakeholderscancontributetotheoverallprojectvalue,ideallyinfacetofacefacilitatedworkshops.The

November2011DraftforPublicReview 93

Page 102: The Agile Extension

Stimulate Collaboration & Continuous Improvement Techniques

realityformanyprojectsisthattheyaredistributedintermsofteam,timeandgeography.Facilitationskills,inconjunctionwiththetechniquesoutlinedinthissection,enablescollaborationforbothlocalanddistributedteams.Thetechniquesinthissectionentailworkingtogetheringroupstocreateasharedunderstanding.Thiscollaborativepointofviewpervadesanagileproject,andisnotlimitedtoanyspecifictechnique.

Oneofthefundamentalprinciplesofallagilemethodsistheneedforcontinuousimprovement,notjustoftheproductunderdevelopmentbutoftheprocessusedbytheteamtodelivertheproduct.Thisisachievedthroughbothstructuredandunstructuredfeedbackonacontinuousbasis.Forexample,theretrospectiveisanopportunityfortheteamtoexaminetheirprocessesandproducttoidentifyopportunitiesforimprovement.Healthycollaborativeteamshavethetrustandsafetynecessarytotransparentlyidentifyopportunitiesforimprovement.

Thefollowingsectionsdescribecommonlyusedtechniques.

• Collaborative Games• Retrospectives

4.1.1 Collaborative Games

.1 Purpose

Collaborativegamesarenotusedstrictlybyagileteams,althoughtheyareprevalentinagilepracticesbecausetheyemphasizetheconceptsofteamworkandcollaboration,whicharehighlyvaluedbyagilepractices.Collaborativegameshelpagroupofpeoplepromoteacommonunderstanding,gaininsightintoaproblem,orinspirenewideasaboutsolvingaproblem.

.2 Description

Collaborativegamesrefertomanydistinctstructuredtechniques,whichincluderulestokeepparticipantsfocusedonaspecificobjective.Thegamesareusedtohelptheparticipantssharetheirknowledgeandexperienceonagiventopic,identifyhiddenassumptions,andexplorethatknowledgeinwaysthatmaynotoccurduringthecourseofnormalinteractions.Thesharedexperienceofthecollaborativegameencouragespeoplewithdifferentperspectivesona

94 The Agile Extension to the BABOK® Guide

Page 103: The Agile Extension

Techniques Stimulate Collaboration & Continuous Improvement

topictoworktogethertobetterunderstandanissueanddevelopasharedmodeloftheproblemorofpotentialsolutions.

Collaborativegamesoftenbenefitfromtheinvolvementofaneutralfacilitatorwhohelpstheparticipantsunderstandtherulesofthegameandhelpstoenforcethem.Thefacilitator'sjobistokeepthegamemovingforwardandtohelpensurethatallparticipantsplayarole.

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

.3 Elements

Purpose

Gamesalwayshavesomedefinedpurpose,typicallytodevelopabetterunderstandingofaproblemortostimulatecreativesolutions.Theparticipantsinthegameneedtounderstandthatpurpose,andthefacilitatorwillhelpkeepthemmovingtowardit.

Process

Gamesalsohaveaprocessorrulesthattheyfollowtokeepthegamemovingtowarditsgoal.Often,eachstepinthegameistimelimited.Gamestypicallyhaveatleastthreesteps:

1.anopeningstep,wheretheparticipantsgetinvolved,learntherulesofthegame,andstartgeneratingideas,

2.theexplorationstep,whereparticipantsengagewithoneanotherandlookforconnectionsbetweentheirideas,testthoseideas,andexperimentwithnewones,and

3.aclosingstep,wheretheideasareassessedandparticipantsworkoutwhichideasarelikelytobethemostusefulandproductive.

Outcome

Finally,attheendofacollaborativegame,thefacilitatorandparticipantswillworkthroughtheresultsofthegameanddetermineanydecisionsoractionsthatneedtobetakenasaresultofwhattheparticipantshavelearned.

November2011DraftforPublicReview 95

Page 104: The Agile Extension

Stimulate Collaboration & Continuous Improvement Techniques

.4 Usage Considerations

Itisnotpracticaltoelaborateonthemanycollaborativegamingtechniquesandtheirusageconsiderationsinthisdocumentbutthefollowingexamplesmayprovideastartingpoint.

Thefollowingchartprovidessomeexamplesofcollaborativegames.

TABLE 4.6 Examples of Collaborative Games

4.1.2 Retrospectives

.1 Purpose

Themostsingularobjectiveofaretrospectivemeetingisforateamtocometogetherinordertoreflectonwhatithasdonewell,whatitcoulddobetter,andtoreachagreementonhowanyimprovementswillberealized.Uniquetotheagileenvironment,retrospectivesareheldattheendofeachiterationsothatlearningscanbequicklyembeddedintheprocessesandpracticesgoingforwardforremainderoftheproject.

.2 Description

Theretrospectiveprovidesanopportunityforallmembersoftheteamtoreflectonthemostrecentdeliveries.Theretrospectiveshouldincludethewholeteamespeciallybusinessstakeholdersandusers.Itiscommonfortheretrospectivetobesplitintotwoparts.Thefirstpartinvolvingthewholeteamandthesecondparttodiscusstechnicalaspectsoftheprojectthatonlyaffectpartoftheteam.

Theretrospectiveshouldbefocusedonidentifyingissueswiththeprocess.Itshouldidentifyprocessimprovements,andnotbepersonal

Game Description Objective Product Box Participants construct a box for the product as if

it was being sold in a retail store. Used to help identify features of a product that help drive interest in the marketplace.

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

Used to help identify related or similar features or themes.

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

Used to identify hidden assumptions or perspectives.

96 The Agile Extension to the BABOK® Guide

Page 105: The Agile Extension

Techniques Stimulate Collaboration & Continuous Improvement

inanysense.Akeyelementofaretrospectiveisthattheteamfeelsafetodiscussanyissuethatconcernsthem.

Ideally,retrospectivesshouldbefacilitatedbyanneutralfacilitatorratherthanbyamemberoftheteam.

.3 Elements

Preparation

Theteampreparesideasfromtherecentiterationthatmaybeanalyzedintheretrospective.

Safety Check

Theteammustagree,together,totrusteachotherandtobelievethateverycommentorsuggestionisintendedforthesolepurposeofimprovingtheteam'sperformance.

Identify the Issues

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

Choosing Future Actions.

Oncealltheideashavebeendiscussedtothesatisfactionoftheteam,thefacilitatoraskstheteamtodecidewhichsolutions/improvementstheywanttofocusonnext.Theteamthenidentifieswhichimprovementswillbeaddressedandassignsresponsibilitytoanindividualteammemberwhoensuresthesolution/improvementisimplemented.

.4 Usage Considerations

Advantages• Anexcellentwayfortheteamtofindacollectivevoicearound

opportunitiesforteamimprovement.

November2011DraftforPublicReview 97

Page 106: The Agile Extension

Avoid Waste Techniques

Disadvantages• Teammembersmayfeelobligedtopretendthattheytrusteach

other,eventhoughtheydonot.• Retrospectivesareonlyofvalueiftheteamactsuponthe

learninginthesessiontoimprovetheprocess.• Mostideasraisedintheretrospectiveareknowtoatleastone

memberoftheteam.Amatureteamshouldbeaddressingissuesastheyarriveratherthanbatchingthemuptobehandledinaretrospective.

4.1 Avoid Waste

Agilemethodsemphasizethedeliveryofworkingsoftwaretothecustomer.Businessanalysisworkaddsvaluebyensuringthattheneedsofthecustomerareunderstoodandthattheteamdeliverswhatthecustomerreallyneeded.Anyactivitythatdoesnotcontributedirectlytothisgoal,orthatthecustomerwouldnotbewillingtopayfor,iswaste.

Wasteeliminationisanissuethathasbeentreatedwithgreatemphasisbytheagilecommunity.Itisamind‐setoriginatedfromLeanasthemosteffectivewaytoincreasetheprofitabilityofanybusiness.Leanthinkingconsidersavaluestreamhashavingtwocomponents.Valueaddedactivitiesandmuda(theJapanesewordforwaste).Theaimofleanthinkingistoremovethemuda,orwaste,fromthevaluestream.Wasteisfurthersub‐dividedintotwocomponents.Thoseactivitiesthathavevaluebutdonotcontributetothefinalproductdirectlylikeanarchitectsplanandthoseactivitiesthatdonotaddvalueatall.Theaimistoremovecompletelythoseactivitiesthatdoaddvalueatall,andminimizethoseactivitiesthatdonotcontributetothefinalproductdirectly.Youcanstartavoidingwasteinbusinessanalysisbydevelopingandkeepingdocumentationlightweight.

Thefollowingprinciplesarehelpfulwhenworkingtoidentifywasteinanybusinessanalysisprocess:

• Avoidproducingdocumentationbeforesomebodyelseneedsit.• Whenevervalueisnotbeingdeliveredtoyourcustomers,the

wasteofwaitingoccurs.Don'tletothersbewaitingforyourjob.• Transportinginformationbetweendifferentmediatypesisa

costincursionwhichaddsnovaluetotheproductdevelopment.

98 The Agile Extension to the BABOK® Guide

Page 107: The Agile Extension

Techniques Avoid Waste

Trytoelicit,analyze,specify,andvalidaterequirementswiththesamemodels.

• Analysismodelsshouldbeassimpleaspossible.Donotincludeinformationthatisnotdirectlyusefultoastakeholder.

• Work‐in‐progress(WIP),orinventory,isadirectresultofoverproductionandwaiting.Theytendtohideproblemsontheprocess.Ifyouseeit,trytoletthemflowovertheprocessoreliminateit.

• Workclosetothecustomersanddevelopmentteambecauseunnecessarymotionorwork‐a‐roundstosubstituteface‐to‐faceconversationsarealsowaste.

• Keepcontinuousattentiontoyourtechnicalexcellence.Qualitydefects(suchasunclearrequirements)resultinreworkandaretheworstwasteintheprocess.

Thefollowingsectionsdescribecommonlyusedtechniques.

• Lightweight Documentation

4.1.1 Lightweight Documentation

.1 Purpose

Ensurethatalldocumentationproducedthroughbusinessanalysisisintendedtofulfillanimmediateneed,hasclearvalueforstakeholders,anddoesnotcreateunnecessaryoverhead.

.2 Description

Lightweightdocumentationisaprinciplethatgovernsalldocumentationproducedinanagileproject.Thebusinessanalystshouldaimtoproduceaslittledocumentationaspossible,allofwhichshouldbeofvalue.Intraditionaldevelopmentlife‐cycles,documentationmaybeusedbydeveloperstocreatesoftwarealongtimeafteritsinitialcreation.Inagilemethodologies,thesoftwareisconstructedwithindaysoftheteamagreeingtodeliverasetofrequirements,andsodoesnotneedtoincludeinformationthattheteamcanrememberoragreetoduringtheconstructionprocess.

Traditionally,functionalspecificationsincludeallinformationthatthebusinessanalystknowsaboutthedomainproblem.Thespecificationmaycontainextensivedescriptionofthecontextinwhichtheprojecttakesplace,andmayattempttotrainthedeveloperinallaspectsofthe

November2011DraftforPublicReview 99

Page 108: The Agile Extension

Avoid Waste Techniques

domain.Thetransferofknowledgeistakenoutofthespecificationandismademoreeffectivethroughfacetofaceconversationsorothercommunicationmethods.

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

Ageneralprinciplewithagileisthatifadocumentisvaluableenoughtobecreated,itisprobablyimportantenoughtobeautomatedsothatitispartofthelivingcodebase.Thishasleadtotheriseofautomatedacceptancetestingandbehaviourdrivendevelopmentthatallowsbusinessanalyststoworkwithqualityassuranceprofessionalstocreateexecutablespecificationintheformofexamples.

ThisprinciplecomesdirectlyfromtheAgileManifestowhichsays“Workingsoftwareoverextensivedocumentation”.Itisoftenmisinterpretedasmeaningnodocumentation.Instead,documentationshouldbebarelysufficienttomeettheneedsoftheteam.

Theagileprinciplehaselevatedthevalueofdocumentationthatisproducedbythebusinessanalyst.Thedocumentationproducedbythebusinessanalystshouldideallybeautomatedintheformofautomatedtestsorexamples.

.3 Usage Considerations

Advantages• Reduceamountoftimespentwritingdocumentation.• Reduceeffortspentreadingandreviewingdocumentation.• Reducenumberofdraftsofdocuments.• Allreviewerscanfocusonkeyissuesratherthanextraneous

details.• Training(knowledgetransfer)isdonetosuiteachperson

ratherthanusingthedocumentation.• Thedocumentationlivesintheformofautomatedexamples.

100 The Agile Extension to the BABOK® Guide

Page 109: The Agile Extension

Techniques Avoid Waste

Disadvantages• Producinglightweightdocumentationmaycauseconflictwith

groupswhoenforcecorporateprocessstandards.• Somemaymisunderstandtheprincipleasmeaningno

documentation.• Someproducedocumentationthatisnotsufficientforan

externalentity.

November2011DraftforPublicReview 101

Page 110: The Agile Extension

Avoid Waste Techniques

102 The Agile Extension to the BABOK® Guide

Page 111: The Agile Extension

appendix A Glossary

Acceptance Criteria Requirementsthatmustbemetinorderfor a solution to be consideredacceptabletokeystakeholders.

Acceptance Test Driven Development (ATDD) ATDD is a TDD instance that involveswritingoneormoretests(or“customertests”) for a customer‐centric feature,beforethesolutionhasbeendeveloped.

Acceptance Testing SeeUserAcceptanceTest.

Agile Agilereferstoagroupofprinciplesandpractices that promote a disciplinedproject management process thatencourages frequent inspection andadaptation,aleadershipphilosophythatencouragesteamwork,self‐organizationandaccountability, a set of engineeringpractices intended to allow for rapiddeliveryofhigh‐quality software,andabusiness approach that alignsdevelopment with customer needs andcompanygoals.AlsoseeAgileManifesto,AgileSoftwareDevelopment.

Agile Manifesto TheAgileManifestoisastatementoftheprinciples thatunderpinAgileSoftwareDevelopment. It was drafted fromFebruary11ththrough13th,2001.

Agile Retrospective Retrospectivesareavariationofprojectretrospectives whereby theretrospectiveworkshopisconductedatregular intervals throughout thedelivery process, such as after eachiterationand/orrelease.

Agile Software Development Agile software development refers to agroup of software developmentmethodologies based on iterative andincremental development, whererequirements and solutions evolvethrough collaboration between self‐organizingcross‐functionalteams.

Anti-patternA commonly used, yet ineffective,processorpractice.

Backlog SeeProductBacklog.

Backlog Item An element that belongs to a productbacklog. It canbea feature,abug fix,adocument,oranyotherkindofartifact.

Behavior Driven Development (BDD) An approach that enhances thecommunicationbetweenbusinessusersandthedevelopmentteambyusingrealexamples.

November2011DraftforPublicReview 103

Page 112: The Agile Extension

Glossary

Burndown Chart Used to track thework remaining overtime.Work remaining is theY axis andtime is the X axis. Thework remainingshould jig up anddown and eventuallytrenddownward.AlsoseeReleaseBurndownChart.

Business Value In management, business value is aninformaltermthatincludesall formsofvalue that determine the health andwell‐beingofthefirminthelong‐run.Inagile development, business value isrelatedtoalldeliverablesthatincrease/protect revenue or reduce/avoid costsinabusiness.

CeremoniesControlled processes and documentsthat constitute events and outputs inanygivenmethodology.Ahighdegreeofceremony frequently implies a highdegreeofcontrolandtraceability.Basedon the just‐in‐time and just‐enoughmodel, agile projects generally have alower degree of ceremony. Agileceremonies include iteration planning,dailymeetings,andretrospectives.

Change Driven Methodology A software development approach thatrefers to a group of principles andpractices that promote a disciplinedproject management process thatencourages frequent inspection andadaptation,aleadershipphilosophythatencouragesteamwork,self‐organizationandaccountability, a set of engineeringbest practices intended to allow forrapid delivery of high‐quality software,and a business approach that alignsdevelopment with customer needs andcompanygoals.

Class-Responsibility-Collaboration (CRC) Cards Abrainstormingtoolusedinthedesignofobject‐orientedsoftware.

Daily Burndown SeeBurndownChart.

Daily Meeting Oneachdayofasprint, theteamholdsdailymeetings. Ideally they are held inthemorningastheyhelpsetthecontextfor the coming day's work. The dailyscrum isnotusedasaproblem‐solvingor issue resolutionmeeting. Issues thatare raisedare takenofflineandusuallydealt with by the relevant sub‐groupimmediatelyafterthedailyscrum.

Daily Scrum Meeting SeeDailyMeeting.

Daily Standup SeeDailyMeeting.

Elicitation An activity within requirementsdevelopment that identifies sources forrequirements and then uses elicitationtechniques (for example, interviews,prototypes, facilitated workshops,documentation studies) to gatherrequirements from thosesources.

Enterprise Analysis Describes how business analystsidentifyabusinessneed,refine and clarify the definition of thatneed, and define a solution scope thatcan feasibly be implemented by thebusiness.Thisknowledgeareadescribes

104 The Agile Extension to the BABOK® Guide

Page 113: The Agile Extension

Glossary

problem definition and analysis,business case development, feasibilitystudies, and the definition of solutionscope.

Epic A piece of functionality that enables auser to achieve a clearly identifiedbusinessobjective.OftenEpicsareatthelevelofElementaryBusinessProcesses‐‐‐a piece of work undertaken by oneperson, at one time, in one place thatdelivers on a specific operationalobjective.

Feature Injection An analysis technique based on realoptionsandKolb’smodelof learning.Itcan be used to efficiently identify thebusinessvalue, and thendetermine theminimum set of features necessary todeliverthatvalue.

Iteration Burndown SeeProductBurndownChart.

Just-in-time Requirements Requirements that define only what isneeded for the current iteration andonly to the level of detail required fortheteamtodelivertheitem.

Lean DevelopmentAnagilemethodologythatisguidedby7principles: eliminate waste, amplifylearning, decide as fast as possible,empower the team, build integrity in,andseethewhole.

Minimal Marketable Feature (MMF) A chunkof functionality thatdelivers asubset of the customer’s requirements,andthatiscapableofreturningvaluetothe customer when released as anindependententity.

Minimal Viable Feature (MVF) Commonlyusedwithnewproducts.AlsoseeMinimalMarketableFeature.

On-site Customers The term used for the individualresponsiblefortherelativeprioritiesforthe solution requirements in theExtremeProgrammingmethodology.

Operations ReviewsA time‐based process that is used toevaluate milestones and ensure theproduction environment is monitoredandmeasured.

Pair ProgrammingA development technique, frequentlyused in Extreme Programming, wheretwo programmers work together onecomputer, developing code. Generallyoneprogrammerwrites the codewhiletheotherreviewsthecode.

Persona Fictional characters or archetypes thatexemplifythewaythattypicaluserswillinteractwithaproduct.

Plan-driven A software development approach thatfollows an orderly series of sequentialstages. Requirements are agreed upon,design is created and then the code isdeveloped,andtested.

Planning GameThe process used in ExtremeProgramming to conduct releaseplanning and iteration planning. Bothtypes of planning is broken down intothreedistinctphases:explorationphase,commitmentphase,andsteeringphase.

November2011DraftforPublicReview 105

Page 114: The Agile Extension

Glossary

Planning PokerAttechniqueusedinrelativeestimationthat uses the entire team to contributetotheestimatedworkeffort.Duringthisgroup exercise, each member of theteamhas a setof cards thathave storypoint values on them. The stories arepresentedand theneach teammembersubmits the card that has the value ofstorypoints that they feel ishowmucheffort is required to deliver the story.Theprocessisrepeateduntilconsensusisreachedforeachstory.

Potentially Shippable Product Increment Scrumrequires thateachsprintdelivera potentially shippable productincrement.The incrementmustconsistofthoroughlytestedcodethathasbeenbuilt into an executable, and the useroperation of the functionality isdocumentedeither inHelp filesoruserdocumentation.

Product Backlog Item In Scrum, a product backlog item (PBI,backlog item,or item) isaunitofworksmallenoughtobecompletedbyateamin one sprint. Backlog items aredecomposedintooneormoretasks.

Product Burndown Chart InScrum,theproductburndownchartisa "big picture" view of a project'sprogress.Itshowshowmuchworkwaslefttodoatthebeginningofeachsprint.The scope of this chart spans releases;however, a release burndown chart islimitedtoasinglerelease.Alsoseeburndownchart.

Product Champion SeeProductOwner.

Product Owner The product owner represents theinterestsofallstakeholders,definesthefeatures of the product and prioritizestheproductbacklog.

Product Roadmap An initial high level project scope anddirection. It may include an initialarchitecture.

Rapid Application Development (RAD) Agenerictermreferringtoanynumberof lighter‐weight approaches, usingfourth‐generation languages andframeworks (such as web applicationframeworks), which accelerate theavailabilityofworkingsoftware.

Rational Unified Process (RUP) An iterative software developmentprocess framework created by theRational Software Corporation, adivisionofIBMsince2003.

Relative EstimationA way of estimating work effort byidentifying features/requirements withstories and then assigning story pointsto each story. The cumulative storypoints are the amount of effort toestimate the amount of effort requiredto deliver each story. The story pointsare then calculated against the team’svelocity to create an estimate on howmuch the team can deliver in aparticulariteration.

106 The Agile Extension to the BABOK® Guide

Page 115: The Agile Extension

Glossary

Release The transition of an increment ofpotentially shippable product from thedevelopment team into routine use bycustomers. Releases typically happenwhenoneormore sprintshas resultedin the product having enough value tooutweighthecosttodeployit.

Release Burndown Chart The release burndown chart is a "bigpicture" viewof a release'sprogress. Itshowshowmuchworkwaslefttodoatthebeginningofeachsprintcomprisingasinglerelease.Thescopeof thischartis a single release; however, a productburndownchartspansallreleases.AlsoseeProductBurndownChart.

Release Planning At the beginning of a project the teamwillcreateahigh‐levelreleaseplan.Theteam cannot possibly know everythingup front so a detailed plan is notnecessary. The release plan shouldaddress:thenumberanddurationoftheiterations, how many people or teamsshouldbeonthisproject,thenumberofreleases, the value delivered in eachrelease,theshipdateforthereleases.

Scrum Master The Scrum Master is responsible formaking sure a Scrum team livesby thevalues and practices of Scrum. TheScrum Master protects the team bymaking sure they do not overcommitthemselves to what they can achieveduringasprint.

Scrum Team TheScrumTeambuildstheproductthatthe customer is going to consume: thesoftware or website, for example. Theteam in Scrum is "cross‐functional" ‐ it

includes all the expertise necessary todeliver the potentially shippableproduct each sprint ‐ and it is "self‐organizing",with a very highdegree ofautonomyandaccountability.

Shippable ProductA fully testedunitof codewhichmeetsacceptance criteria, that is delivered attheendofaniteration.

Service Level AgreementsFormalagreementsthatcontractlevelofserviceandperformance.

Solution Assessment and Validation The set of tasks that are performed inordertoensurethatsolutionsmeet thebusiness need and to facilitate theirsuccessful implementation. Theseactivities may be performed to assessand validate business processes,organizational structures, outsourcingagreements, software applications, andany other component of thesolution.

Spike  An experiment to explore potentialsolutions or build a partial solution.Spikesarecreatedtofigureoutanswerstotoughtechnicalordesignproblems.

Sprint An iteration of work during which anincrement of product functionality isimplemented.

Sprint Backlog Itemsselectedfromtheproductbacklogtobedeliveredinthecurrentsprint,andtheirtasks.

November2011DraftforPublicReview 107

Page 116: The Agile Extension

Glossary

Sprint Goal The Sprint Goal sprint goal is a shortdescription of what the sprint willattempttoachieve.

Sprint Planning Meeting TheSprintPlanningMeetingisattendedbytheproductowner,scrummaster,theentire scrum team, and any interestedand appropriate management orcustomer representatives. During thesprint planning meeting the productowner describes the highest priorityfeatures to the team. The team asksenoughquestionsduringthismeetingsothat they can go off after the meetingand determine which tasks they willmove from the product backlog to thesprintbacklog.

Sprint Retrospective The Sprint Retrospective is the mainmechanismfor taking thevisibility thatScrum provides into areas of potentialimprovement,andturningitintoresults.

Sprint Review Meeting Ameetingwherethescrumteamshowswhat they accomplished during thesprint.Typicallythistakestheformofademo of the new features. Participantsinthesprintreviewtypicallyincludetheproduct owner, the scrum team, thescrummaster,management,customers,and engineers from other projects.During the sprint review the project isassessed against the sprint goaldetermined during the Sprint planningmeeting.Ideallytheteamhascompletedeachproductbacklogitembroughtintothesprint,butitismoreimportantthatthey achieve the overall goal of thesprint.

Standup Meeting SeeDailyMeeting.

Story SeeUserStory.

Story Mapping AStoryMapisatooltoassistincreatingunderstanding of product functionality,the flow of usage, and to assist withprioritizing product delivery (such asreleaseplanning).

Task Board The task board shows all thework theteam is doing during an iteration. It isupdated continuously throughout theiteration – if someone thinks of a newtasktheywriteanewcardandputsitonthe board. Either during or before thedaily meeting, estimates are changed(up or down) and cards are movedaroundtheboard.

Team Velocity The rate at which a team canconsistently deliver software featuresper iteration. Typically, it can beestimated by viewing previous sprints,assuming the team composition. andsprintdurationarekeptconstant.Itcanalsobeestablishedonasprint‐by‐sprintbasis, using commitment‐basedplanning.

Theory of Constraints Developed by Dr. Eli Goldratt, theTheory of Constraints (TOC) holds thateverysystemhasatleastoneconstraintlimiting it. TOC’s goal is to increaseefficienciesbyidentifyingandmitigatingtheseconstraints.

108 The Agile Extension to the BABOK® Guide

Page 117: The Agile Extension

Glossary

UMLUnified Modeling Language (UML) is astandardized language used to visuallyarticulate elements of a piece ofsoftware.

User Acceptance Criteria Test cases that users employ to judgewhether the delivered system isacceptable. Each acceptance testdescribes a set of system inputs andexpectedresults.

User Story Ahigh‐level,informal,shortdescriptionof a solution capability that providesvalue to a stakeholder. A user story istypicallyoneortwosentenceslongandprovides the minimum informationnecessary to allow a developer toestimate the work required toimplementit.

User Story Mapping A workflow of a business process thatbreaksdowntasksforeachprocessandrepresentsthesetasksbasedonpriority.

Value driven developmentA process used to prioritizerequirementsorbacklogitemsbasedonbusinessvalue.

Velocity SeeTeamVelocity.

Waterfall A software development approach thatfollows an orderly series of sequentialstages. Requirements are agreed upon,design is created and then the code isdeveloped,andtested.

Whole Team Testing The concept embraced by may agilemethodologieswheretheentireprojectteam is responsible for qualityassuranceandtestingthecode.

November2011DraftforPublicReview 109

Page 118: The Agile Extension

Glossary

110 The Agile Extension to the BABOK® Guide

Page 119: The Agile Extension

appendix B Bibliography

ThefollowingworkswerereferencedbycontributorstoTheAgileExtensiontotheBABOK®Guide.Incaseswheremultipleeditionsofaworkwereconsulted,onlythemostrecenteditionislisted.

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

Withonlyaveryfewexceptions,theideasandconceptsfoundinTheAgileExtensiontotheBABOK®Guidewerenotcreatedoriginallyforororiginaltoit.TheAgileExtensiontotheBABOK®

Guideisasynthesisofyearsofresearchintohowagiledevelopmentmethodologiesareutilizedandmethodsthatcanbeusedtoidentifypotentialimprovements.Theworkslistedbelow,themselvesbuildonthethoughtsandresearchofmanyothers.

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

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

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

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

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

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

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

November2011DraftforPublicReview 111

Page 120: The Agile Extension

Bibliography

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

Cohen,Mike.2006.AgileEstimatingandPlanning.PrenticeHall.

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

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

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

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

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

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

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

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

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

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

Gottesdiener,Ellen.2005.SoftwareRequirementsMemoryJogger.GoalQPCInc.

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

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

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

IIBA(2009).AGuidetotheBusinessAnalysisBodyofKnowledge®(BABOK®

Guide),Version2.InternationalInstituteofBusinessAnalysis.

112 The Agile Extension to the BABOK® Guide

Page 121: The Agile Extension

Bibliography

Jonasson,Hans.2008.DeterminingProjectRequirements.CRCPress.

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

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

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

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

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

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

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

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

Maassen,OlavandChrisMatts.June2008.RealOptionsunderlieAgilePractices.InfoQ.com.http://

www.infoq.com/articles/real‐options‐enhance‐agility.

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

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

ManifestoforAgileSoftwareDevelopment.http://agilemanifesto.org.

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

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

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

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

Patton,Jeff.October8,2008.Thenewuserstorybacklogisamap.AgileProductDesign.com.http://agileproductdesign.com/blog/the_new_backlog.html.

Patten,Jeff.February26,2010.UserCentredDesignandStoryMapping.InfoQ.com.http://www.infoq.com/interviews/patton‐story‐map.

November2011DraftforPublicReview 113

Page 122: The Agile Extension

Bibliography

Pixton,Pollyanna,NielNickolaisen,ToddLittle,andKentMcDonald.2009.StandBackandDeliver:AcceleratingBusinessAgility.Addison‐WesleyProfessional.

Pols,AndyandChrisMatts.2004FiveBusinessValueCommandments.AgileProjectManagementAdvisoryServiceExecutiveUpdate.Vol.5,No.18.CutterConsortium.http://cdn.pols.co.uk/papers/cutterbusinessvaluearticle.pdf.

Pyzdek,Thomas.2003.TheSixSigmaHandbook,RevisedandExpanded.McGraw‐Hill.

Rosenberg,DougandMattStephens.2007.UseCaseDrivenObjectModelingwithUML:TheoryandPractice.Apress.

Rother,MikeandJohnShook.1999.LearningtoSee:Value‐StreamMappingtoCreateValueandEliminateMUDA.TheLeanEnterpriseInstitute,Inc.

Sayer,NatalieJ.andBruceWilliams.2007.LeanForDummies.JohnWiley&Sons.

Schwaber,Ken.2007.AgileProjectManagementwithScrum.MicrosoftPress.

Schwaber,Ken;Sutherland,Jeff.2010.ScrumGuide.Scrum.org.http://www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf.

Shore,James.2007.TheArtofAgileDevelopment.O'ReillyMedia.

Sims,Chris.March23,2009.StoryMappingGivesContexttoUserStories.InfoQ.com.http://www.infoq.com/news/2009/03/story‐map.

Womack,andJamesP.,andDanielT.Jones.2003.LeanThinking:BanishWasteandCreateWealthinYourCorporation,RevisedandUpdate.FreePress.

Wells,Don.2009.IterationPlanning.XPProgramming.com.http://www.extremeprogramming.org/rules/iterationplanning.html.

Wynne,Matt,andAslakHellesøy.2011.TheCucumberBook:BehaviourDrivenDevelopmentforTestersandDevelopers.ThePragmaticBookshelf.

114 The Agile Extension to the BABOK® Guide

Page 123: The Agile Extension

appendix C Contributors

IIBA®andTheAgileAlliance®wouldliketothankthefollowingcontributorstoTheAgileExtensiontotheBABOK®Guide.WithouttheireffortsandcommitmentTheAgileExtensiontotheBABOK®Guidewouldnotbepossible.

November 2011 Release• KevinBrennan• SusanBlock• DavidC.Cook• PeterGordon• EllenGottesdiener• ShaneHastie• BrianHemker• MarshaHughes• ChrisMatts• AliMazer• LuizClaudioParzianello• CarolScalice• DennisStevens

August 2010 Release• SusanBlock• PascalVanCauwenberghe• SteveErlank• EllenGottesdeiner• ShaneHastie• MarshaHughes• AliMazer• MaureenMcVey• DavidMorris• LuizClaudioParzianello• DennisStevens

November2011DraftforPublicReview 115

Page 124: The Agile Extension

Contributors

116 The Agile Extension to the BABOK® Guide

Page 125: The Agile Extension

IIBA International Institute of Business Analysis

About International Institute of Business Analysis (IIBA)

International Institute ofBusinessAnalysis (IIBA) is anindependentnon‐profitprofessionalassociationservingthe growing field of Business Analysis. For individualsworking in a broad range of roles ‐ business analysis,systemsanalysis,requirementsanalysisormanagement,project management, consulting, process improvementandmore ‐ IIBA®canhelpyoudoyour jobbetter andenhanceyourprofessionallife.

IIBA has created the Business Analysis Body ofKnowledge® (BABOK®) Guide, the collection ofknowledge within the BA profession, reflecting thecurrent generally accepted practices.We help businessanalystsdeveloptheirskillsandfurthertheircareersbyproviding access to unique and relevant content.Membershipbenefitsincludeaccesstothefollowing:

• CopyofthelatestBABOK®Guide

• Online library with access to hundreds of BArelatedbooks

• Webinars on a range of professionaldevelopmenttopics

• BA CompetencyModel and BA Self‐AssessmentTool

• JobsearchcapabilitiesusingtheCareerCenter

• Discounted fees to apply for, re‐certify and sitexams for professional accreditation Certified

Business Analysis ProfessionalTM (CBAP®)designation and Certification of Competency in

BusinessAnalysisTM(CCBATM)designation.

• Monthly"BAConnection"newsletter

• Chapters

IIBAisdedicatedtothedevelopmentandmaintenanceofstandardsforthepracticeofbusinessanalysis,andforthecertificationandrecognitionofpractitioners.

Certified Business Analysis ProfessionalTM (CBAP®) TheCertifiedBusinessAnalysisProfessionalTM(CBAP®)designation is aprofessional certification for individualswithextensivebusinessanalysisexperience.Withatleast7500hoursofhands‐onBAexperience,CBAP®recipientsaretheelite,seniormembersoftheBAcommunity.

Certification of Competency in Business AnalysisTM (CCBATM) TheCertification of Competency inBusinessAnalysisTM

(CCBATM) designation is a professional certification forbusiness analysis practitioners who want to berecognized for their expertise and skills by earningformalrecognition.Withatleast3750hoursofhands‐onBAexperience,theyhavedevelopedessentialBAskills.

MoreinformationregardingCertificationscanbefoundatwww.iiba.org/certification.

IIBA® Chapters IIBA®Chaptersadvancethemissionandobjectivesoftheorganization by promoting professional standards andpractices at the local level. Ongoing professionaldevelopmentisakeybenefitofyourIIBA®membershipand is supported at the chapter level through activities,meetings, and educational programs. A list of IIBA®Chapters andmore information regarding them can befoundatwww.iiba.org/chapters.

Membership in IIBA®When you join IIBA®, you become a member of aninternational association dedicated to developing andpromoting the Business Analysis profession. Moreinformation regarding IIBA® can be found atwww.iiba.org.

www.iiba.org

Page 126: The Agile Extension

The Agile Alliance

The Agile Alliance is a nonprofit organization with global membership, committed to advancing Agile developmentprinciplesandpractices.AgileAlliancesupportsthosewhoexploreandapplyAgileprinciplesandpracticesinordertomakethesoftwareindustrymoreproductive,humaneandsustainable.Weshareourpassiontodeliversoftwarebettereveryday.

Agilemethodshaveproventheireffectivenessandaretransformingthesoftwareindustry.Asagilemethodsevolveandextend,AgileAlliance fosters a communitywhereorganizationsand individuals findways to transition to andadvanceAgilepractices,regardlessofmethodology.

TheAgileAlliancewebsiteoffersan informationhubwheremembers canaccessawidevarietyof resources—anarticlelibrary,videos,presentations,localusergrouplistingsandlinkstoadditionalagileresources.

Agile Alliance organizes the largest, most diverse and comprehensive agile conferences each year. Conferenceparticipants learn from hundreds of sessions spanning the entire agile organization and lifecycle, make businessconnections,andconversewithagilethoughtleaders,practitioners,andauthors.

Inadditiontothesemajorconferences,AgileAllianceprovidesfinancialandorganizationalsupporttoscoresoflocal,regionalandspecialinterestconferencesandusergroupsworldwide.

TheAgileAllianceoperatesontheprinciplesoftheAgileManifesto.http://www.agilemanifesto.org

TheAgileAlliancewebsiteis:www.agilealliance.org.

www.iiba.org

Page 127: The Agile Extension
Page 128: The Agile Extension

Changing the Way Organizations Change™Business analysis is the set of tasks and techniques used towork as a liaison amongstakeholders in oder to understand the structure, policies, and operations of anorganization, and to recommend solutions that enable the organization to achieve itsgoals.

Business analysis involves understanding how organizations function to accomplishtheir purposes and defining the capabilities an organization requires to provideproducts and services to external stakeholders. It includes the definition oforganizational goals, understanding how those goals connect to specific objectives,determiningthecoursesofactionthatanorganizationhastoundertaketoachievethosegoalsandobjectives,anddefininghowthevariousorganizationalunitsandstakeholderswithinandoutsidethatorganizationinteract.

TheAgileExtension to theBABOK®Guide contains descriptions of generally acceptedpractices and techniques used by those to practice business analysis within an agiledevelopment framework. The content has been verified through reviews bypractitioners,consultationwithrecognizedexpertsinthefield,andclosecollaborationbetweenIIBA®andtheAgileAlliance®.

The BABOK®Guide is recognized around the world as a key tool for the practice ofbusinessanalysisandhasbecomeawidely‐acceptedstandardfortheprofession,withover 200,000 copies downloaded from the IIBA®website. TheAgileExtension to theBABOK® Guide builds on the practices found in the BABOK® Guide, and describesbusinessanalysisareasofknowledge,theirassociatedactivitiesandtasks,andtheskillsnecessary to be effective in their execution within the framework of agile softwaredevelopment.