The Agile Extension

International Institute
of Business Analysis
TM
IIBA
TheAgileExtensiontotheBABOK
Guideisacollaborativeeffortbythe
InternationalInstituteofBusinessAnalysisandtheAgileAlliance.
November2011DraftforPublicReview
The Agile Extension to the BABOK
Guide
www.iiba.org
Agile Extension to the
BABOK
Guide
November 2011 Draft
for Public Review
InternationalInstituteofBusinessAnalysis,Toronto,Ontario,Canada
InternationalInstituteofBusinessAnalysis.Allrightsreserved.
Thisdocumentisprovidedtothebusinessanalysiscommunityforeducational
purposes.IIBA
warrantsthatitissuitableforanyotherpurposeandmakesno
expressedorimpliedwarrantyofanykindandassumesnoresponsibilityforerrors
oromissions.Noliabilityisassumedforincidentalorconsequentialdamagesin
connectionwithorarisingoutoftheuseoftheinformationcontainedherein.
IIBA
,theIIBA
logo,BABOK
andBusinessAnalysisBodyofKnowledge
are
registeredtrademarksownedbyInternationalInstituteofBusinessAnalysis.CBAP
andCCBA
areregisteredcertificationmarksownedbyInternationalInstituteof
BusinessAnalysis.CertifiedBusinessAnalysisProfessional,Certificationof
CompetencyinBusinessAnalysis,EndorsedEducationProvider,EEPandtheEEP
logoaretrademarksownedbyInternationalInstituteofBusinessAnalysis.
TheAgileAlliance
andtheAgileAlliancelogoarearegisteredtrademarksownedby
TheAgileAlliance.
Nochallengetothestatusorownershipoftheseoranyothertrademarkedterms
containedhereinisintendedbytheInternationalInstituteBusinessAnalysis.
ThisdraftoftheAgileExtensiontotheBABOK
Guideisprovidedtothecommunity
forreviewandfeedbackandmaynotbeusedforanyotherpurpose.Inorderto
providefeedback,pleaseenteryourcommentsonourfeedbackwebform.
November2011DraftforPublicReview i
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.............................................................................................................. 7
Backlogs ........................................................................................................................... 8
Sprint Planning and Execution...................................................................................... 8
Roles and Responsibilities.............................................................................................. 9
Business Analysis in Scrum............................................................................................ 9
Techniques .................................................................................................................... 11
Extreme Programming (XP) ........................................................................ 11
User Stories................................................................................................................... 11
Release Planning and Execution ................................................................................ 12
Roles and Responsibilities........................................................................................... 13
Business Analysis in XP................................................................................................ 13
Techniques .................................................................................................................... 14
Kanban.......................................................................................................... 14
Queues .......................................................................................................................... 15
The Kanban Board....................................................................................................... 15
Roles & Responsibilities ............................................................................................... 16
Business Analysis in Kanban....................................................................................... 16
Comparison of Agile Life-cycles................................................................. 18
Selecting an Agile Methodology or Framework......................................................... 19
Agile Levels of Planning .............................................................................. 20
Agile Levels of Planning ............................................................................................... 20
Chapter 3: Knowledge Areas 25
Mapping Techniques to Knowledge Areas ............................................... 25
ii The Agile Extension to the BABOK Guide
Business Analysis Planning and Monitoring............................................................. 25
Elicitation...................................................................................................................... 28
Requirements Management and Communication................................................... 30
Enterprise Analysis....................................................................................................... 32
Requirements Analysis ................................................................................................ 34
Solution Assessment and Validation ......................................................................... 36
Business 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....................................................................................... 46
Personas ....................................................................................................................... 49
Value Stream Mapping................................................................................................ 51
Think as a Customer ................................................................................... 55
Story Decomposition ................................................................................................... 56
Story Elaboration......................................................................................................... 59
Story Mapping.............................................................................................................. 61
User Story ..................................................................................................................... 64
Storyboarding............................................................................................................... 67
Analyze to Determine What is Valuable.................................................... 70
Backlog Management.................................................................................................. 70
Business Value Definition............................................................................................ 73
Kano Analysis ............................................................................................................... 74
MoSCoW Prioritization................................................................................................ 77
Purpose Alignment Model........................................................................................... 79
Get Real Using Examples ............................................................................ 81
Behaviour Driven Development ................................................................................. 82
Understand What is Doable....................................................................... 84
Estimation..................................................................................................................... 85
Planning Workshop ..................................................................................................... 87
Real Options ................................................................................................................. 89
Stimulate Collaboration & Continuous Improvement............................ 93
Collaborative Games ................................................................................................... 94
Retrospectives............................................................................................................... 96
Avoid Waste.................................................................................................. 98
Lightweight Documentation........................................................................................ 99
November2011DraftforPublicReview iii
appendix A Glossary 103
appendix B Bibliography 111
appendix C Contributors 115
iv The Agile Extension to the BABOK Guide
November2011DraftforPublicReview 1
chapter 1
Introduction to the Agile Extension
1.1 What is the Agile Extension to the BABOK

Guide?
Guidedescribesbusinessanalysis
areasofknowledge,theirassociatedactivitiesandtasks,andtheskills
necessarytobeeffectiveintheirexecutionwithintheframeworkof
agilesoftwaredevelopment.
ThepurposeoftheAgileExtensionistoactasabusinessanalysis
primerforagilesoftwaredevelopmentmethodologiesandprovide
businessanalysispractitionerswith:
anintroductiontoagilepracticesforbusinessanalysis,
anoverviewofbusinessanalysistechniquesforagile
practitioners,
asetofdefinitionsoftypicalworkingpracticesusedbybusiness
analystsworkingonagileprojects,and
anoverviewofthenewandchangedroles,skills,and
competenciesforbusinessanalysis.
TheAgileExtensionisofvaluetobusinessanalystsnewtoagile,aswell
asthoseexperiencedinagilemethodologies.Bothgroups,andall
thoseinbetween,willfindhelpfulinformationsuchasanintroduction
tothepracticeofbusinessanalysisinanagilecontext,themappingof
existingbusinessanalysistechniquestoagilepractices,andinclusion
oftechniquesthatarespecifictothepracticeofbusinessanalysisin
theagileworld.
AstheAgileExtensionhighlights,anymemberofanagileteammay
engageintheprocessofbusinessanalysis.Tothatend,eachpersonon
anagileteamwillbenefitfromhavingasetofpracticesandtoolsin
whichtheycanselectfromwhileworkinginanyoneofthedifferent
flavorsofagile.
IntheAgileExtension,wehavecalledparticularattentiontothemind
setabusinessanalysispractitionermusthaveinordertoeffectively
contributetodeliveryofongoingvaluetostakeholders.Wehavealso
What does Agile Mean for Business Analysis? Introduction to the Agile Extension
2 The Agile Extension to the BABOK Guide
describedanumberoftechniquesnotfoundintheexistingBABOK
Guide,andexpandedonothersthatneededtobedescribedingreater
detail.Manyoftheapproachesdescribedhere,andthemindsetwe
describe,willprovevaluabletobusinessanalysisinanymethodology
andenvironment.Businessanalystsshouldalwaysworktoensure
thatrequirementsarealignedwithorganizationalgoalsandobjectives
andthatallstakeholdershaveasharedunderstandingofthosegoals,
objectives,andrequirements.Theymustalsoworktomanagerisks
andvalidatethattherequirements,ifdelivered,willcreaterealvalue
forstakeholders.Agilemethodologiescanhelpusfindnewwaystodo
thesethingsthatsupportcontinuousdeliveryofworkingsoftware,but
theresponsibilitytodothesethingsisinherenttotheprofessionof
businessanalysis.
1.2 What does Agile Mean for Business Analysis?
Muchlikeothermethodologies,businessanalysisiscentraltothe
successofagileprojects.Businessanalysisisnecessarytoenablea
diversegroupofcustomerstospeakwithasinglevoice.Thiswork
maybedonebyoneofmoremembersofanagileteam.
Intheagileworld,softwarerequirementsaredevelopedthrough
continualexplorationofthebusinessneed.Requirementsaregathered
andrefinedthroughaniterativeprocessofplanning,defining
acceptancecriteria,prioritizing,developing,andreviewingtheresults.
Throughouttheiterativeplanningandanalysisofrequirements,
businessanalysispractitionersmustconstantlyensurethatthe
featuresrequestedbytheusersalignwiththeproductsbusiness
goals,especiallyasthebusinessgoalsevolveandchangeovertime.
Agilebusinessanalysisisprimarilyaboutincreasingthedeliveringof
businessvaluetothesponsorsandcustomersoftheproject/product
beingdeveloped.Agilebusinessanalysisalignswiththevaluesand
principlesoftheAgileManifesto(www.agilemanifesto.org):
Wevalueindividualsandinteractionsoverprocessesandtools.
Ourhighestpriorityistosatisfyourcustomerthroughearly
andcontinuousdeliveryofvaluablesoftware.
Workingsoftwareistheprimarymeasureofprogress.
Agilebusinessanalysisisaboutensuringtherightinformationis
availabletothedevelopmentteamintherightlevelofdetailatthe
righttimesotheycanbuildtherightproduct.
Introduction to the Agile Extension What does Agile Mean for Business Analysis?
Thetechniquesofbusinessanalysisdonotchangedramaticallyinthe
agileenvironment.However,thetimingandhowtheyareuseddo
change.Artifactssuchaspersonas,datamodels,storymaps,and
businessrulescontinuetobeemployed,butarekeptaslightweightas
possible.Lowfidelityartifacts,suchasdiagrams,maps,andlists,
providemorevaluetoanagileprojectthanlong,textualrequirement
descriptionsorspecifications.Lowfidelityartifactsaredevelopedfor
thesolepurposeofbuildingthesoftwareforaspecificiterationand
onlyneedtobeintelligibletotheteamduringthecourseofthe
iteration.Longlivedartifacts,ontheotherhand,areintendedtobe
utilizedbeyondthescopeofdevelopment.Longlivedartifactsmay
includethebusinesscase,charter,anddocumentationthatisusedto
communicatewhatthesoftwaredoesandwhyitdoesit.
Agileofferstheopportunityforbusinessanalysistobenefitfromthe
frequentfeedbackprovidedbythebusiness.Byreviewingtheresults
ofsuccessiveiterationswiththebusinessstakeholders,analystshave
theopportunityto
refinetheproductsrequirementstoensuretheymaintain
cohesionwiththebusinessneedsfortheproduct,and
identifyandmitigateriskearlyintheproject.
Forthemostpart,inagileprojects,highriskitemsareaddressedin
earlyiterations.Thisallowstheteamtomitigateissuesandthe
possiblereworkrequiredifriskitemsarenotaddresseduntillaterin
theproject.Facilitatingriskdiscoveryandassistingtheteamin
retainingfocusedoneffectiveriskmitigationiscentraltotheanalysts
roleonanagileteam.
Iterativedevelopmentprocessesprovideopportunitiesforincreased
efficienciesintheworkofbusinessanalysis.Inwaterfallprojects,
requirementsaredevelopedintheirentiretypriortothedevelopment
phase.Asriskelementsareuncoveredandbusinessneedsevolve,
certainrequirementsmaychangeorbeeliminatedoutright;making
theworkeffortputintothoserequirementswasted.Byprovidingjust
intimerequirements,thereislessreworkofrequirementsbecause
onlytherequirementsrequiredforthecurrentreleasearedefinedin
detailanddeveloped.
What does Agile Mean for Business Analysts? Introduction to the Agile Extension
1.3 What does Agile Mean for Business Analysts?
Theearlystagesofagilesevolutionfrequentlyreliedonasingle
individualbeingabletomakeallthedecisionsregardingthe
developmentofthesoftware.Asagileprojectsgrowinsizeand
breadth,andbecomeadoptedbylargerandmorediverse
organizations,theroleofbusinessanalysthasbecomeavital
contributor.Theanalystplaysadefiningroleincreatingasinglevision
fortheproductoutofadiversesetofneedsandwishesfrommultiple
stakeholders.
TheAgileManifestousesthetermdeveloperstodescribetheteam
whoworkonbuildingtheproduct.Thisisacrossfunctionalteamof
skilledindividualswhobringavarietyofexpertisetobearonthe
processofbuildingasoftwareproduct.Theskillsthatdevelopers
requiretodothisincludebusinessanalysis,technicaldesign,
programminginvariouslanguagesandtools,testing,UIdesign,
technicalwriting,architectureandwhateverelseisneededtoproduce
workingsoftware.Workingsoftwareisaproductwhichisinthe
productionenvironmentdeliveringvalueforourcustomers.
Thereareavarietyofwaysabusinessanalystcanbeengagedonan
Agileproject:
Insomeprojectsadedicatedbusinessanalystroleis
unnecessary.Thisisnottosaythatbusinessanalysisisnot
conductedduringthecourseoftheproject,onlythatitmaybe
donebyanymember,ormembers,oftheoveralldevelopment
team.
Inmorecomplexenvironmentstheanalystmightbethe
facilitator,bringingdivergentbusinessstakeholderstogether
andhelpingthemspeakwithasinglevoicesotheprojectteam
arenotconfusedbycontradictoryandconflictingperspectives.
Theanalystmightactastheproductowner/customer
representativewheretheyareempoweredbythebusinessto
makedecisionsonproductfeaturesandpriority.
Theanalystcouldactasasurrogateproductowner,in
situationswherethebusinessproductownernotavailable.
Theanalystmightactasthesecondincommandtoabusiness
productownerwithlimitedavailability.
Ananalystcouldtaketheroleofbusinesscoachinan
environmentwherethebusinessproductowneriscompetent
andcommitted,buthaslimitedITprojectexperienceandthe
restofthedevelopmentteamarelackingindomainknowledge.
Introduction to the Agile Extension What does Agile Mean for Business Analysts?
Irrespectiveofjobtitles,businessanalysisisaboutensuringthe
projectisabletodeliverthemaximumvalueforcustomersand
adaptingtotheevolvingbusinessneeds.
Thetechniquesutilizedinagilemethodologiesdonotrepresenta
majorshiftforbusinessanalysts.Theycontinuetoutilizemanyofthe
toolsandtechniquesdefinedinAGuidetotheBusinessAnalysisBodyof
Knowledge
(BABOK
Guide).Whathaschangedisthetimingandthe
usageofthesetechniques.Therigorsanddemandsofagileprojects
alsorequirebusinessanalyststoutilizeanddevelopskillsthatthey
maynothavepreviouslyexercisedatahighlevel.Inanagile
environment,thesuccessofthebusinessanalystreliesincreasinglyon
suchinterpersonalskillsascommunication,facilitation,coachingand
negotiation.Theseskillsarecertainlycentraltothesuccessofan
analystinanyenvironment;however,duetotheinterconnectedness
ofagileteams,iftheseskillsarenotbeingeffectivelyutilized,the
numberofrequeststhatcanbeadequatelyunderstandandprioritized
decreases,resultinginfeweritemsmakingitintothesolution
implementationforagivenrelease.
Analystsarerequiredtoapproachrequirementsfroma360degree
perspective.Theyarerequiredtoworkwiththebusinesssponsorona
strategiclevel,anddefinehowtheproposedproductorfeaturealigns
withtheorganizationsportfolioandstrategy.Theymustthenwork
withthebusinessandprojectteamtobreakthisvisiondowninto
requirementsthatsupporteffectiveandaccurateestimation.Inan
agileprojectthisisdoneforeachiterativerelease,asopposedtothe
singlerequirementsphasethatexistsinplandrivenmethodologies.
Theanalystdeliversjustintime,detailedrequirementstothe
developmentteamsotheycanbuildonlywhatisrequiredfora
specificiteration.
Businessanalystsplayakeyroleinfacilitatingasharedunderstanding
ofthebusinessneedfortheprojectwithallstakeholders.Itistherole
ofthebusinessanalysttoensurethereisashared,agreeduponvision
fortheproductacrosstheentiredeliveryteam.Intheagile
environment,understandingandsynthesizingperspectivesalongside
theabilitytoholdsuccessfulconversationsreplacetheneedfor
formal,detailed,longtermartifactssuchasrequirementdocuments.
Oneofthekeyelementsforabusinessanalystworkinginanagile
environmentistheabilitytousefeedbacktodrivechange.Itis
incumbentontheanalysttoconstantlyreviewrequirementswiththe
What makes a Business Analyst Successful on an Agile Team? Introduction to the Agile Extension
businessstakeholdersandensurethatanyshiftsinbusinessneedsare
accuratelyreflectedinfutureiterationsoftheproduct.
1.4 What makes a Business Analyst Successful on an
Agile Team?
Theverynatureofagilemethodologiesrequiresallteammembersto
beoperatingataveryhighlevelofcompetency,skill,and
effectiveness.Thisisespeciallytrueforbusinessanalysts.Tobe
productiveonanagileteam,businessanalystshavetobeontopof
theirgame.Onsuccessfulagileteams,thebusinessanalystisan
integralcomponentofthedeliveryteam.Theyareactiveparticipants,
ifnottheactualfacilitatorsofplanning,analyzing,testing,and
demonstratingactivities.
Thebusinessanalystplaysacentralroleinensuringthattheproduct
roadmapclearlydefinestheproductsstrategicalignmenttothe
businessneed.Theanalystholdssharedresponsibilityindefiningthe
strategiccriteriaforcompletionoftheproject.Thisrequiresthe
analysttoexerciseanextremelyhighlevelofskillincommunication,
facilitation,andnegotiation.Theyrequiretheabilitytolistentoand
understandfeedbackfromallstakeholdersandusethisfeedbackto
drivethechangesrequiredtotherequirementsandprioritiesofthe
project.
chapter 2
Business Analysis in Agile Life-cycles
Agileisatermusedtodescribeanumberofiterativedevelopment
methodologiesthathavedevelopedovertime.Commontraitsamongst
agilemethodologiesincludefrequentproductreleases,highlevelsof
realtimecollaborationwithintheprojectteamandwithcustomers,
reducedtimeintensivedocumentation,andregular,recurring
assessmentsofvalueandrisktoallowforchange.Itisimportantto
notethatthoughallagilemethodologiesareiterative,notalliterative
methodologiesareagile.Agilemethodologiesareasubsetofiterative
softwaredevelopment.Afewexamplesofagilemethodologiesinclude
Scrum,ExtremeProgramming(XP),Kanban,Crystal,DynamicSystems
DevelopmentMethod(DSDM),FeatureDrivenDevelopment,and
AdaptiveSoftwareDevelopment,tonameafew.Eachmethodologyhas
itsownuniquesetofcharacteristicsthatallowteamstoselecta
certainmethodologythatbestsuitstheprojectathand.Itiscommon
forprojectteamstoblendcharacteristicsfrommorethanoneagile
methodologybasedonuniqueteamcomposition,skills,experience,
operatingenvironment,andotherfactors.
Inordertoeffectivelymanage,elicit,analyze,document,communicate,
andvalidaterequirements,businessanalystsmustbeableto
understandthecharacteristicsofthespecificagilemethodologythey
areworkingwith.Whilewedescribeafewofthepredominantagile
methodologiesinthisAgileExtension,beforestartinganagileprojectit
isimportanttospendsometimeresearchingthevarious
methodologiesandwhatisdifferentabouteach.
2.1 Scrum
Scrumisoneofthemostpredominantagileprocessframeworksinuse
today.IntheScrumframework,workonaprojectisperformedina
seriesofiterations,calledsprints,whichgenerallylastfrom2to4
weeks.Attheendofeachsprint,theteammustproduceworking
softwareofahighenoughqualitythatitcouldpotentiallybeshipped
orotherwisedeliveredtoacustomer.WithintheScrumframework
Scrum Business Analysis in Agile Life-cycles
therearefourformalmeetings,knownasceremonies:sprintplanning,
thedailyscrum,sprintreviews,andsprintretrospectives.
2.1.1 Backlogs
IntheScrumframeworkaproductbackloglistsalloftherequirements
forasolution,includingbothcustomerandtechnicalrequirements.
Thebacklogservesasawishlistfortheproduct.Astheteam
collaborateswiththecustomerfortheproject,thebacklogis
populatedtokeeptrackofeachrequest.Thisbacklogisconstantly
prioritized,suchthatatanygiventimeitcanbeusedtoidentifyhigh
priorityrequestsforthesolutionbeingdeveloped.Atthebeginningof
eachsprint,inthesprintplanningceremony,theteamreviewsthe
prioritizedproductbacklogandidentifiesthehighestpriorityitems
thatcanbecompletedwithinthesprintperiod.Theselecteditemsare
thenplacedonasprintbacklog.Thesprintbacklogoutlinesthe
sprint'sgoalsandthesetoftasksrequiredtoachievethosegoals.
2.1.2 Sprint Planning and Execution
Duringthesprint,theteamrefinestheirunderstandingoftheselected
itemsandworkstoensurethattheyarecompletedwithindefined
timelimitofthesprint.Assprintsareexecuted,theteammeetsonce
perday(referredtoasthedailyscrummeeting)tobrieflydiscuss
whattheyareworkingonandidentifyanyblockersthatmayprevent
themfromcompletingtheirwork.Attheendofthesprint,theteam
deliversworkingandtestedsoftwarethatfullyimplementsthe
selectedbacklogitems.Thesprintisthenclosedoffwithacustomer,
orsprint,reviewandaretrospective.Duringthecustomerreview,a
demonstrationofthesoftwareisprovidedandthecustomerprovides
feedback.Duringtheretrospective,theteammeetsandcollaboratesto
findwaystoimproveboththeproductandtheirprocessesusedto
delivertheproduct.Boththecustomerreviewandtheretrospective
mayidentifyadditionitemsthatfeedintotheproductbacklog.These
itemsarethenusedtoreprioritizetheproductbacklogforthenext
sprintplanningsession.
Business Analysis in Agile Life-cycles Scrum
Thefollowingillustrationdemonstratesatypicalscrumlifecycle.
FIGURE 2.1 ScrumLifecycle
2.1.3 Roles and Responsibilities
InScrum,therearethreeroles:
ProductOwner.Theproductownerisresponsiblefor
maintainingthelistofworktobeperformedandperforming
mostbusinessanalysisactivities.Itisimportanttonotethatthe
productownerisnotnecessarilyabusinessanalyst,ratherthe
individualontheteammostresponsibleforwhathasbeen
consideredtraditionalbusinessanalysisactivities.
ScrumMaster.Thescrummasterisresponsibleformanaging
theScrumprocessandmanaginganyblockersthatmayprevent
theteamfromaccomplishingwork.
TheTeam.Theteamisresponsiblefordevelopinganddelivering
theproduct.
2.1.4 Business Analysis in Scrum
Scrumdoesnotaddressbusinessanalysisactivitiesindetailandmany
oftheseactivitiesoccurasimplicitstepsinthescrumframework.The
followingillustrationshowsthetypicalscrumlifecyclewithbusiness
analysistechniquessuperimposed.

8
S
8

S
Scrum Business Analysis in Agile Life-cycles
FIGURE 2.2 BusinessAnalysisinScrum
Thebuildingandmaintenanceoftheproductbacklogisasignificant
businessanalysisactivitythatfallsexplicitlyoutsidethescopeofthe
scrumframework(althoughothermethodologieshaveaddressed
this).Thebacklogisbuiltthroughacombinationofenterpriseanalysis
work(identifyinggapsandnewcapabilitiesrequiredtoaccomplish
organizationalgoals,anddefiningtheirvaluetotheorganization)and
solutionassessmentandvalidation(identifyingwaysinwhichthe
existingsolutioncanbeenhancedtobetterdeliverbusinessvalue).
Withinasprint,businessanalysisactivitiesfocusondefiningthe
requirementsforthebacklogitemsbeingworkedonandthe
acceptancecriteriaforthoseitems.Thismethodisfrequentlyreferred
toasjustintimerequirementsgathering;developingonlywhatis
requiredforthecurrentsprintandonlydonetothelevelofdetail
requiredtoenabletheteamtobuildtheproductandacceptance
criteria.Intraditionalmethods,requirementsdocumentationis
frequentlyusedasthedocumentationforthesolution.InScrum,asin
mostotheragilemethods,documentationiscreatedaftertheproduct
isbuilttocapturetheteamsknowledge,notdefineanexpectedor
desiredoutcome.Mostfrequentlythebacklogdocumentationcreated
duringeachsprintservesassufficientdocumentationfortheproject.

8
S
8

S
L
A
8
A
SA v
S A v
Business Analysis in Agile Life-cycles Extreme Programming (XP)
2.1.5 Techniques
BacklogManagement:Backlogmanagementistheprimarymethod
ofhandlingbothrequirementsprioritizationandchangemanagement
inmostagilemethods.Analternativetobacklogmanagementisa
kanbanboard(seeTheKanbanBoardonpage15).
Retrospectives:Retrospectivesareacommonpracticeusedbyagile
teamsseekingtoimprovetheirwaysofworking.Businessanalysts
shouldlookforfeedbackontherequirementstheyprovidetotheteam
andhowandwhenthoserequirementsareprovidedinordertofind
waystoimprovetheirprocesses.
2.2 Extreme Programming (XP)
ExtremePrograming(XP)beganbeingusedbydevelopmentteamsin
themid1990s.Likeotheragilemethodologies,XPisiterativein
natureandprovidessmallreleasesattheendofeachiteration.XPs
primaryfocusisonthetechnicalaspectsofagilesoftware
developmentandisbasedon12practicesinfourcategories:
TABLE 2.1 ExtremeProgrammingCategories
2.2.1 User Stories
XPusestheconceptofuserstoriesasacentralmechanismtodefine
requirements.Userstoriesaresimilartotheconceptoftheproduct
backlogfoundinScrum.Theyarecreatedbyusersofthesystemto
definefeaturesandfunctionalitytobeincludedinthesolution.User
storiesdonotcontaingreatdetailandareusedto
prioritizeworkintoiterations,
identifyriskassociatedwitharequest,
estimatetheeffortrequiredtodelivertherequest,and
Fine Scale Feedback Continuous Process
Shared
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
Extreme Programming (XP) Business Analysis in Agile Life-cycles
establishaconversationbetweentheteamandtheproduct
owneraroundthesubjectoftherealbusinessneed,inorderto
createacommonunderstandingofwhathastobedone
2.2.2 Release Planning and Execution
XPreliesonthreelevelsofplanning:
releaseplanning,
iterationplanning,and
anddailyplanning.
Areleaseplanidentifiesthenextsetofusablefeaturethatcouldmake
uparelease.Thereareoftenseveraliterationsworthofworkbecause
theproductisreleaseready.Iterationplanningservestoplaneach
incrementaliterationthatwillultimatelyresultinareleasable
product.Finally,indailyplanningtheteamplansouteachday's
activitiestoensuretheteamisonscheduleandidentifyrisksthatmay
havearisen.
InXP,releaseplansareusedtotrackanddescribewhatfeaturesor
functionalityistobedeliveredineachproductrelease.Therelease
planissimilartotheconceptofthesprintbackloginthescrum
framework.Iterationplanningmeetingsarethenusedasavehiclefor
teamcollaborationinplanningthecomingiteration.Astheteam
workstoscheduletherelease,theuserstoriesareorderedbasedon
themostimportantfeaturestothecustomer,ensuringthatthemost
importantfeaturesarealwaysdeliveredfirst.Onajustintimebasis,
storiesaredecomposedintotheirgranularfunctionalrequirementsin
atechniqueknownasstorydecomposition.Then,throughstory
elaboration,theteamidentifiesthedetaileddesignandacceptance
criteriaforthestory.
Whileaniterationisunderway,XPisalsosimilartoScruminthatit
utilizesdailymeetingsasthekeycommunicationvehiclefortheteam,
calledthedailystandup.Thisdailystandupmeetingisusedto
facilitatedailyplanningactivitiesandreviewprogresssincetheprior
day'sstandup.Inpractice,teamsemployingtheXPmethodology
frequentlycombinesuchelementsascadence,roles,andceremonies
(suchassprintplanningandsprintreviews)fromthescrum
framework.
Business Analysis in Agile Life-cycles Extreme Programming (XP)
ThefollowingdiagramprovidesanoverviewoftheXPmodel.
FIGURE 2.3 ExtremeProgrammingModel
2.2.3 Roles and Responsibilities
InExtremeProgramingtherearethreekeyroles.
Customer.Thecustomercreatesandprioritizestheuserstories
andpreformsriskanalysis.
Developer.Thedevelopercommunicatesdirectlywiththe
customerandbuildsonlywhatisnecessarytodeliveroneach
iteration.
Tracker.Thetrackerkeepstrackofthescheduleandthemetrics.
2.2.4 Business Analysis in XP
WhileXPdoesfocusonvaluedrivendevelopment,itdoesnot
explicitlyaddressbusinessanalysisactivities.XPreliesonthe
fundamentalassumptionthatthecustomerroleisfilledbyasmall
numberofpeoplewhoknowwhatthemostvaluablefeatureswillbe.
WhenXPisappliedatalargerscale,orwithcustomerswhodonot
haveaclearvisionoftheincrementalvalueoffeatures,abusiness
analystaddssignificantvalueinfacilitatingandnegotiatingwith
stakeholderstoreachasharedunderstandingofwhatthemost
valuabledeliverableswillbe.Abusinessanalystcanalsocontributeby
facilitatingstorymapping,atechniqueinwhichagraphical
representationofstoriesalongatimecontinuumiscreated.Thestory
mapisusedtoidentifyrisksanddependenciesamongstandbetween
Kanban Business Analysis in Agile Life-cycles
theuserstoriestooptimizethevaluedeliveredbyeachincremental
storyimplementation.
IntraditionalXP,theuserstoriesarecreatedandmanageddirectlyby
theuser.Thiscanleadtounfilteredrequirementsthatareatriskfor
constrainingasolutionwithoutconsiderationforrootcauseor
applicabilitytoothercustomergroups.Businessanalysisskillscanbe
usedtoensureunderlyingproblemsarebeingaddressedinawaythat
worksformost,ifnotall,ofthestakeholdersontheproject,aswellas
ensurethoroughacceptancecriteriahavebeencollectedforeachuser
story.Onprojectswherethereisadedicatedbusinessanalyst,this
personmayactasabrokerorfilterfortheuserstoriesthatare
generatedbythecustomer,oftenperformingthestorydecomposition
andelaborationactivities.
2.2.5 Techniques
UserStories:Userstoriesidentifywhichrolesthestoryprovides
valueandthereforeidentifythestakeholderswhocanelaborateon
thatvalue.
StoryMapping:Storymapsshowrelationshipsbetweenuserstories
andlargeractivitiesthattheusermustbeabletoaccomplish.
StoryDecomposition:Epics,features,orminimallymarketable
features(MMF)tiegroupsofuserstoriestogetherintolargerpackages
thatcanbediscussedwithstakeholders.
StoryElaboration:Definesthedetaileddesignandacceptance
criteriaforauserstoryonajustintime/justenoughbasis.
2.3 Kanban
ScrumandXPareframeworksthatdefinesetsofroles,ceremonies,and
practicesforproducedelivery.Inthecontextofsoftwaredevelopment,
Kanbanisamethodologyformanagingtheflowofworktoallowfor
evolutionarychange.WithrootsintheTheoryofConstraintsandlean
productdevelopment,Kanbanhasfourkeyprinciples:
visualizethework,
limitworkinprocess,
focusonflow,and
continuallyimprove.
Business Analysis in Agile Life-cycles Kanban
Unliketheotheragileframeworksthatwehavediscussed,Kanban
developmentdoesnotrequirefixediterations.Workmovesthrough
thedevelopmentprocessasacontinuousflowofactivity.Akeyfeature
ofKanbanistolimittheamountofworkunderwayatanyonetime.In
thismethodologytheteamonlyworksonafixednumberofitemsat
anyonetimeandworkmayonlybeginonanewitemwhenitis
requiredtomaintainflowdownstreamandafterthepreviousitemhas
beencompleted.
2.3.1 Queues
Kanbanreliesontheuseofworkqueuestomanagetheflowof
activitiesthatmusttakeplacetodeliveraworkingproduct.Theformat
andcontentforworkqueuesislessprescriptiveinthismethodology
thanotherswehavelookedat,onlynotingthatitshoulddescribethe
worktobecompletedorderedinrelativeprioritytodelivertheproduct.
Forthisreason,theKanbanmethodologyisoftencombinedwith
methodssuchasScrum,wherethebacklogisusedasthe
implementationforthequeue.Whenanewfeaturerequestisreceived,
itisassessedforrelativepriorityandurgencyandthenplacedintothe
queueinitsrelativeposition,maintainingtheorderbypriority.
AnalogoustotheScrumtechniqueofgroomingtheproductbacklog,
Kanbandescribesatechniquecalledgroomingthequeue.Grooming
thequeueisaperiodicexercisewheretheprojectteamscopesthe
featureswaitinginthequeuetoseeiftheyaretoolargeoroutofscope
fortheupcomingrelease.Foritemsthataretoolargetobecompleted
beforeaplannedreleasedate,theprojectteamwillbreaktheitem
down(decomposesit)intosmallerchunksofwork,decidingwhichwill
beincludedinthereleaseandwhichwillnot.Theteamthenreassesses
thepriorityoftheitemsinthequeueandreordersthemasneededto
maintainacontinuous,prioritizedflowofwork.
2.3.2 The Kanban Board
Thetermkanbanactuallytranslatestosignboardorbillboard,andit
referstothekanbanboardusedbyteamstomanagetheirwork.In
keepingwiththeprincipletovisualizethework,thekanbanboardisa
visualdepictionoftheflowofworkthroughthesoftwaredevelopment
process.Thefollowingillustrationshowsanexampleofatypical
kanbanboard.
Kanban Business Analysis in Agile Life-cycles
FIGURE 2.4 TypicalKanbanBoard
ThegoalofaKanbansystemistoallowworkloadstobedrivenby
demand,orpriority,tocreateacontinuousflowofworkthatavoids
bottlenecksatanyonepointintheprocess.Thismethodlimitsthe
amountofworkinprogressbyworkingononethingatatimeuntilitis
completedbeforestartingthenexttask.Whenabottleneckoccurs,itis
expectedthattheentireteamwillcometogethertoremovethe
blockagetohelpkeepworkmovingthroughtheflow.Thekanban
boardenablestheteamtomanagetheflowofwork,identifying
potentialblockagesandensuringthatthenextiteminthequeueis
alwaysreadyandwaitingtobeworkedon.Followingthismethodalso
exposesopportunitiesforprocessimprovementbymakingitpossible
toeasilyseewheredelaysareoccurringinthedevelopmentprocess.
2.3.3 Roles & Responsibilities
Kanbandoesnotincludedefined,mandatedrolesorbusinessanalysis
methods.Likeanyagilemethod,itdoesstrivetobreakdownworksuch
thatindividualworkitemscanbeimplementedinarelativelyshort
periodoftime.TheKanbanmethodalsoattemptstobringtheproject
teamtogetherbyincreasingcommunicationandcollaboration,
enablingtheteamtoworktogetherasacollectiveandcohesiveunit.
2.3.4 Business Analysis in Kanban
Businessanalysis,likeallactivitiesintheKanbanmethod,occursina
constantandcontinuousflowthroughthelifeofaproject.Inorderto
maintainaprioritizedqueueofwork,businessanalysistechniquesare
Business Analysis in Agile Life-cycles Kanban
usedtoelicitnewproductfeatures.Requirementsanalysismethodsare
thenusedtoprioritizetherequirementsbasedonbusinessvalue,while
alsocontinuouslyusingstandardbusinessanalysistechniquesfor
scopingtheproductandmanagingthequeueofrequirements.
WhenplanningandmanagingtasksintheKanbanmethod,Service
LevelAgreements(orSLAs)areusedtomaintaintheestimatesforhow
longafeatureorchunkofworkwilltaketobecompleted.InKanban,
thisestimateincludestheplanningandanalysisactivitiesthattakeplace
beforesoftwaredevelopmentbegins.Thismethodforcesabusiness
analysttofocusonplanningandmonitoringactivities,enabling
constantrevisionandrefinementofestimatesaseachnewrequest
enterstheanalysisportionofthecycle.
InaKanbanproject,thebusinessanalystonlybeginstodefine
requirementsforanewworkitemwhenthequeuestepsforward.At
thatpointthedevelopmentteambeginstoworkononeofthe
completedrequirements,whilethebusinessanalysisbeginscollecting
requirementsforthenextiteminthequeue.Aparticularlyefficient
businessanalystmaybeabletodefinerequirementsforasystemfar
fasterthanthoserequirementscanbedevelopedandtested,whilealess
efficientbusinessanalystwillnot.Byopenlyandvisiblymanagingthe
workoftheprojectteam,theseinefficiencieswillsurfaceasprocess
improvementopportunities.Thiswillhelptomitigatetheriskrelated
tothetimingofbusinessanalysisactivities,enablingthebusiness
analysttomanagetheriskearlyintheprocess.
Comparison of Agile Life-cycles Business Analysis in Agile Life-cycles
2.4 Comparison of Agile Life-cycles
Despitepossessinguniquecharacteristicsanddifferentiators,agile
methodologiesandframeworksgenerallysharesomecommontraits.
Thesecommoncharacteristicsareillustratedbelowinadepictionofa
genericagilelifecycle.
FIGURE 2.5 GenericAgileLifecycle
Regardlessoftheagilemethodologyused,successfulagileprojects
followtheconsistentplanningrhythmorcadenceofStrategy,Release,
Iteration,Daily,andContinuous(seeAgileLevelsofPlanningon
page20).Thiscadenceiscombinedwiththenotionoffrequentand
flexiblereleaseschedulesthatallowforhighcustomerinvolvement
withrapidfeedbackandfrequentproductassessments.
Business Analysis in Agile Life-cycles Comparison of Agile Life-cycles
Thefollowingtableprovidesasummarycomparisonoftwomajor
agileframeworksthathavebeenoutlinedinthischapter,Scrumand
XP.
TABLE 2.2 ComparisonofAgileLifecycles
TheKanbanmethod,oftenusedtosupplementframeworkssuchas
ScrumorXP,describesitsownrhythmorcadenceofwork
progression.Kanbanfailstoprescriberolesandresponsibilitiesfor
projectteammembersortorecommendspecificdocumentationneeds
fortheprocess.ThismakesKanbanacommoncontenderforblended
methodologies.Itisimportanttonotethatitisverycommonfor
projectteamstoblendcharacteristicsoftwoormoreagile
frameworksandmethodologiestocreateabestfitfortheirteamand
organizationalcontext.
2.4.1 Selecting an Agile Methodology or Framework
Withthevarietyofagilemethodologiesavailable,thequestionarises,
howdoteamschoosewhichmethodologybestsuitestheirproject?
Thefollowingquestionsareexamplesofhighlevelquestionsthatcan
helpguidethischoice.
Fromhowmanystakeholdersdoyouneedtoelicit
requirements?
Wherearethesestakeholderslocated?Willtheybeatthesame
siteastheprojectteam?
Willyoursoftwareapplicationbeintegratedwithother
systems?Ifso,howmanyandhowsoon?
Arethereanyculturalororganizationalconstraintsthatwill
limitthenumberorfrequencyofproductreleasestheteamcan
make?
Characteristic Scrum XP
TypesofProjects All <20People;NonLifeCriticalFunctions
PrioritizationValues CustomerDriven CustomerDriven
LevelofDocumentation Anythingofvalue Aslittleaspossible
Typical Management Docs BurndownChart Tasklist
Typical Requirements Docs ProductBacklog,Sprint
Backlog
FeatureCards
Typical Architecture Docs ArchitectureModelClassResponsibility
Collaboration(CRC)Cards
Typical Test Docs
Models/Architecture HighLevelModels
Prototyping
SketchesClassResponsibilityCollaboration(CRC)
Cards
Agile Levels of Planning Business Analysis in Agile Life-cycles
Theanswerstothesefundamentalquestionswillhelptoguidethe
choiceofagilemethodologythatshouldbeused.Inturn,thechosen
flavorofagilewilldrivethemanagementofstakeholders,thetempoof
work,thedurationofwork,documentation,analysis,andother
aspectsofthebusinessanalyst'sworkonaproject.
Whileweprovidesomeinsightintoseveralmethodswithinthis
chapter,therearemanyagilemethodologiesandframeworks
availabletochoosefrom.Westronglyrecommendthatyouresearch
theseagileframeworksandmanyotherstohelpyouunderstandhow
theyaredifferentandtheprosandconsofeachimplementation.This
willhelpyourteamtobestunderstandwhichwillfitprojectteam
needsmostappropriately.
2.5 Agile Levels of Planning
Duetothefluid,dynamicnatureofagilemethodologies,itisimportant
tounderstandwhenandhowtoapplydifferentplanningtechniques
andtheappropriatelevelofdetailforeachlevelofplanning.Itis
importanttonotethatmanyofthetechniquesusedinanagile
environmentaresimilartotraditionaltechniques,whatisdifferentis
howandwhenanalystsapplythesetechniques.Justintimeandjust
enoughrequirementsthatareconsistentlyvalidatedbythebusiness
arecentraltotheanalyst'sroleinagilemethodologies.
Whenundergoingplanningexercisesintheagileworlditishelpfulto
considerhowtheanalyst'srolediffersfromtraditionaldevelopment
methodologies.Inagiletheroleoftheanalystiscentraltothevalueof
theproject.Theanalystholdsakeyroleinmaximizingvalueby
facilitatingtheinteractionswithalltheprojectstakeholders.
Exceptionallyhighcommunication,facilitation,andnegotiationskills
areanimportsetoftoolsforanalystsintheagileenvironment.
2.5.1 Agile Levels of Planning
Asmentionedintheprevioussection,ComparisonofAgileLifecycles
(seeComparisonofAgileLifecyclesonpage18),successfulagile
projectsfollowaconsistentplanningrhythmorcadenceofstrategy,
release,iteration,daily,andcontinuous.Throughthecadence,the
requirementsfortheprojectareprogressivelyelaboratedtoan
appropriatelevelofdetail.Ateachstepstableconceptsarecaptured,
contextiscaptured,andlearningopportunitiesareidentified.Oneof
thekeystoagileistoperformasufficientlevelofanalysisateach
Business Analysis in Agile Life-cycles Agile Levels of Planning
planninglevel.Toomuchanalysisupfrontcanresultincreationof
documentsthataresubjecttochange,requirethebusinessuserto
explaintheirneedsmultipletimes,andmaynotbenecessaryto
achievethegoalsoftheproject.Toolittleanalysisupfrontcanresultin
irresponsiblecommitments,rework,andalackoffocusoncustomer
value.
2.5.1.1 Strategy
Projectsandproductdevelopmenteffortsstartwithavisionofthe
businessdirectionorneed.Thevisionincludesthewhat,why,and
successcriteriafortheeffort.Thevisionisoftenassociatedwitha
roadmap.Theroadmapincludesthehighlevelscopeandmayinclude
aninitialarchitecture.Inadditiontoactivitiessuchasestablishinga
vision,scope,androadmap,thestrategyworkonanagileproject
includestheinitialcreationofafeaturerequestlist.Forexample,in
Scrumthisentailsseedingtheinitialrequestsinaproductbacklogor,
inXP,userstores.Thisisanalogoustopreprojectelicitationofbasic
stakeholderrequirementsthatareusedtofacilitatediscussionson
scopingandphasinginnonagileprojects.
Atastrategiclevel,thepersonwhoownstheproductorisleadingthe
initiativehelpsthedeliveryteamto
understandthecontextofthesolutionneeded,
identifythestepstorealizethevision,
prioritizethework,
assessthetechnicalimpactontheroadmap,and
facilitateobtainingestimatesforthereleases.
Muchlikeanyproject,strongenterprisebusinessanalysisskillsare
requiredtoeffectivelyplanastrategyforanagileproject.Insome
ways,youcouldarguethattheseskillsbecomemoreimportantinagile
methodologies.Thisisbecausewithoutdirectionbasedonbusiness
valueandaclearlydefinedscopeandaudience,agileprojectsareat
riskfordeliveringincrementalfeaturesthatnevercometogetherto
createendtoendvalueforanyonecustomergroup.Withouta
roadmapandsuccesscriteriafortheproduct,agileprojectscould
conceivablygoonforever,possiblywastingtime,money,andother
resourcesintheprocess.
2.5.1.2 Release
Releaseplanningisthephasewherethepersonwhoownstheproduct
groupsactivitiesandallocatesthemtoteams.Teamsworkondefining
enoughdetailtoresponsiblycommittosomerangeofscopeforthe
release.Teamsshouldreleasewhenthebenefitsofdeliveryoutweigh
thecostsassociatedwithrelease.Thereleaseisdefinedbyadate,
strategictheme,andplannedfeatureset.Releasedatescanbelinked
toevents,likeconferencesorcompliancerequirement.Intherelease
planningphasethescopeisfixedandtheprioritizedlistoffeature
requests,suchasaproductbacklog,isusedasthebasisforplanning.
2.5.1.3 Iteration
Manyagileteamsworkinfixedtimewindowscalledsprintsor
iterations.Aniterationplanningeventisheldatthestartofeach
iteration.Priortothatiterationplanningmeeting,theitemsinthe
featurerequestlistthatarebeingconsideredfortheiterationneedto
besufficientlyunderstood,thusenablingtheteamtoresponsiblymake
acommitment.InScrumthisisknownasgroomingthebacklog.In
continuousflowmodels,likeKanban,thefeaturerequestlistisstill
groomedbeforeitiscommitted,buttheplanningcadenceisbasedon
demand,notonadefinedtimeperiod.Onsometeams,thecustomeror
owneroftheproductcollaborateswiththedeliveryteamtogroomthe
requestlistpriortoiterationplanning,whileotherteamsuselow
fidelityspecificationsdevelopedduringspecificationworkshopsheld
priortoiterationplanning.Thisworkiscomprisedofrequirement
communicationandanalysis,withadditionalelicitationand
documentationasneeded.
Initerationplanning,theworkthatwillbeperformedinthesprintis
identified,estimated,reviewed,andcommittedto.Thedeliveryteam
meetswiththecustomerortheowneroftheproducttounderstand
therequirementsandacceptancecriteria,andtogainclarityon
specifications.Thisisanalogoustotheworkatraditionalbusiness
analystperformstocommunicationrequirementstostakeholders.
Duringiterationplanning,thedeliveryteammayalsoestimatethe
effortrequiredtodeliverthedesiredfeatures.Thisestimationisused
whencommittingtotheiteration.Attheendofiterationplanning,the
deliveryteamcommitstodeliveringanincrementofworking,tested,
deployablecode.
Afteraniterationhasbeencompleted,aniterationrevieworproduct
demonstrationisheld.Theproductdemonstrationmeetingissimilar
Business Analysis in Agile Life-cycles Agile Levels of Planning
tolightweightuseracceptancetestingandisgenerallylimitedtoa
maximumof4hours.
Duringtheproductdemonstration
thedeliveryteamdemonstrateshowthecodethatwas
developedmeetstheacceptancecriteria,
theowneroftheproductdetermineswhichitemsonthefeature
listhavebeencompletedintheiteration,
anynewrequeststhatarisefromthecustomerasaresultof
viewingthelatestproductareadded,and
theowneroftheproductanddeliveryteamreviewthestateof
thebusiness,themarket,andthetechnology,andreprioritize
thefeaturerequestlistforthenextiteration.
Aftertheiterationreviewmeeting,theprocessstartsupagain.Whilea
workingproductistheexpectedoutputofeachiteration,manyagile
teamswillwaittoreleaseaproductuntilseveraliterationsworthof
workhavebeencompleted.Theteammustdeterminetheappropriate
tradeoffpointbetweenthecosttodeliverthelatestproductandthe
amountofneworimprovedfunctionalitythatwillbedeliveredtothe
customerbase.Iterationsproceeduntilenoughfeatureshavebeen
donetocompleteorreleaseaproduct.
2.5.1.4 Daily
Agileteamsperformdailyteammeetingstocoordinatethework.The
dailymeetingisusuallyafifteenminutemeetingdesignedtoclarify
thestateofthework.
Duringthedailymeetingtheteam
getsaglobalsnapshotoftheproject,
discoversanynewdependencies,
addressesanypersonalneedsofcommittedindividuals,and
adjuststheworkplantomeettheneedsofthedayandensure
theteamcandeliverontheIterationcommitment.
Frequentlythedialogueheldduringthesemeetinguncoversitemsthat
lackofclarityorrequirefurtheranalysis.Theteamthenidentifiesa
planfordealingwiththeseimpedimentstotheproject.Thisoften
entailsassigningsomeonetodofurtherbusinessanalysisworkfor
elicitationandanalysisontheimpactedrequirements.
2.5.1.5 Continuous
Therearemanydynamicactivities,efforts,andchallengesthatarise
duringtheplanningphasesofagileprojects.Herearesomeguiding
principlesthatthoseconductingbusinessanalystmayfindhelpful,not
onlyduringtheplanningphase,butthroughtheagileprojectslife
cycle.
Startwithvalueandkeeptheteamtruetovalue.Itisvitalthat
theindividualholdingthebusinessanalysisroleispayingclose
attentiontotheprojectsbusinessvalue.
Lowfidelityartifactsserveasanenablerofbusinessvalueby
creatingcontextandgeneratingsharedunderstanding.
However,theydonotreplace,oreventakeprecedenceover
effectivecollaborationandconversation.
Businessanalysisisaboutfacilitatingdiscussionand
understanding.Businessanalyststypicallydonotpossessthe
depthofunderstandingaboutthebusinessasdoesthebusiness
sponsor,orasmuchabouttechnologyasthetechnologyteam.
Operateinthebestinterestofthebusinessovertime.
Responsiblybalancevalueandcapacity.
Identifyandcommunicatecompetingconcernsandgapsin
understandingbetweenthebusinessandtechnology.Ensure
thatcommonunderstandingisreached.
Resourcesarelimitedandvaluable.Alwaysassistinmaximizing
effortovertime.
Assisttheteamtoaction.Effectivelycommunicatewhatis
requiredwhentakingthenextsteps.Ensurethatfeedbackis
clearlyunderstoodandactedonbytheteam.
Deliverincrementallyanditeratively.Dothesmallest,simplest
thingthatcouldpossiblywork.Iteratetoreachminimalvalue.
Progressivelyelaborateinsmallpieceswhiletesting
assumptionsandarticulatingclearacceptancecriteria.
Producethesmallestamountofdocumentationthatmeetsthe
needsoftheteamanddeliveritatthelatestresponsible
moment.
chapter 3
Knowledge Areas
Thefollowingareasofknowledgerepresentaselectionofpopular
agilebusinessanalysistechniquesidentifiedthroughthedevelopment
oftheAgileBABOK
Extension.Manyofthebusinessanalysis
techniquesdescribedintheBABOK
Guidecontinuetobeusableinan
agilecontext,aswell,andothertechniquesnotlistedheremayprove
tobeusefulandapplicableinaparticularsituation.
3.1 Mapping Techniques to Knowledge Areas
3.1.1 Business Analysis Planning and Monitoring
BusinessAnalysisPlanningandMonitoring(Chapter2oftheBABOK
Guide)describestheworkrequiredforabusinessanalysttodetermine
theactivitiesthatwillberequiredtoperformbusinessanalysis
throughthelifecycleofaproject.Inagiledevelopment,mostplanning
isdeferreduntilworkonanactivityisreadytobegin,butsomedegree
ofupfrontplanningisusuallyrequired.
.1 Plan Business Analysis Approach (2.1)
Agilemethodologiesfallintothegeneralcategoryofchangedriven
approaches,asdescribedintheBABOK
Guide.Somebusinessanalysis
workwillgenerallybeperformedupfronttodefineavisionforthe
project,butdetailedanalysiswillbeperformedasneeded.Ifitis
unclearwhatproblemsthesoftwareissupposedtosolve,orthereare
severalstakeholdergroupswithconflictinginterests,itmaybe
necessarytodobusinessanalysisworkpriortothebeginningofa
projecttoreachagreementonthevisionfortheproduct.
Techniques
Backlog Management:Backlogmanagementistheprimarymethodof
handlingbothrequirementsprioritizationandchangemanagementin
Mapping Techniques to Knowledge Areas Knowledge Areas
mostagilemethods.Analternativetobacklogmanagementisakanban
board(describedunderKanbanonpage11).
Planning Workshop:Businessanalystsparticipateinplanning
workshopstodeterminethebusinessanalysiseffortandactivitiesto
supportateamobjective.
Real Options:Realoptionanalysismayhelpdeterminewhenbusiness
analysisneedstobeconductedtoinvestigateaparticularbusiness
issue.
Retrospectives:Thefeedbackfrompriorretrospectivesshouldbe
consideredwhenselectingtheapproach.
.2 Conduct Stakeholder Analysis (2.2)
Stakeholdersmaybechallengedbytherapid,iterativedevelopment
foundinanagileprojectandtheneedtobeoncallwhenever
informationisneededbytheteam.Whatistheimpactoftheagile
cadenceonthestakeholder?Howdoesprogressiveelaborationimpact
theexpectationsofthestakeholder?Canthestakeholderparticipatein
updatingtheprocesses,interactions,andproductsspecifications
duringthecourseoftheproject?
Techniques
Collaborative Games:Manycollaborativegamescanbeusedto
understandtheperspectivesofvariousstakeholdergroups.
Personas:Personascanhelptheanalystordevelopmentteamby
enablingthemtobettervisualizetheneedsofgroupswhodonothave
arepresentativepresent.
.3 Plan Business Analysis Activities (2.3)
Businessanalysisactivitiesareplannedasneeded,usuallyatthestart
ofeachiterationorwhenanewworkitemisreadyforanalysis.There
islessofafocusonformaldocumentation(althoughitstillcanbe
requiredtomeetstatutoryorregulatoryrequirements,ortocapture
knowledgedevelopedduringtheanalysisanddevelopmentprocess)
andmorefocusonprogressiveelaborationofdocumentation
throughoutthelifeoftheproject.Also,muchoftheelaborationis
replacedbyinteractionsandceremonysotheseoutcomesneedtobe
accomplishedwithactivitiesaddressedinthecommunicationplan.
Knowledge Areas Mapping Techniques to Knowledge Areas
Techniques
Planning Workshop:Decisionsregardingbusinessanalysisactivities
willusuallybemadeduringaplanningworkshop.
.4 Plan Business Analysis Communication (2.4)
Duringdevelopment,formalcommunicationofrequirementsis
generallyreplacedwithadhocinformaldiscussionsandmodelling.
Somedeliverablesarereplacedbyspecificinteractionsorceremonies.
Bydefinition,theseinteractionsandceremoniesrequirerealtime
participationbythebusinessanalyst.Formaldocumentationmaybe
developedfollowingdevelopmentofthesoftwaretoensure
knowledgeretentionbytheorganizationortomeetregulatory
requirements.
Techniques
Personas:Thesemayproveusefulinassessingthelikely
communicationneedsofspecificstakeholdergroups.
.5 Plan Requirements Management Process (2.5)
Inagilemethods,requirementsmanagementisfocusedonensuring
thattheintakeofnewworkbytheteammatchestheprioritiesofthe
stakeholdersand/orsponsor,anddeliversvaluetothebusiness.Agile
approachesstresstheimportanceofwelcomingchanging
requirements.Thismeansthattheorderingofworkitemsthatare
readyfordevelopmentmaybechangedatanytime.
Techniques
Backlog Management:Mostagilemethodsusebacklogmanagement
todeterminewhichrequirementsarereadytobeworkedonbythe
developmentteam.
.6 Manage Business Analysis Performance (2.6)
Thisactivitywillbeperformedonanongoingbasisasthebusiness
analystlearnstoworkeffectivelywithstakeholdersandthe
developmentteam.Aseveryoneinvolvedbetterunderstandshowto
worktogethertodelivervalue,thebusinessanalysisprocess,methods,
ortechniquesinusemayneedtochange.Effectivebusinessanalysis
performancewillresultinlimitedreworkoftherequirements
documentation,effectiveprioritizationandscopingofrequirements,
andclearcommunicationofneedtothedevelopmentteam.
Techniques
Retrospectives:Retrospectivesareacommonpracticeusedbyagile
teamsseekingtoimprovetheirwaysofworking.Businessanalysts
shouldlookforfeedbackontherequirementstheyprovidetotheteam
andhowandwhenthoserequirementsareprovidedinordertofind
waystoimprovetheirprocesses.
Value Stream Mapping:Valuestreammappingcanbeusefulin
assessinghowbusinessanalysisactivitiesarecontributingtothe
deliveryofvaluetothecustomerandidentifyingactivitiesthatmay
notbeaddingvalue.
3.1.2 Elicitation
Elicitation(Chapter3oftheBABOK
Guide)describeshowbusiness
analystsworkwithstakeholderstoidentifyandunderstandtheir
needsandconcerns,andunderstandtheenvironmentinwhichthey
work.Effectiveelicitationensuresthatthestakeholdersactual
underlyingneedsareunderstood,ratherthanstatedorsuperficial
desires.Elicitationisongoingthroughouttheprojectandperformedin
conjunctionwithanalysisactivities(ascomparedtotraditional
approaches,whereitispossibletoperformelicitationasadistinct
activityorphase).
.1 Prepare for Elicitation (3.1)
Preparingforelicitationchangesduringthelifeoftheproject.Earlyon,
itisdonebythebusinessanalysttocoordinatesupportingmaterials
andscheduleresourcestodefinethehighlevelrequirements.Asthe
projectprogresses,workiscoordinatedbyprioritizationofthe
backlog.Stakeholdersworkdirectlywiththedevelopers,when
possible,toelaboraterequirements.Wherethisisnotpossible,the
businessanalystmustactasaproxy.Thistaskrequiresthescheduling
ofresourcesandthecoordinationofinputstoalignwiththe
progressiveelaborationofthebacklog.
Techniques
Personas:Personasmayprovideinsightintotheparticularneedsofa
stakeholderorthetechniquesthatwillbemosteffectivein
understandingthoseneeds.
User Story:Auserstorywillidentifytheroleforwhomthestory
providesvalue(andthereforeidentifythestakeholderswhocan
elaborateonthatvalue).
.2 Conduct Elicitation Activity (3.2)
Elicitationactivitiesareconductedonafrequentbasisthroughoutthe
project,possiblyevendaily.Earlyon,elicitationisperformedtodefine
highlevelrequirementsoravisionfortheproduct.Astheproject
progress,stakeholdersinteractwiththedevelopmentteamdirectly
duringiterationplanninganddevelopment.Theintentofallelicitation
activitiesistogeneratejustenoughdetailtoensurethattheworkat
handisperformedcorrectly.
Techniques
Behaviour Driven Development:Stakeholdersmayfinditeasierto
articulatetheirneedsbyprovidingexamplesratherthanthrough
abstractmodels.
Collaborative Games:Collaborativegamesencourageparticipantsin
anelicitationactivitytocollaborateinbuildingajointunderstanding
ofaproblemorasolution.
Note:Asmentionedabove,analysisisusuallyperformedduring
elicitationsessions.MostofthetechniquesfoundintheAgile
Extension,aswellasmanyofthetechniquesintheBABOKGuide,are
suitableforthispurpose.
.3 Document Elicitation Results (3.3)
Amajorvalueofdocumentationisthatitcanbeusedforlongterm
knowledgeretention.Agilemethodsaimtominimizethetimebetween
thedevelopmentofrequirementsandtheirimplementationin
software,reducingtheoverallvalueofthatdocumentationtotheteam.
Recordsofelicitationactivitiesshouldbekepttoensurethatkey
decisionscanbeunderstoodatalaterdate,ortoensurethat
regulatoryorgovernancerequirementsaremet.
Techniques
Lightweight Documentation:Seethissectionforguidelineson
developingdocumentation.Inmostcases,therewillnotbeseparate
documentationoftheelicitationandanalysiswork.
.4 Confirm Elicitation Results (3.4)
Thiswillbeperformedbytheteamduringiterationplanning,during
thedevelopmentiteration,andatcustomeracceptance.Thecustomer
maychangetheirmindaboutsomespecificelementofastoryafter
seeingtheresult.Thisfeedbackbecomesaninputintotheconduct
elicitationactivity.
Techniques
AcceptanceandEvaluationCriteriaDefinition:Elicitation
outcomeswillfrequentlybecapturedintheformofacceptance
criteriathatwillbeusedbytheteamtoverifythatthesoftwaremeets
stakeholderneeds.
3.1.3 Requirements Management and Communication
RequirementsManagementandCommunication(Chapter4ofthe
BABOK
Guide)describeshowbusinessanalystsmanageconflicts,
issues,andchangesinordertoensurethatstakeholdersandthe
projectteamremaininagreementonthesolutionscope,how
requirementsarecommunicatedtostakeholders,andhowknowledge
gainedbythebusinessanalystismaintainedforfutureuse.
.1 Manage Solution Scope and Requirements (4.1)
Asagileprojectsunfold,thescopeisdefinedwithincreasing
specificity.Thespecificdetailsofthescopecanbefoundinthesolution
backlog.Basedonthelevelofelaboration,thesolutionbacklogitself
mayvaryinitsownlevelofdetail.Itshouldalsobeconsideredthatthe
sponsormaydecidetoterminatetheprojectshouldtheydecidethat
furthereffortswillnotprovideanacceptablereturnofbusinessvalue.
Techniques
Backlog Management:Mostagileteamsusetheproductbacklogto
managebothsolutionscopeandrequirements.
.2 Manage Requirements Traceability (4.2)
Onagileprojects,everythingisconnectedbacktothestrategicthemes,
epics,andstoriesthatareusedtodefinetheproject.Thisismaintained
bytheproductownerorthebusinessanalyst.
Techniques
Story Mapping:Storymapsshowrelationshipsbetweenuserstories
andlargeractivitiesthattheusermustbeabletoaccomplish.
.3 Maintain Requirements for Reuse (4.3)
Inmatureagileorganizations,thishappensmuchthesamewayasit
doesintraditionalefforts.Thedifferenceisinthewaythat
requirementsaredocumentedattheendoftheproject.Often,the
sourcecodeitselfiswrittentobeselfdocumenting.
Techniques
AcceptanceandEvaluationCriteriaDefinition:Theacceptance
testsandcriteriadevelopedduringtheprojectaremaintainedto
validateanyfuturechangestothesoftware.
.4 Prepare Requirements Package (4.4)
Thisishandledthroughscenarios,usecases,acceptancetests,and
mockupsandmodelsassociatedwiththethemes,epics,andstories
usedtodefinetheproject.Thisisanongoingactivitythroughthelifeof
thedevelopmentofthesolution.Thespecifictechniquesusedwill
dependupontheapproachchosenatthebeginningoftheproject,and
willchangebasedontheemergentunderstandingofwhatworksbest
inthecontextoftheproject.
Story Decomposition:Epics,features,orminimallymarketable
features(MMF)tiegroupsofuserstoriestogetherintolargerpackages
thatcanbediscussedwithstakeholders.
.5 Communicate Requirements (4.5)
Requirementsarecommunicatedtodevelopersinreleaseplanning
meetingswherethemesandstoriesarereviewedandselectedfor
release.Theyarediscussedinmoredetailiniterationplanning
meetingswherethemodelsandspecificationsareselectedand
discussedamongtheteamandtheproductowner.Intheseiteration
planningmeetings,risksarealsoreviewedanddiscussed.
Planning Workshop:Seethistechniqueforfurtherdetails.
3.1.4 Enterprise Analysis
EnterpriseAnalysis(Chapter5intheBABOK
Guide)describeshow
businessanalystsidentifyabusinessneed,refineandclarifythe
definitionofthatneed,anddefineasolutionscopethatcanfeasiblybe
implementedbythebusiness.Thisknowledgeareadescribesproblem
definitionandanalysis,businesscasedevelopment,feasibilitystudies,
andthedefinitionofsolutionscope.Enterpriseanalysisisabout
identifyingthebusinessneed,opportunityorproblemtobesolved
anddecidingontheappropriateapproachtoaddressingtheneed.
.1 Define Business Need (5.1)
Nosignificantchanges.
Techniques
Business Capability Analysis:Abusinessneedwillusuallycorrespond
tothedevelopmentofanewcapabilityortheenhancementofan
existingcapability.
Collaborative Games:Somecollaborativegamescanbeusefulin
exposingunmetbusinessneeds.
.2 Assess Capability Gaps (5.2)
Nosignificantchanges.
Techniques
Business Capability Analysis:Thiscanbeusedtounderstandwhat
shortcomingsexistinanexistingcapability.
.3 Determine Solution Approach (5.3)
Agiledevelopmentisasolutionapproach.Itmaybeselectedinorder
toprovideafasterdeliveryofvaluethantraditionalmethods,or
becausetheproblemareaneedstobeexplored.Italsosupports
incrementaldeliverysothesolutionapproachcanbeevolvedoverthe
courseoftheproject.Thisapproachallowsadifferentbargaintobe
struckwiththebusinessregardingdeterminingthesolution.
Techniques
Purpose Alignment Model:Thepurposealignmentmodelcanprovide
guidanceregardingthebestsolutionapproachtotakeforagiven
businessneed.
.4 Define Solution Scope (5.4)
Thescopeofagileprojectsevolvesduringthecourseoftheprojectas
theteamlearnsmoreaboutwaystosolvetheproblemandthe
customerpreferencesforasolution.Thescopeisdefinedinhigher
levelabstractions(suchasthemesandepics)andisdetailedasthe
projectevolves.
Business Capability Analysis:Thescopeoftheprojectshouldbe
relatedtothebusinesscapabilitiesitiscreatingorenhancing.
Story Decomposition:Epicsandfeaturescanserveasthebasisfor
definingthescope.
Story Mapping:Astorymapcanbeusedtoseetherelationship
betweenthevariousstoriesdeliveredbytheproject.
.5 Define Business Case (5.5)
Thebusinesscaseforagileprojectsistypicallybasedonachievinga
specificbusinessoutcomewithinaspecifiedcostandtime.The
businesscaseisrevisitedfrequentlyastheteamlearnswhatitcan
deliver,howwellitmeetsthereal(notperceived)needs,andwhether
thebusinessoutcomecanbeachievedwithinthespecifiedcostand
time.
Business Capability Analysis:Definesthecustomerandorganizational
valueassociatedwithabusinesscase.
Kano Analysis:Identifieswhichproductfeaturesarelikelytohavethe
greatestmarketimpact.
Purpose Alignment Model:Identifieswhatkindofinvestmentislikely
togeneratethegreatestvaluefortheorganization.
Real Options:Allowsassessmentofwheninvestmentneedstobe
madeinordertoensurevalueisobtained.
3.1.5 Requirements Analysis
RequirementsAnalysis(Chapter6intheBABOK
Guide)describeshow
businessanalystsprioritizeandprogressivelyelaboratestakeholder
andsolutionrequirementsinordertoenabletheprojectteamto
implementasolutionthatwillmeettheneedsofthesponsoring
organizationandstakeholders.Itinvolvesanalyzingstakeholder
needstodefinesolutionsthatmeetthoseneeds,assessingthecurrent
stateofthebusinesstoidentifyandrecommendimprovements,and
theverificationandvalidationoftheresultingrequirements.
.1 Prioritize Requirements (6.1)
Inagile,requirementsareprogressivelyelaborated.Throughoutthe
elicitationtask,elicitationresultsareprogressivelybrokendownand
elaborated.Ateachpointofelaborationtheconstituentpartsneedto
beevaluatedandprioritizedbasedonbusinessvaluecontributionand
riskburndown.Inagile,thisisnotaonetimeupfrontactivity.This
happensthroughoutthelifeoftheprojectonallremainingworkand
newworkbroughtinfromlearningabouttheproduct.
Techniques
Backlog Management:Backlogmanagementisthestandardmethodof
prioritizingrequirementsinmanyagilemethodologies.Thebacklog
canbereprioritizedwheneverbusinessneedschangeorarebetter
understood.
Kano Analysis:Kanoanalysiscanprovideinsightintotherelative
importanceoffeaturestoausergroup.
Planning Workshop:Prioritizationnormallytakesplaceduringa
planningworkshop.
Note:alsoseetheexpandedtreatmentofMoSCoW Prioritization.
.2 Organize Requirements (6.2)
Inagile,itisimportanttoorganizerequirementstominimize
dependenciesbetweenfeaturesets.Thisreducescomplexityandrisk
andimprovestestabilityatthebusinesslevelvalue.Since
requirementsareprogressivelyelaborated,thisbigblockarchitecture
resultsinthesolutionarchitecturefromabusinessstandpoint.
Requirementsshouldbeorganizedaroundbusinessvalueandnot
technicalimplementations.Onlywithincomponentteams,wherethe
businessvaluearisesfromdeliveringenablingtechnology,isit
appropriatetodepicttechnicalrequirements.Eventhen,these
requirementsneedtobeprioritizedandfilteredbasedonriskburn
downandbusinessvaluecontribution.Storymapswithinepicsarea
methodofimplementingorganizerequirements.
Techniques
Story Decomposition:Individualstoriesmaybeorganizedaroundan
epicorfeature.
Story Mapping:Storymappingalsoshowshowindividualstoriesare
relatedtoorsupportoneanother.
.3 Specify and Model Requirements (6.3)
Atdifferentlevelsofelaborationtherearedifferentmethodsfor
specifyingandmodellingrequirements.Theapproachshouldsupport
progressiveelaboration,beadaptabletochangebasedonlearning,
andnotcausetheteamtoselectsolutionstooearly.Itshouldalso
ensurethatintentandintendedbusinessvalueiscommunicated
consistentlythroughtheelaboration.Agileteamstendtousestories
andtasksatthelowestlevelofdecomposition.Thesestoriesandtasks
canbesupportedbydetaileddocumentationandusecases.Itis
becomingincreasinglycommonforacceptanceteststobeproducedas
partofspecifyingandmodellingtherequirements.
Techniques
Behaviour Driven Development:Concreteexamplesoffunctionality
mayhelpstakeholdersbetterspecifyandunderstandtheirneeds,or
dealwithspecificscenariosthatareofgreatervalue.
Storyboarding:Usedtodescribeuserinterface(UI)functionalityand
behaviour.
Note:alsoseetheexpandedtreatmentofUser Storyinthisextension.
.4 Define Assumptions and Constraints (6.4)
Onagileprojects,thisishandledthroughariskmanagementapproach
thattreatsrisksasstorieswithinthemes.Riskmitigationactivitiesare
reprioritizedalongwithstoriesandburneddownandreprioritized
astheystoriesareperformed.Thisistypicallyproducedbythe
businessanalystandprojectmanageralongwiththeteam,prioritized
bytheproductowner,andperformedbytheteam.
User Story:Userstoriescanalsobeusedtotrackassumptionsor
constraints(particularlythelatter),althoughitneedstobecleartothe
teamandstakeholdersthattheseareseparatefromthestories
plannedfordevelopment.
.5 Verify Requirements (6.5)
Requirementsareverifiedbytheteamduringtheproject.Through
retrospectivesandoperationsreviews,theteammaydecidetomodify
thelevelofdetailtorequirementsorthemethodofspecifyingand
modellingrequirementstoimprovetheperformanceoftheteam.
Verificationofrequirementsusuallyisdonethroughdirect
stakeholderinteractionwiththeteamasthesoftwareisdeveloped.
.6 Validate Requirements (6.6)
Requirementsareverifiedthroughoutthedevelopmentanddelivery
ofthesolutionthroughcontinualinvolvementoftheproductowner
andcustomer.Thishappensatreleaseplanning,iterationplanning,
duringdevelopment,andatcustomeracceptance.
3.1.6 Solution Assessment and Validation
SolutionAssessmentandValidation(Chapter7oftheBABOK
Guide)
describeshowbusinessanalystsassessproposedsolutionsto
determinewhichsolutionbestfitsthebusinessneed,identifygapsand
shortcomingsinsolutions,anddeterminenecessaryworkaroundsor
changestothesolution.Italsodescribeshowbusinessanalystsassess
deployedsolutionstoseehowwelltheymettheoriginalneedsothat
thesponsoringorganizationcanassesstheperformanceand
effectivenessofthesolution.
.1 Assess Proposed Solution (7.1)
Inagileprojects,thistaskislikelytobeperformedrepeatedlyasthe
solutionisbuilt.Oneofthebenefitsofagileisthatthesolutioncanbe
assessedovertime.Somesolutiondecisionsmustbemadeupfront.
Agilefacilitatestheconceptofrealoptionswheredesigndecisionscan
bedeferreduntilthelastresponsiblemoments.Detailed
understandingofthebusinessneedisunfoldingatthesametimeas
theteamsunderstandingofhowtosolvetheproblemisdeveloping.
Witheffectiveagilearchitectureanddesign,thecostofredoingthings
thathavealreadybeendevelopedisrelativelylow.Assessingthe
proposedsolutiondoesntbecomeacheckpointontheprojectbutan
ongoingassessmentagainstthebusinesscaseandcurrentstatusofthe
project.
Techniques
Real Options:Allowsforassessmentofaspectsofthesolutionto
determinewhendecisionshavetobemaderegardingaparticular
proposal.
.2 Allocate Requirements (7.2)
Onagileprojects,thisisdonebyallocatingrequirementsintofeature
themesandcomponents.Agileteamsaresmallteamsandthis
allocationshapesthedesignofthedeliveryorganizationitself.Feature
teamsformaroundthefeaturethemesandcomponentteams
supportingcrossfeaturethemerequirements.
Techniques
Story Decomposition:Breaksdownhighlevelepicsandfeaturesinto
smallersupportingstories,whichcanbeallocatedtodifferent
components(includingprocessororganizationalchanges).
.3 Assess Organizational Readiness (7.3)
Theorganizationalreadinessassessmentoccursonagileprojectsin
muchthesamewayasitdoesintraditionalprojects.Thedifferenceis
thatthereleasecadencecanbemorefrequent.Asignificantareato
defineinagileprojectsishowoftentheorganizationcanabsorb
releases.Organizationalreadinessshouldincludenotjusttheend
user/customerofthereleasebutthesupportingorganizationaswell
(forexample,support,training,sales,marketing,andaccounting).
.4 Define Transition Requirements (7.4)
Thedeterminationoftransitionrequirementsoccursinanagile
projectmuchasitdoesinatraditionalproject.Theabilitytodeliver
valueincrementallyopensupnewpossibilitiesfortransition.Unlikea
monolithicrelease,theorganizationalimpactcanbesmallerbutmore
frequent.Sincethecostofdevelopmentperunitislower,temporary
integrationintoexistingsystemscanbedevelopedandmaketheneed
forrunningparallelsystemslesssignificant.
Techniques
User Story:Userstoriescanbeusedfortheplanningoftransition
requirementsandareprioritizedand/ororderedinthesamefashion
asotherstories.
.5 Validate Solution (7.5)
Validationofasolutionhappensasanongoingeffortinanagile
project.Withineachiteration,thecustomerisprovideddetailed
feedbackonthecurrentrequirements.Atthecompletionofeach
iterationcycle,theproductownerfacilitatesalignmentwiththe
customerneedandcontinuedalignmentwiththebusinesscase.
.6 Evaluate Solution Performance (7.6)
Uponrelease,theproductownerfacilitatesunderstandinghowwell
thesolutionmeetstheneedsofthecustomerandidentifiesnew
opportunitiesforimprovementandtocreateadditionalvalueforthe
business.Theincrementalnatureofthebacklogallowsnew,higher
valueitemsdiscoveredduringthisevaluationtoenterintotheexisting
backlogaheadofexistingitems.Thisisanadditionalwaythatagile
shortenstimetovalue.
Techniques
Business Capability Analysis:Allowsbusinessanalystsand
stakeholderstounderstandtheimportanceandrelativeperformance
ofabusinesscapability.
Value Stream Mapping:Usedtoidentifythoseaspectsofthesolution
thataddvalueforcustomersandthosewhicharenonvalueadded.
Thisassessmentbecomesthebasisforongoingimprovementefforts.
3.1.7 Business Analysis Techniques Mapped to Agile Business
Analysis Guidelines
ThefollowingtablemapstechniquesasdescribedintheBABOK
Guidetotheguidelinesforagilebusinessanalysispresentedinthis
document.
TABLE 3.3 BusinessAnalysisTechniquesMappedtoAgileBusinessAnalysisGuidelines
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
Decompositio
n
9.12
Interface
Analysis
9.13
Interviews
9.14
Lessons
Learned
Process
9.15
Metrics and
Key
Performance
Indicators
9.16
MoSCOW
Analysis
6.1.5.2
Non-
functional
Requirements
Analysis
9.17
Observation
9.18
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
Documentatio
n
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
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
chapter 4
Techniques
4.1 A Context for Agile Business Analysis
ThischapteroftheAgileExtensiontotheBABOK
Guideprovides
analystswithskillsandtoolsthatwillassisttheminexcellinginthe
agileworld.Inorderforthetechniquesandskillspresentedinthis
sectiontobeappliedwithsuccess,therearesomefoundational
principlesthatarerequiredtobeunderstood.Theseprinciplesbreak
downintoanumberofpracticaltechniquesthatcanbeusedby
practitionerswhentheyundertakebusinessanalysisonagileprojects.
Theprinciplesthatguidesuccessfulbusinessanalysiscanbe
categorizedintotwodistinctframeworks:discoveryanddelivery.
Thediscoveryframeworkdealswiththewhatsandthewhysofthe
product.Effectivediscoveryisformulatedbythreeunderlying
principles:
See The Whole,
Think as a Customer,and
Analyze to Determine What is Valuable.
Thedeliveryframeworkdealswiththehowsandthewhensofthe
product.Effectivedeliveryisformulatedbyfourunderlyingprinciples:
Get Real Using Examples,
Understand What is Doable,
Stimulate Collaboration & Continuous Improvement,and
Avoid Waste.
Thefollowingsection,AgileExtensionTechniques,exploreseach
principleindepthandprovidestechniquestosupporttheapplication
oftheseprinciples.
Guidelines for Agile Business Analysis Techniques
4.1 Guidelines for Agile Business Analysis
Thefollowing7guidelinesforpracticingbusinessanalysisinsidean
agilecontext,arebasedonthevaluesandprinciplesoftheAgile
ManifestoandtheprinciplesofLean.Together,theseguidelines
embodythedisciplineofagilebusinessanalysis.Theseguidelines
providevaluablecontextwhenapplyingthevarioustechniques
describedinthischapter.
Inanagilecontext,businessanalysisviewstheentiresystemof
people,process,andtechnologytofindwheretruevaluelies
andtohelporganizationsmaximizesthelikelihoodof
deliveringavaluableandvaluedsolution.
Agileanalysispaysspecialattentiontothevoiceofthe
customertounderstandtheirvaluesandexpectations.
Toconfirmwhatisvaluable,itiscommontouseconcrete
examplestobothelicitandvalidateproductneeds.
Technologystakeholdersareempoweredbyeffectively
analyzedneeds.Ithelpsthemdeterminehowmuchworkthey
candeliveratanygivenpointintime,identifyproduct
requirementsoptions,andproviderecommendationsto
businesspartnersonsolutions.
Facilitativetechniquesenableefficientandeffective
collaborationandaccelerateateam'sabilitytodefineand
deliverproducts.Trustandsafetyareintegraltohealthyteam's
andallowsthemtotransparentlyidentifyimprovement
opportunities.Improvingbothproductandprocessis
imperative;thereforeagileteamscontinuallyseektoalwaysget
better.
Alwaysbeonthelookoutfor,andavoid,anythingwasteful.
Adoptingtheseguidelinesrequiresleveraging,extending,and
adaptingfoundationalbusinessanalysistechniques.Business
AnalysisTechniquesMappedtoAgileBusinessAnalysisGuidelineson
page39foramatrixofbusinessanalysistechniquesthatmayapplyin
anagilecontext.
4.1 A Note on Agile Extension Techniques
Agilebusinessanalysisisstillinarelativelyearlyphaseof
development.Assuch,thetechniquesusedbybusinessanalyststo
supportagileteamsarealsoinastateofflux.Webelievethatthe
Techniques See The Whole
techniquesdescribedherehaveprovenvalueinsupportingagile
businessanalysis,butwedonotclaimthatthislistisallinclusiveorin
anywaycanonical.Thetechniquesherewereselectedbasedonthe
experiencesoftheteammembers,andrepresentbothexpansionsto
existingcontentintheBABOK
Guideandnewtechniquesnot
describedinthecurrentversion.FutureversionsoftheAgileExtension
willlikelyincludenewtechniques,anditisalsopossiblethatsomeof
thetechniqueslistedherewillberemoved.
Inaddition,manyofthetechniqueslistedheremayproveusefulto
businessanalysispractitionerswhoarenotworkingonagileteams.
4.1 See The Whole
SeetheWholeisaconceptthatdescribestheneedtolookataproblem
oropportunityinthecontextofthebigpicture,focusingonthe
businesscontextandwhyaprojectisbeingundertaken.Itdescribes
notjustwhatasystemis,buthowitwillbeused.Itisimportantto
assesshowthesolutionachievessomethingofvalueforitsrecipients.
Thevaluecontextforthesolutioniscreatedbyunderstandingboththe
solutionandthestakeholders,andthenarticulatingwhotheyareand
howtheywillfindvalueinthesolution.
Onagileprojectsthereisahighriskofgettingmiredinthedetailson
eachiteration.Whendevelopingthebusinesscaseforasolutionand
performingiterationandreleaseplanningactivities,itisimportantto
maintainthefidelityofthecontext.Bydoingso,thecontextguidesthe
nextlevelofelaboration.Bythinkingaboutthestrategicoutcomefor
thesolution,thedeliveryteammovesfromordertakerstoagroup
thatdeliversbusinessvaluewithlesscodebloat,scopecreep,and
neverendingprojecttimelines.Seeingthewholecreatessituation,
appropriatecontextandasharedunderstandingofthebusiness
problemthatneedstobesolved,whichinturnwillguidedecision
making.
Thefollowingsectionsdescribecommonlyusedtechniques.
Business Capability Analysis
Personas
Value Stream Mapping
See The Whole Techniques
4.1.1 Business Capability Analysis
.1 Purpose
Provideaframeworkforproductscopingandreleaseplanningby:
generatingasharedunderstandingoftheoutcomesofabusinessor
product,identifyingalignmentwithastrategyandspecific
performancegaps,andprovidingascopeandprioritizationfilterthat
isstableandlowfrictiontomaintainovertime.
.2 Description
Businesscapabilitiesdescribetheabilityofabusinesstoactonor
transformsomethingthathelpsachieveabusinessgoalorobjective.
Manyproductdevelopmenteffortsareanattempttoimprovethe
performanceofabusinesscapabilityortodeliveranewbusiness
capability.Businesscapabilityanalysisistheanalysisofthe
performanceandriskassociatedwithasetofbusinesscapabilitiesto
identifyspecificperformancegapsandtoprioritizethesebasedon
businessvalueandrisk.
.3 Elements
Capabilities
Capabilitiesaretheabilitiesinabusinesstoperformortransform
something.Capabilitiesshoulddescribethepurposeoroutcomeofthe
performanceortransformation,nothowtheperformanceor
transformationisperformed.Itdescribesthewhat,asopposedtothe
how.Forexample,sendingafaxisnotacapability;notifyingthe
customeristhecapability.
Using Capabilities
AmodelofBusinessandCustomerValue:Businessvalueis
somethingthatincreasesorprotectsrevenue,reducesorprevents
cost,improvesservice,achievescompliance,orpositionsthecompany
forthefutureinalignmentwiththebusinessstrategy.Notall
capabilitieshavethesamelevelofvalue.Forexample,while
distributingpayrolltoemployeesisimportanttoacompany,itislikely
neitherofhighbusinessnorcustomervalue.Inotherwords,thismay
notbeacapabilitythataddsvalueforthecompanytobuildand
maintaininternally.Therearevarioustoolsthatcanbeusedtomake
businessandcustomervalueexplicitinacapabilityassessment.In
additiontothesetools,balancedscorecardscanbeusedasamodelof
businessvalue.
Performance Expectations
Sincecapabilitiesidentifytheabilitiesrequiredtoperformor
transformsomething,capabilitiescanbeassessedtoidentifyexplicit
performanceexpectations.Whenacapabilityistargetedfor
improvement,aspecificperformancegapcanbeidentified.Whilethe
performanceofeverycapabilitycanbeimproved,theperformance
gapisthedifferencebetweenthecurrentperformanceandthedesired
performancegiventhebusinessstrategy.
Risk Model
Risksintheperformanceofthecapabilityfallintothefollowing
categories:
businessrisk,
technologyrisk,
organizationalrisk,and
marketrisk.
Strategic Planning
Businesscapabilitiesforthecurrentstateandfuturestateofan
organizationcanbeusedtodeterminewherethatorganizationneeds
togoinordertoaccomplishtheirbusinessstrategyandimperatives.
Asaresultofperformingabusinesscapabilityassessment,thereis
generallyasetofrecommendationsorproposalsforsolutionsthat
needtobeputinplace.Thisinformationformsthebasisofaproduct
roadmapandservesasaguideforreleaseplanning.
Capability Maps
Frequently,organizationsusecapabilitymapstoprovideagraphic
viewofelementsinvolvedinbusinesscapabilityanalysis.The
followingillustrationdemonstratesoneelementofacapabilitymap
thatwouldbepartofalargercapabilitiesgrid.
FIGURE 4.6 SampleCapabilityMap
.4 Usage Considerations
Capabilityanalysisisusefulwhenanorganizationchangesitsbusiness
focusorstrategy,orthereismoredemandforchangethanthereis
capacitytodeliver.Whenthedemandoutweighsthecapacityto
deliver,alargeundifferentiatedbacklogofchangesorimprovement
requestscanresult.Capabilityanalysishelpstoidentifythose
improvementrequeststhatwilladvancethestrategicgoalsofthe
business.Uponcompletionofaprojecteffort,thecapabilityanalysis
canbeupdatedtoreflectimprovementsinperformanceandtoidentify
thenextmostimportantcapabilityperformancegaptofocuson.
Theoutcomesofacapabilityanalysisserveaslonglivedartifactsthat
representacommonviewofthebusiness.Thiscanbeusedtogenerate
sharedunderstandingandalignefforts.Whenthebusinessstrategy
changesorcustomerdesiresevolve,thismodelcanbeusedtorapidly
reprioritizethelistofwantsforasolution(forexample,re
prioritizingthebacklog).
%XVLQHVV9DOXH$QDO\VLV&HQWUHRI([FHOOHQFH
2UJDQL]DWLRQDO$QDO\VLV 3URMHFW$QDO\VLV 3URIHVVLRQDO'HYHORSPHQW
0DQDJHPHQW
Employee
Bevelopment
Planning
Resouice
Allocations
Peifoimance
Nanagement
Templates
Resouices
Naintenance
Nentoiing
Tiaining
Pioject Analysis
Consulting
iii
0iganizational
Analysis
Consulting
Requiiements
Eliciation
Requiiements
Nanagement
Requiiements
Communication
0sei Acceptance
Testing
0sability Testing
Roudmup
Constructlon
Stakeholuei
Analysis
Process Anulysls
Root Cuuse
Anulysls
Cupublllty
Anulysls
+LJK9DOXH
0HGLXP9DOXH
/RZ9DOXH
+LJK3HUIRUPDQFH*DS
0HGLXP3HUIRUPDQFH*DS
/RZ3HUIRUPDQFH*DS
+LJK5LVN
0HGLXP5LVN
/RZ5LVN
.H\
Advantages
Theadvantagesofcapabilityanalysisarethattheyresultina
sharedarticulationofoutcomes,strategy,andperformance.
Thesehelpcreateveryfocusedandalignedinitiatives.The
modelworksverywellwithagileteamsbutitalsohelps
identifyopportunitiesthatarenottechnologybased,including
process,talent,anddataimprovements.
Thecapabilityanalysishelpsaligntheseinitiativesacross
multipleaspectsoftheorganization.
Disadvantages
Thismodelrequiresanorganizationtoagreetocollaborateon
thismodel.
Whenthismodeliscreatedunilaterallyorinavacuumitfailsto
deliveronthegoalsofalignmentandsharedunderstanding.
Themodelalsorequiresabroad,crossfunctionalcollaboration
indefiningthecapabilitymodelandthevalueframework.
Implications for Agile
Agilemethodologiescreateaframeworkthatfacilitatesfrequentre
assessmentofbusinessneedsandvalue.Thedirectionofthebusiness
andthegapsrequiredforthebusinesstomeetitsobjectivesmustbe
revisitedforeachreleaseplanningsession,whichgenerallyoccurs
every24weeksinmostagilelifecycles.Thismeansthatanagile
projectteammustmaintainaconstantviewofthebusiness
capabilitiesthatarerequiredforthebusinesstobesuccessful,
particularlythosethatareinscopefortheproductbeingdelivered.
BusinessValue:SeeKano,PurposeAlignment,BalancedScorecard,
Moscow.
4.1.2 Personas
.1 Purpose
Usercentereddesignpracticesoftenusepersonasasapowerfuland
simpletooltohelpdesignsoftwarethatuserswillenjoyandbenefit
from.
.2 Description
Personasarefictionalcharactersorarchetypesthatexemplifytheway
thattypicalusersinteractwithaproduct.Theyareoftenusedinagile
methodstounderstandvaluefromtheperspectiveofaparticular
customerandallowateamthatmaynothavedirectaccesstoa
customerrepresentativetobetterunderstandtheirneeds.Workcan
thenfocusonthefeaturesofgreatestvaluetoaparticularpersona.
.3 Elements
Apersonashouldbedescribedasthoughtheyarearealperson.
Personasmayprovideaname,personality,family,workbackground,
skilllevel,preferences,behaviorpatterns,andpersonalattitudes.Itis
alsoagoodpracticetoincludeapictureandwriteashortdayinthe
lifenarrativethathelpstheteamvisualizetheuser.
Usepersonaswhenyouwanttogetadeeperunderstandingofkey
stakeholdersthanonegenerallygetsfromatraditionalroleoractor
description.Personashelpdriveproductsthatarefitforpurposeand
highlyusable,becausetheyarepatternedafterthesubtlequalitiesof
realpeoplethatwillinteractwiththesystemsandhowtheydotheir
job.
Ifthedataisavailable,usingdemographic(oranthropomorphic)data
abouttheintendeduserpopulationisagoodwaytostartbuilding
personas.Howeverinsomecasesitisnecessarytobecreativeand
inventpersonasbasedonlittlemorethanafewdryfactsaboutthe
intendedendusers.Ineithercase,arepresentativepoolofpersonas
shouldbeidentified.Dependingonthesizeoftheprospectiveuser
baseanddiversityofthatpopulation,thepersonasidentifiedmay
rangefromasmallhandfultoadozenormore.
Personasarethenrankedtoidentifyafewkeytargetsthatwillrealize
themostbenefitfromthesystemdesign.Whendesignconsiderations
aremade,theimpacttheywillhaveonthetargetedpersonasshould
betakenintoconsideration.
Afrequentmistakeistodesignforsomeonewhoisclosetothe
productbutisnottheactualusertheITmanagerwhopurchasedthe
productwillrarelybetheonetoactuallyuseit.(Cooper,1999)
Advantages
Personashelpteammembersshareaspecific,consistent
understandingofvariousaudiencegroups.Dataaboutthe
groupscanbeputinapropercontextandcanbeunderstood
andrememberedincoherentstories.
Proposedsolutionscanbeguidedbyhowwelltheymeetthe
needsofindividualuserpersonas.Featurescanbeprioritized
basedonhowwelltheyaddresstheneedsofoneormore
personas.
Provideahumanfacesoastofocusempathyonthepersons
representedbythedemographics.
Disadvantages
Personasarefictionalsothereisoftenatendencytocreate
personasthatembodytraitsthatarecommontomostusers,
butindoingsocreatingagenericuserthatisnotdistinctor
realistic.Thiscanleadtosoftwarethatisdesignedtobe
everythingtoeveryone.
Personasmaynotbeagoodsubstituteforarealuser,iftheyare
available.Personascandistanceateamfromausercommunity.
4.1.3 Value Stream Mapping
.1 Purpose
Valuestreammapping(alsoknownasmaterialandinformationflow
mapping)providesacomplete,factbased,timeseriesrepresentation
ofthestreamofactivitiesrequiredtodeliveraproductorserviceto
thecustomer(internalorexternal).Itisusedtoidentifyareasof
potentialimprovementinanendtoendprocess.
.2 Description
Valuestreamrepresentstheflowofmaterialandinformationrequired
tobringaproductand/orservicefromrawmaterialtothecustomer.
Valuestreammap(VSM)isagraphicalrepresentationthatcapturesa
snapshotofthevaluestream.
Thetwomaintypesofvaluestreammapthatarewidelyusedare:
CurrentStateValueStreamMap:Depictsavaluestreamasitis
appliedbythosewhoareresponsibleforcarryingit.Itis
usuallyusedasastartingpointforanalysisofanexisting
processtoidentifyimprovementopportunities.
FutureStateValueStreamMap:Derivedfromthecurrentstate
anditshowswhatthevaluestreamwilllooklikeafterthe
implementationoftheimprovements.
Inanagileenvironment,thisdiagramisusuallysimpleanddrawnona
whiteboard.Itcanbeusedtohelpreengineerbusinessprocessesto
optimizeuseofsoftware.Itcanalsobeusedtoreengineerandtune
thesoftwaredevelopmentprocessitself,forexample,toreducelead
timefromproductdiscovertorelease.
.3 Elements
Thefollowingisabroaddescriptionforoneapproachtobuildinga
valuestreammap.
Prepare
Gathercrossfunctionalteam.Intheagileworldthisshould
includepeoplewithbusinessdomainknowledgeandtechnical
teammembers(suchasdevelopers,testers,andarchitects).
Oftensomeoneactingasthebusinessanalystwillfacilitatethe
session.
Assignavaluestreammapowner.Ideallythisissomeonewho
hasadeepunderstandingofthecurrentprocess.
Selectaproduct,aproductfamily,oraservice,anddefinethe
scopeofthevaluestreammap.
Inthecontextofagileprojects,valuestreammappinglooksat
theflowofinformationneededtocompleteabusinessprocess
fromendtoendandthehandoffsbetweenrolesand/or
organizationalunitsinthatprocess.
Create Current State
Thecurrentvaluestreammapcanbecapturedfollowingthesesteps:
Observeorsimulatevaluestream.Followaproduct(orproduct
family)pathbystartingattheendclosesttothecustomerand
recordtheprocessworkingyourwaybackwardstothe
beginning.Simulatingthevaluestreamcanbedoneindifferent
ways.Teammembersmightstartwiththestepstheyare
responsiblefor,oritcanbeachievedinagroupworkshopwith
thecrossfunctionalteam.
Drawthevaluestreammap.
Capturetheinformationflow.Theinformationthatisvitalfor
thevaluestreamtofunction.Informationflowincludes(butnot
limitedto)thingssuchasorders,schedules,inventorytime,
changeovertime,cycletime,andnumberofoperatorsinvolved.
Buildamodelthatshowseachstepintheflowwithhandoffs
andsequence.Toassistintheanalysisneededtoidentify
opportunitiesforimprovementintheprocess,ensurethatyou
includetime/costvaluesontothestepsintheprocess.These
timevaluesmaybeestimated,ifneeded.Themoredetails
available,theeasieritistoidentifyimprovement
opportunities.
Validatethevaluestreammap.Theinitialdraftofthecurrent
valuestreammapmustbevalidatedbeforeproceedingtothe
improvementphase.Teammemberscanusedirectobservation
oftheworkplaceforthispurpose.
Analyze Current State
ThecurrentvaluestreammapcanbeanalyzedasdescribedinRoot
CauseanalysisoftheBABOK
Guide(9.25RootCauseAnalysis)to
identifyvalueaddedsteps(suchastransformationprocesses)from
thosethatarenonvalueadded(suchasexcessiveinventories).
Thenonvalueaddedstepscanbeanalyzedfurthertodetermine
whichonesarenecessary(suchasmeetingregulatoryrequirements)
andwhichonesareunnecessary(suchasexcessivepaperwork).
Create Future State
Thefuturestatevaluestreammapcanbedrawnasfollows:
Identifyimprovementareas.Unnecessarynonvalueadded
stepsarethesourceofwasteand,assuch,theycanbe
eliminated.Teammemberscanmarktheseareas(suchas
reducingleadtime)onthecurrentvaluestreammap.
Capturethefuturestatevaluestreammap.Drawthevalue
streammapthatshowswhatthevaluestreamwilllooklike
afteryouhaveeliminatedthewaste(unnecessarywaittime,
excessiveadministrativepaperwork,highinventories).
Oncethefuturestateiscaptureditwillbeusedasthetargetstateof
theimprovementinitiative.
Implement Process Improvement
Identifysupportingmaterialrequiredforimplementingthe
improvementsuchastrainingandchangeover.
Implementtheimprovementfollowingoneofthewellknown
businessprocessmethodologiessuchas,butnotlimitedto,
LeanorSixSigma.
Inanagileproject,valuestreammappingwillbemostutilizedwhen
implementingprocessimprovement.Oftenthechangestobemadein
thebusinessprocesswillrequirechangestoorimplementationof
supportingsoftwareproducts.Therequirementsforthesechangesor
enhancementsbecomebacklogitemsthatfeedintoanagileinitiative.
Oncetheimprovementismade,thefuturestatebecomesthecurrent
valuestreammapanditcanbeusedasastartingpointforanother
improvementcycle.
Thefollowingisanexampleofavaluestreammap.
FIGURE 4.7 ValueStreamMap
S
C

L 1
1

C
l
8 M C
C C
l
1

C 1
l
1
l
1
C 1

C 1
M
l
l
l
L
l
M

u

M

Techniques Think as a Customer
Advantages
Morecomprehensivethanaprocessflowdiagram.
Providesablueprintforimplementingimprovement.
Establishesasharedunderstandingofprocesswastesand
bottlenecks.
Providesacommonvisuallanguagefordiversestakeholders.
Disadvantages
Noteasytoconstructincomparisonwithothervisualmodeling
techniques.
Canlookdauntingbecauseofalltheinformationcaptured.
Mappingparalysis.Itiseasytogetcaughtmakingthevalue
streammapcompleteandperfectinsteadofproceedingtothe
improvementstage.
Doesntworkwellinknowledgebasedornonlinearwork.
Leadstodisruptiveorreengineeringapproach.Doesntwork
wellwithongoingimprovementefforts.
4.1 Think as a Customer
Thinkinglikeacustomerisakeycomponentofagilebusinessanalysis.
Thecustomeristhepersonwhogetsvaluefromtheproductweare
building.Westartwithahighlevelviewofcustomergoalsand
progressivelydecomposetheseintoamoreandmoredetailed
understandingofthespecificneedsthattheproductmustmeet.
Agileprocessesincorporatefeedbackloopstocontinuouslyvalidate
thisunderstanding.Asproductdeliveryprogresses,thecustomerand
teamunderstandingoftheneedswillevolve,itisimportantthatthese
changesinfluenceanddefinetheworkoftheteamgoingforward.
Agileanalysisslicesthedeliveryintothesmallestpracticalincrements
thatdeliverbusinessvalueoverthelifeoftheproject.
Itisimportantthatagileanalysisstartwithaholisticperspective,in
ordertohelptheteamunderstandtheoverallproductthatneedstobe
delivered.Theteamcollaborateswiththecustomertoconsiderthe
userexperienceexpected.
Think as a Customer Techniques
Agoalofanalysistoensurethevoiceofthecustomer,especiallythe
enduser,iselicitedandexpressedintheproduct.
Backlogitemsrepresentworktobedoneandconveycustomer
thinking,andcanberepresentedthroughprototypes,userstories,use
cases,minimalmarketablefeatures,features,epics,orworkitems.
Thetechniqueslistedbelowarebasedonuserstories:
Story Decomposition
Story Elaboration
Story Mapping
User Story
Atechniqueforprototypingauserinterfaceandusingthattodefine
detailedrequirementsis
Storyboarding
4.1.1 Story Decomposition
.1 Purpose
Storydecompositionisaderivationofexistingrequirementsanalysis
techniquessuchasfunctionaldecomposition.Inanagilecontext,
storiesareoftenusedtorepresenttheworkoftheteamandthe
requirements(oracceptancecriteria)ofthatwork.Story
decompositionensuresthattherequirementsforaproductare
representedattheappropriatelevelofdetailandarederivedfroma
valuablebusinessobjective.
Thistechniqueprovidesastructurefordefiningthevariouselements
ofrequirementsatprogressivelysmallerlevelsofgranularity,starting
withthebroadsystemcontextanddrillingdowninmultiplelevelsto
eventuallydefinethedetailedacceptancecriteriaforindividualuser
stories.
.2 Description
Themostcommonagileapproachtostorydecompositioncanbe
describedasbreadthbeforedepth:startwithaveryhighlevel
pictureofwhatbusinessgoalsneedtobeachieved,decomposethose
intosmallercomponentsthatprovideincrementsofvaluable
functionality(sometimescalledminimallymarketablefeaturesetsor
MMFs),splitthecomponentsintouserstories,andeventually
elaboratetheuserstorieswithacceptancecriteria,seeStory
Elaborationonpage59.Astorythatistoolargeorinsufficiently
understoodtoelaborate,estimate,ordeliverasastoryissometimes
calledanepic.Epics,whenused,arelaterdecomposedintosmaller
stories.
FIGURE 4.8 StoryDecomposition
Differentteamsapplythistechniqueindifferentways.Forexample,
someteamsfollowthemodellinearly,asshownintheabovediagram,
whileotherteamsutilizetechniquesthatworkbestintheir
environment.Forexample,onceateamhasdevelopedtheMMF
(sometimesreferredtoasfeaturegroups),theymayemployusecases
insteadofstories.Theanalystsrolehereistofocusondynamic
collaboration,facilitation,andcommunicationingettingacceptance
forjustwhatisrequiredtodevelopanddelivertheproduct.
System GoaIs
MinimaIIy MarketabIe
Feature / Component
User Stories
With Acceptance
Criteria
Epics
MinimaIIy MarketabIe
Feature / Component
User Stories
User Stories
With Acceptance
Criteria
User Stories
Thefollowingtabledescribesthedifferentlevelsofstory
decomposition.
TABLE 4.4 StoryDecomposition
StoryDecompositionisundertakenprogressively.Oneofthemost
significantdifferencesbetweenagileprojectsandwaterfallprojectsis
inthedefinitionofdetailedrequirements.Inagileprojects,theinitial
analysisactivitieswillidentifythegoals,MMFs,andmostoftheepics.
Theinitialsetofuserstories(probablyforthefirstreleaseofthe
product)willbedoneintheprojectinitiationactivities.Thereisaclear
understandingthatthesestoriesarelikelytochangeandthatthe
teamsunderstandingoftherequirementswillevolveovertime.
Therefore,decomposingtothelowestlevelofdetailislikelytobea
wastefulactivityearlyintheproject.
Advantages
Thisdecompositiontechniquehelpsavoidthecommon
problemofgettinglostinthedetailoftheuserstoriesand
losingthebigpicturecontext.
Itisimportantthatteammemberskeeptheprojectsgoalsand
objectivesinmind,andwhileusingthedecomposition
approachtheyareabletotraceimplementedorrequested
functionalitybacktothedrivingbusinessobjectives.
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.
BreakingtheproductintoMMFsandepicshelpswithrelease
levelplanning,providesvisibilityintothedevelopmentproject,
andhelpscoordinateexternalprogramactivitiessuchas
organizationalchangemanagementandusertraining.
Disadvantages
Acommonantipatternisthetemptationtotreatstory
decompositionasawayofrevertingtodetailedrequirements
upfront.Ensuringthecontinuedemphasisonjustenoughand
justintime,meansknowingwhentostopdecomposing.
4.1.2 Story Elaboration
.1 Purpose
Storyelaborationisatechniqueusedtodefinethedetaileddesignand
acceptancecriteriaforauserstoryonajustintime/justenough
basis.Storyelaborationisanongoingactivitythatispartofthe
developmentprocess.
.2 Description
Storyelaborationisthelowestlevelofstorydecompositionandthe
processbywhichthestorysentenceisintobrokendownintopiecesof
work.Thisisoftendonebysomeoneontheteamwhohasstrong
businessanalysisskills,particularlywithfacilitationand
communication.Storyelaborationisthetechniquethroughwhich
detailedrequirementsareelicitedandcommunicatedtotheproject
team.
Duringeachrelease(iteration/sprint),theteamthatworksonastory
schedulestimetoexpandonthestorytounderstandthedetail.Often
(butnotalways)thisiscompletedinashortworkshopwiththe
programmerswhowillworkonthestory,thebusinessSME/customer
whoneedsthestory,thepersonwhowilltestthestory,andsomeone
actingasabusinessanalysttofacilitateandchallengethestory.
Typically,storyelaborationisundertakenafewdaysaheadofthe
developmentofthestory.
Storyelaborationisacommunicationtechniquethathelpsensurethe
correctproductisbuilt.Inanagileproject,thedetailedrequirements
areproducedbystoryelaboration.However,asopposedtowaterfall
approaches,andconsistentwiththejustintimephilosophyofagile,
thedetailedrequirementsdefinedduringstoryelaborationcontain
onlytherequirementdetailsforthepieceofworkthatistobe
completedinthecomingrelease.
.3 Elements
Theresultofstoryelaborationisasharedunderstandingamongthe
participantsofwhatthestorymeansandwhatshouldbedeliveredto
achievetheDonestateforthisstory.Theroleofthebusinessanalyst
indevelopingandcommunicatingdynamicrequirementsnecessitates
ahighdegreeofskillinbothfacilitationandcommunication.
Theoutputsofeffectivestoryelaborationdescribeand/ordocument
thetasksthatenabletheteamtosuccessfuldelivertheupcoming
iteration.Theseoutputsmayinclude
detailedrequirementsfortheupcomingrelease,
taskdefinitionsandbreakdowns,
examplesandscenariosthatexplainthecustomer'sintentfor
thestory,
lowfidelitymodelsthatclarifythetechnicalorprocessdesign
(forexample,datamodels,dataflowdiagrams),
screenorreportmockups,
acceptancecriteria(testdesignspecifications)toclarifyhow
thestorywillbetested,ofteninthe<given><when><then>
formatofbehaviordrivendevelopment,and
otherartifactsthatwillbeusefulinthedevelopmentand
testingofthisstory.
Advantages
Themajoradvantageofstoryelaborationisthatitavoids
wastefulrequirementselicitation,andpotentially
documentationaswell.Byelaboratingonrequirementsonlyas
theyareneeded,theteamavoidstheworkofeliciting
requirementsforfeaturesthatmayneverbebuiltorthatwill
needtobechangedbythetimetheyarereadyfor
implementation.
Disadvantages
Forthosewhoarerelativelynewtoagilemethodologies,itcan
bedifficulttodeterminethebesttimingforconductastory
elaboration.Ifconductedtooearly,theinformationmayno
longerbecorrectforthegivenreleaseandwillneedtobere
elicited.However,whencollectedtoolate,itcandelayproject
teamprogressiontodevelopment.
Anotherchallengetoimplementingstoryelaborationisthe
abilitytoelicittheappropriatelevelofdetailsuchthatthe
requirementscanbedeveloped,tested,andcomparedto
acceptancecriteria.
Timing
Storyelaborationshouldbedoneonanasneeded,justintimebasis
forstoriesthathavebeendeterminedtobeinscopefortheupcoming
release.Theprojectteamshouldnotinvestigatestoriesforfurther
elaborationiftheyhavenotbeenplannedforthereleaseinquestion,
astheinformationcollectedmaybestaleandoutofdate.
4.1.3 Story Mapping
.1 Purpose
Storymappingprovidesavisualandphysicalviewofthesequenceof
activitiestobesupportedbyasolution.Itusesatwodimensionalgrid
structuretoshowsequenceandgroupingsofkeyaspectsofthe
productonthehorizontaldimension,withdetailandpriorityofstories
ontheverticaldimension.
.2 Description
Astorymapisatooltoassistincreatingunderstandingofproduct
functionality,theflowofusage,andtoassistwithprioritizingproduct
delivery(suchasreleaseplanning).Itisadecompositiontechnique
thatallowsfortheevolutionaryunderstandingofaproductstarting
withanendtoendviewanddrillingdowntothedetaileduserstories.
Astorymapisdesignedtobeaninformationradiator,usedto
visualizeaproduct'srequestsinthecontextofusageandpriority.The
storymapisoftenplacedondisplayfortheprojectteamduring
releaseplanningsessions.Byanalyzingthestorymap,theteamcan
morereadilyidentifydependenciesgeneratedasaresultofthe
intendedflowthroughtheuserstories.Themapcanalsobeusedfor
riskassessmentandmanagementbyexamininghowthestorieswill
needtoworktogetherinthecontextofdeliveringbusinessvalue.
Thefollowingillustrationisanexampleofastorymap.
FIGURE 4.9 StoryMap
.3 Elements
Thestorymaphasacentralbackboneofelementsthatwillmakeup
theproduct.Abovethisbackbonearethelargefeaturesets(activities)
thatneedtobedeliveredoverthelifeoftheproject.Thebackboneisa
sequentialsetofoperator/customertasksthatneedtobeenabledby
thesoftware.Belowthebackbonearethedetailedstoriesthat
implementthespecificpiecesoffunctionalitytoenablethetaskstobe
accomplished.
Process
Theprocessofbuildingastorymapcanbedescribedasaseriesof
steps.
1. Identifythekeyactivitiestheproductmustsupport,writingeach
activityonaseparatecardoradhesivenote.Useonecolorforthe
activitycards.
2. Sequencetheseinorderofusage,fromlefttoright.Whilethe
sequenceinwhichactivitieswillbeperformedwillvary,therewill
beacommondayinthelifeofsequencewhichcanbeused.
Theseactivitieswillnormallybetoolargetoimplementinasingle
developmentiteration.
3. Oncetheactivitiesareinalogicalorder,definetheindividualtasks
thatmakeuptheactivities.Thesetasksshouldbeadiscretepieceof
workforsomeoneoperatingtheproduct.Writeeachtaskonasepa
ratecardoradhesivenote,usingadifferentcolorfromtheactivities.
4. Placethetasksonasinglerowinlogical,sequentialorderunder
neaththeactivities.Again,therewilloftennotbeastrictsequence
whichmustbefollowedeverytime,buttherewillbeacommonlog
icalorderinwhichtasksaredone.Thisisthesequenceofthetasks
onthemap.
5. Validatetheactivitiesandtaskswithdomainexpertsandother
stakeholders.Askthequestion:dotheyconstituteacompletepic
tureofwhattheproductneedstodeliver?Updateandamendthe
activitiesandtasksasneeded.
6. Addsubtasksbelowthetasks,againusingadifferentcolorcardor
adhesivenote.Thesewilloftencoverthealternativewaysofunder
takingataskordealwithexceptionsorpotentialproblemswhen
performingatask.Addthesebelowthetaskinatoptobottomlogi
calorderbasedonuserpriority.Thesesubtasksareatthelevelof
theuserstoryandtherewillbemanyofthem.Viewingthetoprow
ofsubtasksacrossthemapprovidesaviewofthelikelyminimum
viableproduct,thesetoffeatureswhichmustbedeliveredforthe
producttohaveanyvalueatalltothebusiness.Thishorizontalview
oftheuserstoriesprovidesalogicalstartingpointforreleaseand
iterationplanning,asthevertIcalpositionofauserstoryshowsits
relativepriorityintheoverallpicture.
7. Validatethestorymapwithstakeholdersandupdateitasneeded.
8. Keepthestorymaptogethertoprovideabigpictureviewofthe
completeproduct.Indicatewhenstoriesarecompletedonthestory
mapsooverallprogressisclearlyvisible.
Advantages
Whenthelargercontextofaproductisnotaccountedfor,agile
projectscanbesubjecttogettingmiredinthedetailswithan
inabilitytoeffectivelystringcomponentstogethertocreate
endtoendbusinessvalue.Storymappinghelpsavoidthe
commonproblemofgettinglostinthedetailoftheuserstories
andtheriskoflosingthebigpicturecontext.
Disadvantages
Storymappingcanbecomecumbersomewheretheproductis
verylargeandmayrequirebuildinganumberofstorymaps
thatcoveralargeprogramofwork.Whilestorymapsillustrate
aflow,theydonotanalyzeorillustratedependenciesbetween
requirements(thoughtheycanbeusedtohelpfacilitatethat
analysis).
4.1.4 User Story
UserStoriesaredescribedindetailintheBABOK
Guide(9.33User
Stories).Thisinformationfoundherereflectsandexpandsonthat
informationinthecontextofagiledevelopmentmethodologies.
.1 Purpose
Auserstoryrepresentsasmall,concisestatementoffunctionality
neededtodelivervaluetoaspecificstakeholder.
Userstoriescanbeused:
tocaptureandprioritizeuserneeds,
asabasisofestimatingandplanningproductdelivery,
asabasisforgeneratinguseracceptancetests,
asametricformeasuringthedeliveryofvalue,
asaunitfortracingrelatedrequirements,
asabasisforadditionalanalysis,and
asaunitofprojectmanagementandreporting.
.2 Description
Userstoriesareaplanningtechniquethatenablesagileteamstotrack
featuresofvaluetoacustomerorenduser,andareusedasabasisfor
estimatingwork.Typically,theyareoneormoresentenceswrittenby
thecustomers,productowners,orbusinessanalyststhatdescribe
somethingofvaluetoastakeholder.Userstoriesprovideamechanism
fortheproductownertoscope,coordinate,andprioritizethe
incrementsofuservaluefordevelopment.Astoryshouldbeshort
enoughtobewrittenonasmallpapernotecard,usuallya35inch
indexcardorstickynote.Storiesmayalsoberecordedinanelectronic
system.
Userstoriescapturestakeholderneedsusingshort,simple
documentationandinviteexplorationoftherequirementsthrough
conversations,tests,and/orsupplementalrequirements
representations,asneeded.Theyareconciseandeasytochangeas
stakeholderneedsarebetterunderstoodorasthoseneedsevolve.
Someteamsmakeuseofothertypesofstoriestocatalogue,estimate,
plan,andtrackotherworkneededtobuildtheproduct.Thesestories
typicallydefineworkneededtoenableproductdevelopment,
deployment,andsupport.
.3 Elements
Title (optional)
Thetitleofthestorydescribesanactivitythattheuserwantstocarry
outwiththesystem.Typically,itisanactiveverbgoalphrase,similar
tothewayusecasesaretitled.
Description
Thereisnomandatorystructureforuserstories,however,themost
popularformatincludesthreecomponents:
auserroleorpersona[WHO],
anecessaryaction,behaviour,orfeature[WHAT],and
thebenefitorbusinessvaluereceivedbytheuserwhenthe
storyisimplemented[WHY].
Usageexample:
Asa<role>,Ineedto<behavior>sothat<businessvalue>
Analternativeformat,preferredbythosewhopracticebusiness
analysisinAgiledevelopmentis:
Inorderto<businessvalue>,asa<role>,Ineedto<behavior>
Thiscanonicalformatcanalsobeusedforstoriesprovidedfromother
productorprojectconstituents.Forexample:
AsaSecurityOfficer,Ineedtoonlyallowauthorizeduserstoaccess
thexyzfunctionalitysoIcaninsureweenforceabcsecuritydirective.
Conversation
Userstoriesserveasareminderthattheteamneedstoexploreand
understandthefeaturedescribedinthestoryandthevaluethatitwill
delivertothecustomer.Thestoryitselfdoesn'tcaptureeverything
thereistoknowaboutthecustomerneed,andtheinformationinthe
storywillbesupplementedbyfurthermodelingasthestoryis
delivered.
Acceptance Criteria
Whenauserstoryiswelldefinedandunderstood,itisaccompaniedby
acceptancecriteria.Acceptancecriteriadefinetheboundariesofauser
storyandhelpproductowners,customers,orbusinessanalyststo
answerwhattheyneedtoprovidevaluewiththeproduct.
Acceptancecriteriahelpdevelopersidentifywhentostopaddingmore
functionalityandtoderivetestsforverificationandvalidation
purposes.Acceptancecriteriaaretypicallyaddedjustbeforeplanning
orjustintimeduringdevelopment.Theycanalsobedevelopedasa
storybecomeswellunderstoodtoenablethedevelopmentteamto
verifythatthesolutionwillmeettheusersneeds.
Acceptancecriteriaareoftenbuiltshortlypriortoorinparallelwith
theimplementationoftheuserstory.
Advantages
Tiedtosmall,implementable,andtestableslicesof
functionalityfacilitatingrapiddeliveryandfrequentcustomer
feedback.
Easilyunderstandablebystakeholders.
Canbedevelopedthroughavarietyofelicitationtechniques,
includingbutnotlimitedtofacilitatedworkshops,contextual
inquiry,andotherethnographicelicitationtechniques.
Userstoriesaresimpleenoughthatpeoplecanlearntowrite
theminafewminutes,beingcarefulaboutalwaysdeliver
businessvalue.
Theprocessofcollaboratingondefiningandexploringstories
buildsteamcommitmentandsharedunderstandingofthe
businessdomain.
Storiesinviteconversationforfurtherdecompositionand
exploration.
Disadvantages
Thisconversationalapproachcanchallengetheteam,since
theydonothavealltheanswersanddetailedspecificationsup
front.
Tofacilitateestimating,planning,anddelivery,manyagile
teamssupplementstorieswithanalysismodels(suchasadata
model,businessrules,useracceptancetests,screenmockups
orprototypes,contextdiagram,andstatediagram)
Large,chunkystories(epics)canbevagueanddifficulttouse
withoutbreakingthemdownintosmallstories.
Storiesspawnmorestoriesviadecompositionsothe
informationmustbeorganizedtoensureitiscurrentand
relevant(calledpruningorgrooming).
Thecollectionofstoriesneedstobemanaged(forexample,
withbacklogmanagement).
Storiesrequirecontextorlineofsight.Iftheteamdoesnttrace
storiesback(throughvalidation)orsupplementthemwith
higherlevelanalysisandvisionartifacts,thentheteamcanlose
sightofthebigpicture.
Somepractitionerscanbeconfusedamongstuserstories,use
case,andstoriestechniques.
4.1.5 Storyboarding
.1 Purpose
Storyboardingisusedinconjunctionwithothertechniquessuchas
usecases,userstories,andprototypingtodetailvisuallyandtextually
thekeyeventssummingupdifferentinteractionsofuserswiththe
systemorbusiness.
Storyboardingserves
toelicit,elaborate,organizeandvalidatetherequirements,
tocommunicatetodeveloperswhatneedstobebuilt,
toshowdifferentvariationsoftheproposedsolution,and
asaninputtotests.
.2 Description
Storyboards(alsoknownasdialogmap,dialoghierarchy,or
navigationflow)userepresentativeimagesandtexttodescribeatask,
ascenario,orastory.Itcanalsobeusedwithprototypingtechniqueto
representpartsofthesystemthatarewellunderstoodorexpensive
andunnecessarytoproduceviaformalprototypes.
Whenusedtodescribetheinteractionwiththesystem,thestoryboard
showshowscreenswilllookandhowtheywillflowfromoneto
another.Whenusedtodescribebusinessorganization,thestoryboard
showstheinteractionwithabusinessprocesssuchasbackoffice.
Storyboardscanbedevelopedusingwhiteboardsandstickynotesor
usingCASEtools.
Storyboardsarecommoninmanyanalysisanddevelopment
methodologies,andareaformofprototyping(seetheBABOKGuide,
9.22Prototyping).However,asagilemethodsfavourthedevelopment
ofworking,usablesoftwareoverthrowawayprototypes,
storyboardingisausefultoolforunderstandinghowpeoplewill
actuallyusethesystem.
.3 Elements
Storyboardscanbecreatedinaworkshopenvironmentwithrelevant
stakeholders.
Preparation
1.Identifymainscenarioswithinthescopeoftheproject.Thiscanbe
drivenfromusecasesoruserstoriesorcanbeidentifiedina
customervisitoraninformationgatheringsessionwithexperts.
2.Selectthescenariosthatneedtohaveastoryboarddeveloped.While
somescenariosneedtobedetailedinastoryboard,othersare
obviousandcanbeomittedsuchasalternatescenariosand
exceptions.
3.Identifyparticipantsandschedulethesession.
4.Arrangeroomandequipmentsuchasflipcharts,markers,glue,
scissors,rulers,printers,andaccesstotheInternet.
Session
1.Haveattendeescreateillustrationsforthestoryboardsofthe
selectedscenarios.
2.Enhancestoryboardillustrationswithtextualinformationsuchas
optionalinteractions,unavailableinteractions,furtherstakeholder
requestsnotassociatedwiththeprimaryscenario,andgeneral
notesassociatedwithaspecificstep.
3.Makesureeachstoryboardstandsonitsownbyaddingrequired
explanationsastext.
Wrap up
Attheendofthesession,thebusinessanalystreaches
consensusonthehighlevelflowofthedevelopedstoryboards.
Aftertheworkshop,thebusinessanalystmightusecompany
templatestoformallydocumenttheoutcomeofthesession,adding
additionalelementstothestoryboardssuchasstoryboard
identification,description,user,trigger,input,output,andissues.The
businessanalystmayalsouseCASEtoolstocreaterepresentative
screensthatwillbeusedforlatervalidation.
Advantages
Intheearlystagesoftherequirementsgatheringprocess,
storyboardingcansignificantlyreduceabstractnessbroughtby
othertechniquessuchasusecasesanduserstories.
Storyboardscanbeproducedquicklyandataverylowcost
comparedtoothertechniquessuchasprototypes.
Theintuitivenatureofthestoryboardencouragesstakeholder
participation.
Disadvantages
Differentlookandfeelthanthefinalproduct.
Easytogetboggeddownonhow,ratherthanwhy.
Analyze to Determine What is Valuable Techniques
4.1 Analyze to Determine What is Valuable
Theagileapproachisdistinctinthatvalueiscontinuouslyassessed
andprioritizedtoensurethatthemostvaluableworkisdeliveredat
anypointintime,alwaysusingtheendcustomerperspective.Itisalso
imperativetoquestionthepurposebehindrequirements,challenging
thoserequirementsthatdonotsupportthebusinessgoals.Agile
practicesenabletheartofmaximizingtheamountofworknotdone,
somethingessentialtodelivervaluablesoftwareearlyand
continuously.Thetechniquesoutlinedinthissectionfacilitatethe
valuationofproductneedsonanongoingbasis.
Backlog Management
Business Value Definition
Kano Analysis
MoSCoW Prioritization
Purpose Alignment Model
4.1.1 Backlog Management
.1 Purpose
Thebacklogisawishlistofrequestsforfeaturestobeincludedina
product,andisthemainmechanismformanagingrequirementsonan
agileproject.
.2 Description
Theproductbacklog,whichderivedfromtheScrumframeworkis
leveragedinmanyblendedagilemethodologies,isestablishedatthe
beginningofaproject.Thebacklogisafluiddocumentthatevolves
overthecourseoftheprojectasmoreislearnedabouttheproductand
itscustomers.Theproductownerisresponsiblefororderingtheitems
onthebacklogbasedonbusinessvalue,featureimportance,orother
relevantcriteria.Whenmanagingabacklog,itemsshouldbeordered
suchthatthemostimportantitemsoccuratthetopofthelistandare
orderedbasedondescendingpriority.InXP,thebacklogoffeature
requestsmaybemanagedasalogofuserstories.Abusinessanalyst
mayactastheproductownerorsupporttheproductownerrole.
Techniques Analyze to Determine What is Valuable
Duringthereleaseplanningsessions,itemsareselectedfromthe
backlogbasedonfactorssuchaspriority,risk,valuetotheproductor
customer,andabilitytodeliverthefeaturewithinthegivenrelease.At
theendofeachrelease,feedbackonwhatwasdevelopedmayresultin
newitemsbeingaddedtothebacklog,changedpriorities,orremoved
items.
Thebacklogissometimesreferredtoasaportfolioofoptionsthatthe
businesscaninvestin.Othertermsusedaremasterstorylistand
prioritizedfeaturelist.
.3 Elements
Items in the Backlog
Thebacklogcancontainuserstories,usecases,features,functional
requirements,aswellasitemsthathavebeenaddedbytheteamto
supportdevelopmentoftherequirements,suchastechnical
infrastructure.Toaidinorderingthebacklog,itemsshouldbe
expressedinsuchawaythatthebusinessvalueoftheitemsisclear.
Productriskmitigationitemsmayalsogetaddedtothebacklogas
storiesorpiecesofworktobedone.
Appropriate level of detail
Itemswithhighorderinthebacklogwillbedevelopedinnearterm
releases,sotheyneedtobedetailedenoughtoallowthedevelopment
teamtoestimatethemwithaccuracyandbeabletodecomposethem
intothetasksneededtodevelopthem.Itemswithlowerprioritycan
remainhighlevelandlesspreciseuntiltheyriseintheorderandneed
tobespecifiedinmoredetail.Largeitemsinthebacklogare
sometimesreferredtoasepicsorbusinessvalueincrements,andmay
bebrokendownintomultiple,moregranularitemsasthebacklogis
elaboratedviastorydecomposition.Someaspectsofthestorymaybe
importantneartermandotherslessimportant.Thisabilitytobreak
storiesdowninthebackloghelpsprotecttherateofvaluedelivery.
Forexample,addinganewfeaturemayhaveinvolvedhardcoding
somethingupfrontandaddinganewstorytothebacklogtoaddsome
dynamicconfigurationabilitytotheproductlater.
Estimation Accuracy
Itemswithhighorderinthebacklogneedtobeestimatedwithenough
accuracytousethemforplanningreleases.Itemsinlowerorderalso
needtobeestimated,butwithlessaccuracysincetheyareoftenless
detailed.Estimatesfortimetocompleteitemsisoftenmaintainwithin
thebacklogitself.
Prioritization
Itemsinthebacklogareorderedrelativetoeachother.Orderingcan
beestablishedusingnumbering,valuepoints,high/medium/low,or
anyotherprioritizationtechnique.Theorderofitemsonthebacklogis
likelytochangeoverthecourseoftheproject,especiallyasthe
productevolvesandtheteamreceivesfeedbackfromthestakeholders
andcustomers.Itisimportanttonotethatorderingneartermitemsis
important,butputtingalotofeffortintoorderingthebacklogfarinto
thefuturecanbeawastefulactivitybecausethefartheroutbacklog
itemsaresubjecttochange.
Managing Changes to the Product Backlog
Thebacklogisthemainmechanismforbothmanagingchangetothe
requirementsonanagileprojectandforcontrollingscope.Whennew
orchangedrequirementsareidentified,theyareaddedtothebacklog
andorderedrelativetotheotheritems.Thebacklogisalsousedto
trackandmanagereporteddefectsorbugs.Orderingtheentire
backlogcanbedoneupfrontusingrelativeimportancedesignations
(basedonbusinessvalue),whichallowshighlevelprioritization
withouttoomuchgettingintotheweeds.Sincereleasesanditerations
aretimeboxedonagileprojects,theitemsloweronthebacklogare
oftennotincludedinagivenrelease.Rigorousorderingofthebacklog
allowstheteamtocontrolthescopeoftheprojectandreleases.
Whenanitemisdevelopedandacceptedbytheproductowner,the
itemisremovedfromthebacklogandmovedtoanotherdocument
suchasthereleaseplanorsprintbacklog.Theproductownerroleis
responsibleformanagingthebacklog,addingandorderingnewor
changeditems,removingcompleteditems,andrevisingtheorderon
anongoingbasis.Thisprocessissometimesreferredtoaspruningor
groomingthebacklog.
Advantages
Sincetherequirementsonthebacklogareorderedin
importance,theteamknowsthatwhattheyareworkingonina
giveniterationishighpriorityandwillcontributebusiness
valuetotheproduct.Thepersonontheteamresponsiblefor
detailingtherequirementscanreviewthebacklogand
determineiftheitemsthatwillbedevelopedinanupcoming
releaserequirefurtheranalysisinordertoreadythemfor
development.Thisprocessisreferredtoasbuildingthe
requirementsrunway.
Sinceeachreleasetypicallyimplementsasmallsetof
requirements,requirementsareanalyzedindetailonajustin
timebasis.Whattheteamandthestakeholderslearnaboutthe
requirementsdevelopedduringareleasecaninformthe
analysisofotherrequirementsinupcomingiterations.
Disadvantages
Largebacklogsmaybecomecumbersomeanddifficultto
manage.Breakingtheoverallproductbacklogintobacklogsfor
releases(calledreleasebacklogs)canhelpaddressthis
disadvantage.Also,alackofdetailinthestoriesinthebacklog
canresultinlostinformationovertime.
Timing
Thebacklogisdevelopedatthebeginningofanagileproject,butit
doesnotneedtobecompleteatthistimesinceitwillcontinueto
evolvethroughouttheproject.
4.1.2 Business Value Definition
Inorderforaprojecttodelivervalue,theymustfirstbeabletoidentify
whetherarequestisactuallyvaluabletotheorganization.Withouta
clearunderstandingofbusinessvalue,itispossiblefortheprojectto
deliversomethingthatsoundsvaluablebutisactuallynot.
Aprojectcreatesbusinessvaluewhenitdeliversanythingthat
contributestoanorganization'sstatedprimarygoals,forexample
increasingorprotectingrevenue,
reducingoravoidingcosts,
improvingservice,
meetingregulatoryorsocialobligations,
implementingamarketingstrategy,and
developingstaff.
Oftenprojectscreateoptionsforthebusinesstoexploit.Forexample,
theoptiontosell1000itemsofaproductaday.
Businessvalueshouldbeexpressedintheformofamodelratherthan
anabsoluteamount.Theevolutionofthebusinessvaluemodelwill
developunderstandingofwhytheprojectisneeded.Themost
importantaspectofdevelopingabusinessvaluemodelisthe
conversationthatgeneratesthesharedunderstanding,ratherthanthe
modelandthenumbersthatthemodelproduces.
Examplesofbadbusinessvaluestatementsare:
Thisenablesstraightthroughprocessing.
Thiswillmake1milliondollars.
Thiswillsave1milliondollars.
Mr.Bigneedsthisproduct.
Noneoftheseshowalignmentwiththegoalsoftheorganization.
Anexampleofagoodbusinessvaluestatementis:
Thisprojectwillgenerateanadditional$20millioninprofit.The
modelisbasedonthefollowingassumptions:
Wemaintain25%ofthesalesofexistingproductXYZ($150
millionayear).
Thetotalcostofdesigning,producing,andmarketingthe
productis$7.5million.
Ourproductisfirsttomarket.
Weareabletoreleasetheproductinthespring.
Thisstatement,inmodelform,conveysunderstandingofwhythe
projectisneededandwouldlikelypromotevaluableconversationthat
generatesasharedunderstandingoftheproject.
4.1.3 Kano Analysis
.1 Purpose
Kanoanalysishelpsanagileteamunderstandwhichproduct
characteristicsorqualitieswillprovetobeasignificantdifferentiator
inthemarketplaceandhelptodrivecustomersatisfaction.
.2 Description
Kanoanalysisismostusefulinhelpingtosupportagiledevelopment
forcommercialproducts.Itassistsinidentifyingfeaturesthatwill
havethegreatestimpactoncustomersatisfaction,eitherbecausethey
areexceptionallyimportantorbecausetheirabsencewillcause
intensedissatisfaction.Thishelpstheteamdeterminewhichfeatures
aremostimportanttoimplementbeforereleasingaproductto
market.
Kanoanalysisratesproductcharacteristicsontwoaxes:
theextenttowhichthefeatureisimplementedintheproduct,
and
thelevelofcustomersatisfactionthatwillresultfromanygiven
implementationlevel.
Theresultinggraphisplottedona22matrix.Basedontheresulting
profile,theproductcharacteristicshouldfallintooneofthree
categories:
thresholdcharacteristics,
performancecharacteristics,and
excitementcharacteristics.
Thisanalysiscanthenbeusedtotryandidentifycharacteristicsthat
willgivetheproductauniquepositioninthemarketplace.
.3 Elements
Threshold Characteristics
Thresholdcharacteristicsarethosethatareabsolutelynecessaryfor
stakeholderstoconsideradoptingaproduct.Theirabsencewillcause
intensedissatisfactionbut,astheyrepresentminimumacceptance
criteria,theirpresencewillnotincreasecustomersatisfactionbeyond
acertainlowlevel.Thechallengewithelicitingrequirementsforthese
featuresisthatpeopleexpectthemtobepresentandsotendnotto
thinkaboutthemunlessexplicitlyasked.
Performance Characteristics
Performancecharacteristicsarethoseforwhichincreasesinthe
deliveryofthecharacteristicproduceafairlylinearincreasein
satisfaction.Theyrepresentthefeaturesthatcustomersexpecttosee
inaproduct(speed,easeofuse,etc).Requirementsforthesetypesof
featuresarelikelytomostreadilycometomindforthemajorityof
stakeholders.
Excitement Characteristics
Excitementcharacteristicsarethosethatsignificantlyexceed
customerexpectationsorrepresentthingsthatthecustomerdidnot
recognizewerepossible.Theirpresencewilldramaticallyincrease
customersatisfactionovertime.Asthesecharacteristicsarenotmet
byanythingcurrentlyonthemarket,stakeholderswillnottendto
thinkaboutrequirementsthatdescribethem.
Inordertodeterminethecategorytowhichacharacteristicorfeature
belongs,customerscanbesurveyedusingtwoformsofaquestion
aboutthefeature:thefunctionalformandthedysfunctionalform.
Functionalform:Howdoyoufeelifthisfeatureorcharacteristicis
presentintheproduct?
Dysfunctionalform:Howdoyoufeelifthisfeatureorcharacteristicis
absentintheproduct?
Possibleanswerstoeachquestionformare:
Ilikeitthatway.
Iexpectittobethatway.
Iamneutral.
Icanlivewithitthatway.
Idislikeitthatway.
Determiningthecategoryisbasedonmappingtheanswerstoboth
formsofthequestiontothefollowinggrid.Thetoprowrepresentsthe
answerstothedysfunctionalformofthequestion.Theleftcolumn
representstheanswerstothefunctionalformofthequestion.
TABLE 4.5 KanoAnalysisQuestionsGrid
E=Exciters
P=Performance
T=Threshold
I=Indifferent(Doesnotfitintooneofthe3categories)
QorR=QuestionableorReversed(theanswerdoesn'tmakesense)
Thisapproachismostapplicableforconsumerproductsorgoodsthat
willberesold,asitfocusesonidentifyingrequirementsthatwill
encouragewidespreaduseoradoptionofaproduct.The
categorizationofaparticularcharacteristictendstoshiftovertime,as
customersgrowtoexpectfeaturesorcharacteristicstobepresentina
product.Exciterseventuallybecomeastandardexpectationand
thresholdcharacteristic(thinkofthenoveltyofATMswhentheywere
firstintroduced,nowcustomersassumetheirbankwillhaveATMs).
4.1.4 MoSCoW Prioritization
.1 Purpose
Toidentifythemostcriticalsetoffeaturesorstoriesthatwilldeliver
businessvalue.
.2 Description
MoSCoWisamethodtoprioritizestoriesinincrementalanditerative
methodsandisdescribedintheBABOK
Guide(6.1Prioritize
Requirements).MoSCoWprovidesawaytoreachacommon
understandingonrelativeimportanceofdeliveringastory.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
inthebacklogarevaluable,butoftennotallofthemcanbedelivered
atthesametime.MoSCoWprovidesamechanismforprioritizing
storiesinabacklogacrossmultiplereleases.Prioritizationis
importantforanysoftwaredevelopmentmethod,butagilemethods
cannotsucceedwithoutconstantandfrequentprioritizationofwork.
MoSCoWgetsitsnamefromanacronymformedbythefollowing
classificationsofpriority:Musthave,Shouldhave,Couldhave,and
Wouldlike.Theletteroisaddedtomaketheacronympronounceable.
Theclassificationsareasfollows:
MustHave.Thesearestoriesthatmustbedeliveredforthe
currentbusinessproblemtobeaddressed.Mustcansare
thoughtofasaminimalusablesubset.
ShouldHave.Thesearestoriesthatarecriticaltothesuccessof
therelease.ShouldstoriesareasimportantasMuststoriesbut
maynotbetimecriticalormayhaveaworkaround.
CouldHave.Thesearestoriesthatlesscritical.
WouldLike.Thesestorieswilllikelynotbeincluded,butmight
eventually.
.3 Elements
ProductBacklog:Acollectionofuserstoriesdescribingthe
desiredfunctionalityofaproduct.
Strategy:Anunderstandingoftheoutcomesforaninitiative.
CustomerPreference:Clarityonwhatismostimportanttothe
customer.
MoSCoWisusefulwhentryingtoprioritizeabacklog.Unlikesome
prioritizationmethods,thismodelhelpsdifferentiatebetweenasetof
usefuluserstoriestothosespecificallyfocusedonanoutcome.
Advantages
MoSCoWiseasytodescribeandtypicallyispowerfulin
prioritizingbacklogs.
Disadvantages
MoSCoWcanbesubjective.Ifthereisnoteffectivecollaboration
withthebusiness,thismethodofprioritizationcanbe
inaccurate.
Onaprojectwhereabusinessvalueincrementsapproach
(MinimumMarketableFeatures)isused,theteamshouldonly
deliverMustHavesintheincrement.MoSCoWistherefore
inappropriate.
4.1.5 Purpose Alignment Model
.1 Purpose
Thepurposealignmentmodelisusedtoassessideasinthecontextof
customerandbusinessvalue.Fromanagileperspective,themodel
aidsinmakingprioritizationdecisionsandfocusinginvestmenton
thosefeaturesorcapabilitiesthatareofgreatestvaluetothe
organization.
.2 Description
Thepurposealignmentmodelisusedtorateactivities,processes,
products,orcapabilitiesintwodimensions,andthenrecommendthe
bestactionstotaketoimprovethembasedonthoseratings.Thefirst
dimensioniswhetherornottheactivitycreatesmarket
differentiation,theseconddimensioniswhetherornottheactivityis
criticalforthecontinuedfunctioningoftheorganization.
Thefollowingillustrationisanexampleofanpurposealignment
model.
FIGURE 4.10 PurposeAlignmentModel
.3 Elements
Differentiating Quadrant
Features,products,orservicesthatbothservetodifferentiatethe
organizationinthemarketplaceandarecriticaltothefunctioningof
thecompanyarepartofthedifferentiatingquadrant.Thesearethe
thingsinwhichtheorganizationshouldbepreparedtoinvesttooffer
somethingthatisdistinctfromcompetitorofferings.Adifferentiating
activityisonethatmightbeusedtoadvertisethecompany,thatis
difficultforcompetitorstomatch,orotherwisehassignificant
strategicvalue,andauniqueapproachtotheseactivitiesislikelytobe
needed.
Parity Quadrant
Thingswhicharemissioncritical,butnotmarketdifferentiating,fall
intotheparityquadrant.Thatmeansthatitisusuallysufficienttobe
operatingonparwithotherfirmsinyourindustry.Manystandard
functions,suchasfinance,HR,payroll,andothersfallintothis
quadrantformostorganizations.Activitiesinthisquadrantare
importantbuttheywillnotprovideanadvantagetothefirmin
relationtocompetitorsandsoadoptionofbestpracticesisgenerally
sufficient.
Partner Quadrant
Activitiesthatmayhaveuniquevaluetocustomers,butwhicharenot
criticaltothefunctioningoftheorganization,fallintothepartner
quadrant.Eventhoughtheseactivitiesareimportanttocustomersor
otherstakeholders,theorganizationdoesntneedtoperformthemto
survive.Thatmeansthattheorganizationisunlikelytohavethe
resourcestoexcelattheseactivities(asmoremissioncritical
operationswilltakeprecedence),whileapartnermayperformthem
moreeffectively.
Who Cares? Quadrant
Finally,activitieswhichareneithermissioncriticalorhelpto
differentiatetheorganizationinthemarketplacefallintothewho
caresquadrant.Astheseactivitiesdonotaddcustomervalue,andthe
organizationcanfunctionwithoutperformingthem,theyareprime
candidatestobeeliminatedandtheresourcesreallocatedtosupport
moreusefulwork.
Techniques Get Real Using Examples
Thepurposealignmentmodelisdesignedforusebyforprofit
organizationsthatfacecompetitioninthemarketplace.Governmental
organizationsandnoprofitsmayfindthatmarketdifferentiationis
notasignificantdriverfortheirdecisions.Stakeholderormember
value,oralignmentwiththeorganizationalmissionmayserveasan
alternative.
Secondly,themodelprovidesguidanceonwhethersomethingshould
beanareaofstrategicconcernbutdoesnotprovideanyguidanceon
whatstrategiesordecisionsmightbethecorrectones.
Advantages
Oneofthekeyadvantagesofthismodelisitssimplicity.Itcan
betaughttobusinesssponsorsandusersinacoupleofminutes
sothattheycancriticallyassessanideathemselvesratherthan
thebusinessanalystdotheanalysisthatmaythenbe
challenged.
Themodeliseasytouseinafacilitatedcollaborative
environment.
Itcanbeappliedallthewayupanddowntheinvestment
decisionprocess.Fromstrategicinvestmentdowntoan
individualfeatureinasystem.
Itisfastandentirebacklogcanbeanalyzedinlessthananhour.
Disadvantages
Itassumespositiveintentinthebusinessstrategy.Itdoesnot
incorporatespoilerbehaviourbycorporations.
4.1 Get Real Using Examples
Inagilemethodologies,inordertoelicitandvalidateproductneeds
businessanalysispractitionersuserealcustomerexamplesto
communicatewiththeteam,includingthecustomer.Realexamples
servetobridgeunderstandingofthecustomer'sbusinessandhow
theyseetheproductservingafuturestateneed.Analysismodelscan
beconcurrentlydevelopedandelaboratedusingthesesameexamples.
Modelsmaybeusefulfortheteambutexamplesaremoreconcretefor
thecustomer.Thetechniquesareusediterativelybyalternating
betweenexamplesandanalysismodelstoexploremultiple
Get Real Using Examples Techniques
dimensions(forexample,userrole,useractions,data,businessrules)
ofaproductneed.Thisisacontinuouspracticethatbuildsashared
teamunderstandingofproductneedsusefulforbothplanningand
delivery.Thesetechniquesengagecustomersinrequirements
elicitation,analysis,andvalidation.
Examplesandmodelsshouldbeatalevelofgranularitythatis
appropriatefortheoutcomeyouseek.Whenplanningtheproduct,
modelsareusedtosetcontextandhelptheteamandcustomer
identifyscope.Thesemodelsaremoreabstractandprovideabroad
perspectiveoftheproblemdomain.Whendeliveringtheproduct,the
samemodelcanbeprogressivelyelaboratedandrelatedexamplesare
elicitedandspecifiedtolaunchintoadeeperdiscussionofthe
dimensions.Theexamplescanbeusedtoderiveacceptancecriteria,
helpthedeveloperdesignthesolution,andprovideafoundationfor
functionaltesting.
Behaviour Driven Development
4.1.1 Behaviour Driven Development
.1 Purpose
Anapproachthatenhancesthecommunicationbetweenbusiness
usersandthedevelopmentteam.
.2 Description
Traditionalbusinessanalysistechniquesofteninvolvecreating
analysismodels,forexampleusingUMLmodels.Inadditiontoanalysis
models,agiletechniquesfavourcommunicationusingexampleswhich
aremoreconcreteforthecustomer.Manypeopleareuncomfortable
withabstractionsandprefertoworkwithrealexamples.
Examplestendtobeadditiveandcanformaspecification.Theycanbe
usedduringagileplanninganddeliverywork.Asmodelschange,
examplescanberefinedbybuildingonpreviousexamples.Inagile,it
ishelpfultoiteratebetweenusingexamplesandanalysismodels
encouragingthemtofeedoffofeachother.Progressiveelaboration
leadstoricherexplorationofmultipledimensions(forexample,user
role,useractions,data,businessrules)relatedtotheexample.
Techniques Get Real Using Examples
Supplementingproductneeddiscussionswithexamplescreatesa
muchmorestablesetofrequirementsthanusingamodelalone.
Forexample,ratherthanacompanywhichsupportsmultiplebrands
fordifferentdemographicsegments,considerDisneyCorporation
whichhasDisneyfilmsforfamilyentertainment,Miramaxformore
adultaudiences,andMarvelforsuperheropictures.
Inaddition,examplesfeedsmoothlyintoabehaviour/testdriven
developmentapproach.
.3 Elements
Examples
Examplesmayalsobeknownasscenarios.Examplesshouldnotbe
artificialormadeup.Theyshouldbereallifebusinessscenarios
providedbythebusinessusers.Businessanalysisactivitieshelpto
facilitatethediscoveryoftheexamplesandensurethatthesetof
examplesiscomprehensive.Notallexamplesidentifiedwill
necessarilybewithinthescopeofadevelopmenteffort.
Behaviour Driven Development
Behaviourdrivendevelopmentprovidesasimplegrammarformat
thatallowsrealscenariostobefilledin.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
Understand What is Doable Techniques
Scenariosthatarewritteninabehaviourdrivendevelopmentformat
specifyingevents,conditions,andactionsareverifiable.Theycan
serveasacceptancecriteriaforstories[seeStoryElaborationon
page52]andserveastestsinsupportofAcceptanceTestDriven
Development(ATDD)thatdriveacommonunderstandingof
requirementsandfutureproductneeds.
Testing
Therearenowanumberofsoftwareproductsthatwilltakeexamples
inthisformatandallowthemtobeeasilyconvertedintoautomated
tests,thusenablingmoreagiledelivery.Withacomprehensivesetof
examplesthatcanbeexecutedasautomatedtests,businessanalysis
andtestingactivitiescanbemoretightlycoupled.
4.1 Understand What is Doable
Asanagileprojectteamplansfordelivery,itisimportanttothink
aboutwhatispragmaticanddoable.Theteammustbalancecapacity
anddemandwhentheyestimatetheworktobedonetodeliverthe
product.Agileprojectteamscontinuallyreviewmeasures,suchas
teamcapacity,priordeliverycyclecommitmentsandactuals,and
velocitytrendstoadjustcommitmentsonanongoingbasis.This
enablestheteamquestionwhatcanbedeliveredgiventheir
knowledgeoftheworksetandtosetappropriateexpectationsand
makebetterestimates.Understandingwhatisdoableoccurs
throughoutanyagiledeliverycycle,suchasreleaseplanning,work
aheadanalysis,orwheneverateamispullingnewbacklogitemsfor
considerationinaproductdeliverycycle.
Theentireteamusesthefollowingtechniquesasmethodstoidentify
andestimateunitsofworkthataredecomposedwithbusinessvaluein
mind.
Estimation
Planning Workshop
Real Options
Techniques Understand What is Doable
4.1.1 Estimation
.1 Purpose
Accurateestimationiscriticaltoanagileteamsproductivity,
reliability,andreputation.Bybeingabletodevelopaccurateestimates
ofcost,time,andeffort,theagiledevelopmentteamhastheabilityto
faithfullycommittoaprojectorworkeffort.
Estimationisateamactivity,andbusinessanalysismakesan
importantcontributionbyhelpingtheteamtobetterunderstandthe
components,characteristicsandcomplexityofthework.
Althoughestimatesarenotvisibleinthefinalproduct,theydoadd
significantvaluetoanagileproject.Providingcredibleestimates
allowstheprojectteamto:
determinecostandeffort,
establishtheprioritiesoftheproject,and
commitmenttoaschedule.
.2 Description
EstimationisdiscussedatlengthintheBABOK
Guide(9.10
Estimation).Here,webuildontheinformationintheBABOK
Guide
andsummarizetherelativeestimationtechniquesthatcanbeapplied
intheagiledevelopmentenvironment.
Uniquetotheagileenvironment,estimatingisprogressiveandoccurs
inalignmentwithiterations.Nooneexpectsearlyestimatestobeas
accurateaslatterestimates.Improvementoccursovertimeasthe
teamsbuildconfidenceintheircapacityandcapabilities.
Inadditiontothebasicapproachofestimatingbasedonhistorical
knowledge,agileestimatorsfrequentlyapplyarelativeestimating
modelinwhichteamsdevelopnarratives(stories)thatdefineuser
needsandbenefits.Thesestoriesareanalyzedbytheteamand
numericvaluesareappliedtoeachstory(storypoints).Storypoints
canbeabstractmeasurementsthatprovideanumericvaluetoastory,
orstorypointscanbedescribedasidealdeveloperdays(IDDs).
Astorypointisanumberassignedtoeachstorythatdefinesthe
estimatedeffortateamwillhavetoapplytothestory.Storypointsare
usuallybasedonwhattheteamknowsaboutthestoryinfourkey
areas:
Knowledge:Howmuchinformationdoestheteamhave?
Complexity:Howdifficultistheimplementationlikelytobe?
Volume:Howbigisthestory?Howlongwillittake?
Uncertainty:Whatvariablesandunknownfactorsmightimpact
thestory?
Thetotalnumberofstorypointswithinanygiveniterationis
consideredtobetheteamsvelocity,orhowmuchateamcan
accomplishwithintheiteration.Afterseveraliterationsteamswill
haveabetterunderstandingoftheiractualvelocity.Thiswillallow
themtomakebetterinformedestimatesandcommitmentsin
subsequentiterations.
Thereareseveralwaystogetstartedwithstorypointestimation.The
agileestimatorcanbeginwith
aWAG(wideangleguess),
agivensetofresourcesandafixediteration,or
anestimationofthetimerequiredforasinglestorypoint,and
thenextrapolatefromtheirtoestimatetheworkthatcanbe
doneinaniteration.
.3 Usage Consideration
Advantages
Relativeestimationisasimple,reliablemethodologythatfits
wellwithagilepractices.Itishighlyadaptiveandislikelyto
becomeincreasinglyaccuratethroughoutsuccessiveiterations.
Theplanningpokertechniqueisahighlycollaborativeprocess
thatisbasedonconsensusandwilllikelyhaveapositiveimpact
ondevelopmentteams.Itbuildsuponthewisecounseltoask
theteam.
Disadvantages
Relativeestimatesarebasedonhistoricaldataandaccuracyis
dependentuponthesimilarityofnewstoriestostories
previouslydelivered.Ifnewstoriesdifferradicallyfrom
previousstories,itispossiblethattheaccuracyoftheestimate
maydecrease.
Theaccuracyofvelocityisdependentontheknowledgeand
experienceofthedevelopmentteam.Anychangestoteam
compositionwillimpactvelocityandthereforeestimates.
4.1.2 Planning Workshop
.1 Purpose
Toenabletheteamtodeterminewhatworktoperformduringan
iterationortodeliveraminimummarketablefeature(MMF).
.2 Description
Aplanningworkshopisexecutedwhentheteamneedstoarriveata
commitmenttosomesetoffunctionalitythattheyfeelreasonably
confidenttheycancompleteinthenearfuture.Inmostagilemethods,
thisisperformedatthebeginningofeachiteration,butmayalsooccur
whenevertheteamisneartocompletingtheirbacklogofworkorthat
backlogneedstobeordered.InKanban,theamountofworkbeing
performedbytheteamislimitedbyrestrictingthenumberofwork
itemsthatcanbeinanyworkflowstate,notbasedoniterations.
Businessanalystscanprovidevaluetotheteambyhelpingto
understandandfocusontheiterationobjectives,thevalueassociated
withaparticularMMF,businessissues,storydecomposition,and
bringingtheteamtogethertodeliveranacceptableoutcome.Priorto
theworkshop,thereisusuallyapreplanningstagethatinvolves
analysistogetareasonablegaugeofthesize,scope,andcomplexityof
eachbacklogitemthatwillbebroughttotheiterationplanning
workshop.
Inagiledevelopment,planningworkshopsneedtobeperformedona
frequentandregularbasis,astheorderinwhichworkismeanttobe
performedisregularlyalteredandupdated.Thisallowstheteamand
customerstochangetheprioritiesofoutstandingworktoincorporate
feedbackorchangingbusinessneeds.
.3 Elements
Estimated and Ordered Product Backlog
Typicallybasedonuserstories,itisthemaininputfortheplanning
meeting.
Team Velocity
Priorvelocity(throughputcapacityofbacklogitems)iscriticalto
enablingtheteamtoschedulearealisticamountofwork.Whenusing
Kanban,workinprogress(WIP)limitswillbeusedtomanagethis
workloadinstead.
Iteration Goal or MMF Set
Manyteamssetanoverallgoalfortheiterationtohelpguidethe
selectionoffeatures.Thisisasubsetofthereleasegoal.Itisan
objectivethatwillbemetthroughtheimplementationoftheproduct
backlog.
Requirement Selection
Atthebeginningofthemeeting,basedonbusinessvalue,iteration
goal,andteamvelocity,thehighestpriorityfeaturesaretypically
selectedfromthereleaseplanbytheproductowner,product
champion,oracustomergivendecisionmakingauthority.
Non-Feature Selection
Thebacklogcanalsobecomposedbynonfeatureitems(elementsnot
relatedtoaproductincrement)identifiedasnecessarytoachievethe
iterationgoalordeliveranMMF.Forexample,therecanbebugstobe
fixed,systemorenvironmentsetup,researchinitiatives,management
workitems,oranyotheractivitythataddvaluetotheproject.
Task Planning
Theteamwillbreakthefeatureandnonfeatureitemsdownintotasks.
Taskstypicallyrangeinsizefrom4hoursto2days,withmosttasks
capableofbeingdeliveredwithinaday.Taskseffortcanbeestimated
inhoursforfurtherstatisticalcontrol.
Advantages
Customer,productowner,anddevelopmentteamcan
communicateandcollaboratefrequentlyaboutproductvision
andevolution.
Customerandproductownercanguidetheprojectnotjustat
thestartbutdaybyday.
Itseasiertounderstand,estimate,andplanthescopeofsmall
iterationsinsteadofthescopeofbigreleases.
Planscanbechangedinadvancebasedonfeedbackfrom
incrementaldeliveryofworkingsoftware.
Iterationplanningcanguaranteevisibilityofthewholeproject
andsynchronizationbetweenmultipleteams.
Disadvantages
Itisnecessarytogetallpeopletogetherinordertoavoid
interruptionsandrework,especiallywhenworkingwith
distributedorconcurrentteams.
Ifthewholeprojectisnotwellunderstoodduringtheiteration
planningworkshop,itspossibletoresultinasuboptimalplan.
Someapproachesconsideranalysis,design,andplanningsome
activitiestobeexecutediniterationplanningworkshops,which
canbeverytimeconsumingforlongiterations(3or4weeks),
generatingcomplaintsfromteammemberseveniftheeventis
productive.
4.1.3 Real Options
.1 Purpose
Anapproachtohelppeopleknowwhentomakedecisionsratherthan
how.Theapproachhelpsyouunderstandwhetheryouhavea
commitmentoranoption.
.2 Description
Thecoreconceptbehindrealoptionsisthatyoushoulddelaymakinga
decisionoracommitmentinaprojectuntilthelastresponsible
moment,whenthedecisionreallyneedstobemade.Therealoption
approachhasthreesimplerules:
optionshavevalue,
optionsexpire,and
nevercommitearlyunlessyouknowwhy.
Thefirstandthirdruletellyoutoavoidcommitmentsandkeepyour
optionsopen.Thesecondruletellsyoutounderstandwhenanoption
expiressothatyoucanactivelymanagewhetheryouchosethatoption
orletitlapse.Asthereisvalueinoptions,youshouldseektoextend
thematurityoftheoptions.
Realoptionsaddresspeople'saversiontouncertaintybyprovidingthe
conditionswhenacommitmentshouldbemade(theoptionexpiry)
ratherthansimplysuggestingthattheywait.
Themostcommonusageofrealoptionswithinagileprojectsisthe
wayinwhichbusinessinvestorschosewhichitemtoinvestinnext.
Traditionally,investorswouldprioritizetheirrequirementsforan
extendedperiodoftime.Withrealoptions,theywouldonlyprioritize
untilthenextinvestmentdecisionpoint.OnScrumprojectsthiswould
bethenextsprintplanningsession.InKanban,itwouldbethenext
timecapacitybecomesavailabletoworkonsomethingnew.
Realoptionssupportagilebusinessanalysisbyallowingustoreduce
thenumberofdecisionswehavetoconsideratanyonetime.
.3 Elements
Options and Commitments
Realoptionsforcesyoutoidentifywhetheryouhaveoptionsor
not,andalsoforcesyoutoidentifythecommitmentsyouare
making.
TherealoptionsmaterialtendstofocusonnonITproject
relatedexamples,tohelppeopleidentifytheminageneral
senseratherthanspecifyalistofcommonoptionswhichare
learnedbyrote.
Examplesofoptionsinclude:
Ahotelreservation.Anoptiontostayatthehotel.Theoption
normallyexpiresat6p.m.onthedayofthestayatwhichpoint
youarecommittedtopayingforthehotelroom.
Atickettoaconference,sportingevent,rockconcertortheatre.
Theoptiontoattendtheeventexpiresattheendoftheevent,or
sometimesearlier.
Atravelcard.Theoptiontotravelonpublictransport.The
optionexpiresinLondonataboutmidnight.
Abusinesscard.Theoptiontocontactthepersonwhogivesyou
thecard.Theoptionexpireswhenthepersonchangescontact
details.
Optionsarethingsyoucanchosetodoornotdo.Ifyouarecommitted
todoingsomethingandthereisonlyoneway,thenyoudonothave
options.
Someexamplesofcommitmentsinclude:
Oftenthereisapenaltyassociatedwithfailingtomeeta
commitment.
Payingyourtaxes.Failuretomeetthiscommitmentmayresult
infinesorworse.
Turninguptoworkontime.Failuretomeetthiscommitment
mayresultinterminationofyourcontractofemployment.
Deliveringitemsyouhavecommittedtodelivertootherpeople.
Failuretomeetthiscommitmentwillleadtoabadreputation
andmayleadtoalawsuit.
Examplesofthingsthatarenotoptions.
Thingsyoucannotdo.
Thingsyoucannotafford.
Thingsyoucannotdointime.
Thingsyoucannotbuyorsell.
Thingsyoudonothavethetoolsfor.
Options Expiry
Realoptionsforcesustounderstandwhenouroptionsexpireorwhen
wenolongerhaveachoice.Wehaveanoptionuptotheexpirydate
butnotafterit.Infinancialoptions,theexpirydateoftheoptionis
explicitlystatedasaseriesofdate/times.Inrealoptions,theexpiry
dateisconditional.
Determinationofwhenanoptionexpiresisthemostimportantaspect
ofrealoptions.Withoutthisknowledge,youareblindinyourdecision
process.Youeithermakedecisionstosoonortoolateandyoudonot
knowwhich.
Example
Youhavethechoicetoattendasportingeventat7p.m.
Theoptiontoattenddependsonwhereyouare.Imagineyou
areathomewhichis1houraway,thenyouroptiontoattend
expiresat6pm.Ifyouleaveafter6p.m.,youwillbelate.
Imagineyouareatworkwhichis2hoursaway,thenyour
optiontoattendexpiresat5p.m.Ifyouleaveafter5p.m.,you
willbelate.
Asoptionshavevalue,pushingtheexpirydatebackaddsvaluetoyour
projectandallowsyoumoreflexibility.
Right / Wrong / Uncertain
Arationaldecisionprocesswouldorderourpreferenceasbeingright,
thenuncertain,andfinallywrong.Observingpeople'sbehaviour
thoughtheirpreferenceisright,wrong,andthenuncertain.
Ifyouasksomeonetomakeadecisionlaterortonottomakethe
decisionnow,theyarefacedwithunboundeduncertaintyandasa
resulttheyarelikelytomakeadecisionbasedontheinformationthey
havenow.Thisemotionalcommitmentthenmakesithardertochange
thedecisionasfurtherinformationarrives.
Realoptionssuggestsusingboundeduncertainty.Makethedecision
when...Specifytheconditionswhenthedecisionshouldbemade.
Specifyingtheconditionswhenacommitmentshouldbemadeallows
thedecisionprocesstobemanaged.Aseniormanagercanasktheir
assistanttomonitortheconditionsonhisbehalf.
Anotherexampleofthisisthecheckoutatsupermarkets.Whendo
theyopenanothercheckout?At6p.m.?At7p.m.?Theyopena
checkoutwhenthreepeoplearewaitinginthequeue.Theythen
publishthefactsothattheircustomerscanmanagetheprocessfor
them.Theyreactwhencustomer'scomplainaboutthelengthofthe
queueandopenupanothertill.Whenqueuelevelsdrop,theyclose
tillsagainandredeploystafftoreplenishingtheshelves.
Feature Injection
Featureinjectionisacollectionoftraditionalbusinessanalysis
techniquesthathavebeencombinedtoallowabusinessanalystto
performanalysisinafastandeffectivemanner.Thisspeedthenallows
investmentcommitmentstobedeferredbecauseitreducethelength
oftimethatanalysistakes.
Thespeedoftheprocessisduetofollowingtherealoptionprocess.
Theanalysisstartswiththeoutputandthenworksbackthroughthe
Techniques Stimulate Collaboration & Continuous Improvement
processtotheinputs.Itthenconsidershowdifferentexamplesaffect
theprocess.
Thethreestepsoftheprocessare
1.Identifythebusinessvaluewhichspecifiestheoutputs/outcomes
requiredfromthesystem/process.
2.Injectthefeaturesthatworkoutwhichprocessesandinputsare
requiredtoproducetheoutputs/outcomes.
3.Breakthemodelwhichusemodelsidentifiesalltheexamplesthat
produceadifferentbehaviourinthesystem/process.
Advantages
Realoptionssimplifydecisionmakingbyprovidingasimpleset
ofprinciplestofollow.
Realoptionsmakedecisionmakingfastasyouonlyfocusonthe
immediatedecisionsanddeferprioritizationuntilalaterdate
whencomplexityisresolved.
Realoptionsdonottellyouhowtomakedecisions,justwhen
whichmakesthembroadlyapplicableasanapproach.
Realoptionshelpusoptimizeprocessbyforcingustoconsider
thedecisionpointsandtheinformationarrivalprocess(when
dataarrivesandwhetheritarrivesbeforethedecision).
Disadvantages
Realoptionscanbecounterintuitiveastheyrequireusto
analyzesystemsfromtheoutputstotheinputs.
Realoptionsarenotasimpleprocesstobefollowedbyrote.
Theyareathinkingtoolthatrequirespracticeandstudy.
4.1 Stimulate Collaboration & Continuous
Improvement
Agilepracticesemphasizetheimportantofcontinualcollaboration
betweenmembersoftheprojectcommunity.Weactivelycreatean
environmentwhereallprojectstakeholderscancontributetothe
overallprojectvalue,ideallyinfacetofacefacilitatedworkshops.The
Stimulate Collaboration & Continuous Improvement Techniques
realityformanyprojectsisthattheyaredistributedintermsofteam,
timeandgeography.Facilitationskills,inconjunctionwiththe
techniquesoutlinedinthissection,enablescollaborationforbothlocal
anddistributedteams.Thetechniquesinthissectionentailworking
togetheringroupstocreateasharedunderstanding.This
collaborativepointofviewpervadesanagileproject,andisnotlimited
toanyspecifictechnique.
Oneofthefundamentalprinciplesofallagilemethodsistheneedfor
continuousimprovement,notjustoftheproductunderdevelopment
butoftheprocessusedbytheteamtodelivertheproduct.Thisis
achievedthroughbothstructuredandunstructuredfeedbackona
continuousbasis.Forexample,theretrospectiveisanopportunityfor
theteamtoexaminetheirprocessesandproducttoidentify
opportunitiesforimprovement.Healthycollaborativeteamshavethe
trustandsafetynecessarytotransparentlyidentifyopportunitiesfor
improvement.
Collaborative Games
Retrospectives
4.1.1 Collaborative Games
.1 Purpose
Collaborativegamesarenotusedstrictlybyagileteams,althoughthey
areprevalentinagilepracticesbecausetheyemphasizetheconcepts
ofteamworkandcollaboration,whicharehighlyvaluedbyagile
practices.Collaborativegameshelpagroupofpeoplepromotea
commonunderstanding,gaininsightintoaproblem,orinspirenew
ideasaboutsolvingaproblem.
.2 Description
Collaborativegamesrefertomanydistinctstructuredtechniques,
whichincluderulestokeepparticipantsfocusedonaspecific
objective.Thegamesareusedtohelptheparticipantssharetheir
knowledgeandexperienceonagiventopic,identifyhidden
assumptions,andexplorethatknowledgeinwaysthatmaynotoccur
duringthecourseofnormalinteractions.Thesharedexperienceofthe
collaborativegameencouragespeoplewithdifferentperspectivesona
topictoworktogethertobetterunderstandanissueanddevelopa
sharedmodeloftheproblemorofpotentialsolutions.
Collaborativegamesoftenbenefitfromtheinvolvementofaneutral
facilitatorwhohelpstheparticipantsunderstandtherulesofthegame
andhelpstoenforcethem.Thefacilitator'sjobistokeepthegame
movingforwardandtohelpensurethatallparticipantsplayarole.
Collaborativegamesalsousuallyinvolveastrongvisualortactile
element.Activitieslikemovingstickynotes,scribblingonwhite
boards,assemblingthings,ordrawingpictureshelpovercome
inhibitions,fostercreativethinking,andthinklaterally.
.3 Elements
Purpose
Gamesalwayshavesomedefinedpurpose,typicallytodevelopa
betterunderstandingofaproblemortostimulatecreativesolutions.
Theparticipantsinthegameneedtounderstandthatpurpose,andthe
facilitatorwillhelpkeepthemmovingtowardit.
Process
Gamesalsohaveaprocessorrulesthattheyfollowtokeepthegame
movingtowarditsgoal.Often,eachstepinthegameistimelimited.
Gamestypicallyhaveatleastthreesteps:
1.anopeningstep,wheretheparticipantsgetinvolved,learntherules
ofthegame,andstartgeneratingideas,
2.theexplorationstep,whereparticipantsengagewithoneanother
andlookforconnectionsbetweentheirideas,testthoseideas,and
experimentwithnewones,and
3.aclosingstep,wheretheideasareassessedandparticipantswork
outwhichideasarelikelytobethemostusefulandproductive.
Outcome
Finally,attheendofacollaborativegame,thefacilitatorand
participantswillworkthroughtheresultsofthegameanddetermine
anydecisionsoractionsthatneedtobetakenasaresultofwhatthe
participantshavelearned.
Stimulate Collaboration & Continuous Improvement Techniques
Itisnotpracticaltoelaborateonthemanycollaborativegaming
techniquesandtheirusageconsiderationsinthisdocumentbutthe
followingexamplesmayprovideastartingpoint.
Thefollowingchartprovidessomeexamplesofcollaborativegames.
TABLE 4.6 ExamplesofCollaborativeGames
4.1.2 Retrospectives
.1 Purpose
Themostsingularobjectiveofaretrospectivemeetingisforateamto
cometogetherinordertoreflectonwhatithasdonewell,whatit
coulddobetter,andtoreachagreementonhowanyimprovements
willberealized.Uniquetotheagileenvironment,retrospectivesare
heldattheendofeachiterationsothatlearningscanbequickly
embeddedintheprocessesandpracticesgoingforwardforremainder
oftheproject.
.2 Description
Theretrospectiveprovidesanopportunityforallmembersoftheteam
toreflectonthemostrecentdeliveries.Theretrospectiveshould
includethewholeteamespeciallybusinessstakeholdersandusers.It
iscommonfortheretrospectivetobesplitintotwoparts.Thefirst
partinvolvingthewholeteamandthesecondparttodiscusstechnical
aspectsoftheprojectthatonlyaffectpartoftheteam.
Theretrospectiveshouldbefocusedonidentifyingissueswiththe
process.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.
inanysense.Akeyelementofaretrospectiveisthattheteamfeelsafe
todiscussanyissuethatconcernsthem.
Ideally,retrospectivesshouldbefacilitatedbyanneutralfacilitator
ratherthanbyamemberoftheteam.
.3 Elements
Preparation
Theteampreparesideasfromtherecentiterationthatmaybe
analyzedintheretrospective.
Safety Check
Theteammustagree,together,totrusteachotherandtobelievethat
everycommentorsuggestionisintendedforthesolepurposeof
improvingtheteam'sperformance.
Identify the Issues
Therearemanymechanismstoidentifyissuestodiscuss.Oneofthe
mostcommonisforallteammemberstowriteupthingsthatwent
well,thingstoimprove,andthingsofinterestonpostitnotes.Colour
codingthenotesandapplyingthemtoavisualtimelineassistin
addingunderstandingtotheemergingpicture.
Choosing Future Actions.
Oncealltheideashavebeendiscussedtothesatisfactionoftheteam,
thefacilitatoraskstheteamtodecidewhichsolutions/improvements
theywanttofocusonnext.Theteamthenidentifieswhich
improvementswillbeaddressedandassignsresponsibilitytoan
individualteammemberwhoensuresthesolution/improvementis
implemented.
Advantages
Anexcellentwayfortheteamtofindacollectivevoicearound
opportunitiesforteamimprovement.
Avoid Waste Techniques
Disadvantages
Teammembersmayfeelobligedtopretendthattheytrusteach
other,eventhoughtheydonot.
Retrospectivesareonlyofvalueiftheteamactsuponthe
learninginthesessiontoimprovetheprocess.
Mostideasraisedintheretrospectiveareknowtoatleastone
memberoftheteam.Amatureteamshouldbeaddressing
issuesastheyarriveratherthanbatchingthemuptobe
handledinaretrospective.
4.1 Avoid Waste
Agilemethodsemphasizethedeliveryofworkingsoftwaretothe
customer.Businessanalysisworkaddsvaluebyensuringthatthe
needsofthecustomerareunderstoodandthattheteamdeliverswhat
thecustomerreallyneeded.Anyactivitythatdoesnotcontribute
directlytothisgoal,orthatthecustomerwouldnotbewillingtopay
for,iswaste.
Wasteeliminationisanissuethathasbeentreatedwithgreat
emphasisbytheagilecommunity.ItisamindsetoriginatedfromLean
asthemosteffectivewaytoincreasetheprofitabilityofany
business.Leanthinkingconsidersavaluestreamhashavingtwo
components.Valueaddedactivitiesandmuda(theJapanesewordfor
waste).Theaimofleanthinkingistoremovethemuda,orwaste,from
thevaluestream.Wasteisfurthersubdividedintotwocomponents.
Thoseactivitiesthathavevaluebutdonotcontributetothefinal
productdirectlylikeanarchitectsplanandthoseactivitiesthatdonot
addvalueatall.Theaimistoremovecompletelythoseactivitiesthat
doaddvalueatall,andminimizethoseactivitiesthatdonotcontribute
tothefinalproductdirectly.Youcanstartavoidingwasteinbusiness
analysisbydevelopingandkeepingdocumentationlightweight.
Thefollowingprinciplesarehelpfulwhenworkingtoidentifywastein
anybusinessanalysisprocess:
Avoidproducingdocumentationbeforesomebodyelseneedsit.
Whenevervalueisnotbeingdeliveredtoyourcustomers,the
wasteofwaitingoccurs.Don'tletothersbewaitingforyourjob.
Transportinginformationbetweendifferentmediatypesisa
costincursionwhichaddsnovaluetotheproductdevelopment.
Techniques Avoid Waste
Trytoelicit,analyze,specify,andvalidaterequirementswith
thesamemodels.
Analysismodelsshouldbeassimpleaspossible.Donotinclude
informationthatisnotdirectlyusefultoastakeholder.
Workinprogress(WIP),orinventory,isadirectresultof
overproductionandwaiting.Theytendtohideproblemsonthe
process.Ifyouseeit,trytoletthemflowovertheprocessor
eliminateit.
Workclosetothecustomersanddevelopmentteambecause
unnecessarymotionorworkaroundstosubstitutefaceto
faceconversationsarealsowaste.
Keepcontinuousattentiontoyourtechnicalexcellence.Quality
defects(suchasunclearrequirements)resultinreworkandare
theworstwasteintheprocess.
Lightweight Documentation
4.1.1 Lightweight Documentation
.1 Purpose
Ensurethatalldocumentationproducedthroughbusinessanalysisis
intendedtofulfillanimmediateneed,hasclearvalueforstakeholders,
anddoesnotcreateunnecessaryoverhead.
.2 Description
Lightweightdocumentationisaprinciplethatgovernsall
documentationproducedinanagileproject.Thebusinessanalyst
shouldaimtoproduceaslittledocumentationaspossible,allofwhich
shouldbeofvalue.Intraditionaldevelopmentlifecycles,
documentationmaybeusedbydeveloperstocreatesoftwarealong
timeafteritsinitialcreation.Inagilemethodologies,thesoftwareis
constructedwithindaysoftheteamagreeingtodeliverasetof
requirements,andsodoesnotneedtoincludeinformationthatthe
teamcanrememberoragreetoduringtheconstructionprocess.
Traditionally,functionalspecificationsincludeallinformationthatthe
businessanalystknowsaboutthedomainproblem.Thespecification
maycontainextensivedescriptionofthecontextinwhichtheproject
takesplace,andmayattempttotrainthedeveloperinallaspectsofthe
domain.Thetransferofknowledgeistakenoutofthespecificationand
ismademoreeffectivethroughfacetofaceconversationsorother
communicationmethods.
Thecontextplaysanimportantfactorintheamountofdocumentation
required.Someprojectsaremandatedtoproducedocumentationby
externalentities(forexample,regulators).Documentationmayalsobe
neededtoprovidealongtermrecordofdecisionsreachedbytheteam
orfunctionsimplementedintheapplication.However,this
documentationcanbewrittenafterthesoftwareisdeveloped,which
ensuresthatitactuallymatcheswhattheteamdelivered.
Ageneralprinciplewithagileisthatifadocumentisvaluableenough
tobecreated,itisprobablyimportantenoughtobeautomatedsothat
itispartofthelivingcodebase.Thishasleadtotheriseofautomated
acceptancetestingandbehaviourdrivendevelopmentthatallows
businessanalyststoworkwithqualityassuranceprofessionalsto
createexecutablespecificationintheformofexamples.
ThisprinciplecomesdirectlyfromtheAgileManifestowhichsays
Workingsoftwareoverextensivedocumentation.Itisoften
misinterpretedasmeaningnodocumentation.Instead,documentation
shouldbebarelysufficienttomeettheneedsoftheteam.
Theagileprinciplehaselevatedthevalueofdocumentationthatis
producedbythebusinessanalyst.Thedocumentationproducedbythe
businessanalystshouldideallybeautomatedintheformofautomated
testsorexamples.
Advantages
Reduceamountoftimespentwritingdocumentation.
Reduceeffortspentreadingandreviewingdocumentation.
Reducenumberofdraftsofdocuments.
Allreviewerscanfocusonkeyissuesratherthanextraneous
details.
Training(knowledgetransfer)isdonetosuiteachperson
ratherthanusingthedocumentation.
Thedocumentationlivesintheformofautomatedexamples.
Techniques Avoid Waste
Disadvantages
Producinglightweightdocumentationmaycauseconflictwith
groupswhoenforcecorporateprocessstandards.
Somemaymisunderstandtheprincipleasmeaningno
documentation.
Someproducedocumentationthatisnotsufficientforan
externalentity.
appendix A Glossary
Acceptance Criteria
Requirementsthatmustbemetinorder
for a solution to be considered
acceptabletokeystakeholders.
Acceptance Test Driven Development
(ATDD)
ATDD is a TDD instance that involves
writingoneormoretests(orcustomer
tests) for a customercentric feature,
beforethesolutionhasbeendeveloped.
Acceptance Testing
SeeUserAcceptanceTest.
Agile
Agilereferstoagroupofprinciplesand
practices that promote a disciplined
project management process that
encourages frequent inspection and
adaptation,aleadershipphilosophythat
encouragesteamwork,selforganization
and accountability, a set of engineering
practices intended to allow for rapid
delivery of highquality software, and a
business approach that aligns
development with customer needs and
companygoals.
AlsoseeAgileManifesto,AgileSoftware
Development.
Agile Manifesto
TheAgileManifestoisastatementofthe
principles that underpin Agile Software
Development. It was drafted from
February11ththrough13th,2001.
Agile Retrospective
Retrospectivesareavariationofproject
retrospectives whereby the
retrospective workshop is conducted at
regular intervals throughout the
delivery process, such as after each
iterationand/orrelease.
Agile Software Development
Agile software development refers to a
group of software development
methodologies based on iterative and
incremental development, where
requirements and solutions evolve
through collaboration between self
organizingcrossfunctionalteams.
Anti-pattern
A commonly used, yet ineffective,
processorpractice.
Backlog
SeeProductBacklog.
Backlog Item
An element that belongs to a product
backlog. It can be a feature, a bug fix, a
document,oranyotherkindofartifact.
Behavior Driven Development (BDD)
An approach that enhances the
communication between business users
andthedevelopmentteambyusingreal
examples.
Glossary
Burndown Chart
Used to track the work remaining over
time. Work remaining is the Y axis and
time is the X axis. The work remaining
should jig up and down and eventually
trenddownward.
AlsoseeReleaseBurndownChart.
Business Value
In management, business value is an
informal term that includes all forms of
value that determine the health and
wellbeingofthefirminthelongrun.In
agile development, business value is
relatedtoalldeliverablesthatincrease/
protect revenue or reduce/avoid costs
inabusiness.
Ceremonies
Controlled processes and documents
that constitute events and outputs in
anygivenmethodology.Ahighdegreeof
ceremony frequently implies a high
degreeofcontrolandtraceability.Based
on the justintime and justenough
model, agile projects generally have a
lower degree of ceremony. Agile
ceremonies include iteration planning,
dailymeetings,andretrospectives.
Change Driven Methodology
A software development approach that
refers to a group of principles and
practices that promote a disciplined
project management process that
encourages frequent inspection and
adaptation,aleadershipphilosophythat
encouragesteamwork,selforganization
and accountability, a set of engineering
best practices intended to allow for
rapid delivery of highquality software,
and a business approach that aligns
development with customer needs and
companygoals.
Class-Responsibility-Collaboration (CRC)
Cards
A brainstorming tool used in the design
ofobjectorientedsoftware.
Daily Burndown
SeeBurndownChart.
Daily Meeting
On each day of a sprint, the team holds
daily meetings. Ideally they are held in
themorningastheyhelpsetthecontext
for the coming day's work. The daily
scrum is not used as a problemsolving
or issue resolution meeting. Issues that
are raised are taken offline and usually
dealt with by the relevant subgroup
immediatelyafterthedailyscrum.
Daily Scrum Meeting
SeeDailyMeeting.
Daily Standup
SeeDailyMeeting.
Elicitation
An activity within requirements
development that identifies sources for
requirements and then uses elicitation
techniques (for example, interviews,
prototypes, facilitated workshops,
documentation studies) to gather
requirements from those
sources.
Enterprise Analysis
Describes how business analysts
identifyabusinessneed,
refine and clarify the definition of that
need, and define a solution scope that
can feasibly be implemented by the
business.Thisknowledgeareadescribes
Glossary
problem definition and analysis,
business case development, feasibility
studies, and the definition of solution
scope.
Epic
A piece of functionality that enables a
user to achieve a clearly identified
businessobjective.OftenEpicsareatthe
levelofElementaryBusinessProcesses
a piece of work undertaken by one
person, at one time, in one place that
delivers on a specific operational
objective.
Feature Injection
An analysis technique based on real
options and Kolbs model of learning. It
can be used to efficiently identify the
business value, and then determine the
minimum set of features necessary to
deliverthatvalue.
Iteration Burndown
SeeProductBurndownChart.
Just-in-time Requirements
Requirements that define only what is
needed for the current iteration and
only to the level of detail required for
theteamtodelivertheitem.
Lean Development
Anagilemethodologythatisguidedby7
principles: eliminate waste, amplify
learning, decide as fast as possible,
empower the team, build integrity in,
andseethewhole.
Minimal Marketable Feature (MMF)
A chunk of functionality that delivers a
subset of the customers requirements,
andthatiscapableofreturningvalueto
the customer when released as an
independententity.
Minimal Viable Feature (MVF)
Commonlyusedwithnewproducts.
AlsoseeMinimalMarketableFeature.
On-site Customers
The term used for the individual
responsiblefortherelativeprioritiesfor
the solution requirements in the
ExtremeProgrammingmethodology.
Operations Reviews
A timebased process that is used to
evaluate milestones and ensure the
production environment is monitored
andmeasured.
Pair Programming
A development technique, frequently
used in Extreme Programming, where
two programmers work together one
computer, developing code. Generally
one programmer writes the code while
theotherreviewsthecode.
Persona
Fictional characters or archetypes that
exemplifythewaythattypicaluserswill
interactwithaproduct.
Plan-driven
follows an orderly series of sequential
stages. Requirements are agreed upon,
design is created and then the code is
developed,andtested.
Planning Game
The process used in Extreme
Programming to conduct release
planning and iteration planning. Both
types of planning is broken down into
threedistinctphases:explorationphase,
commitmentphase,andsteeringphase.
Glossary
Planning Poker
Attechniqueusedinrelativeestimation
that uses the entire team to contribute
totheestimatedworkeffort.Duringthis
group exercise, each member of the
team has a set of cards that have story
point values on them. The stories are
presented and then each team member
submits the card that has the value of
story points that they feel is how much
effort is required to deliver the story.
Theprocessisrepeateduntilconsensus
isreachedforeachstory.
Potentially Shippable Product Increment
Scrum requires that each sprint deliver
a potentially shippable product
increment. The increment must consist
of thoroughly tested code that has been
built into an executable, and the user
operation of the functionality is
documented either in Help files or user
documentation.
Product Backlog Item
In Scrum, a product backlog item (PBI,
backlog item, or item) is a unit of work
smallenoughtobecompletedbyateam
in one sprint. Backlog items are
decomposedintooneormoretasks.
Product Burndown Chart
InScrum,theproductburndownchartis
a "big picture" view of a project's
progress. It shows how much work was
lefttodoatthebeginningofeachsprint.
The scope of this chart spans releases;
however, a release burndown chart is
limitedtoasinglerelease.
Alsoseeburndownchart.
Product Champion
SeeProductOwner.
Product Owner
The product owner represents the
interests of allstakeholders,defines the
features of the product and prioritizes
theproductbacklog.
Product Roadmap
An initial high level project scope and
direction. It may include an initial
architecture.
Rapid Application Development (RAD)
A generic term referring to any number
of lighterweight approaches, using
fourthgeneration languages and
frameworks (such as web application
frameworks), which accelerate the
availabilityofworkingsoftware.
Rational Unified Process (RUP)
An iterative software development
process framework created by the
Rational Software Corporation, a
divisionofIBMsince2003.
Relative Estimation
A way of estimating work effort by
identifying features/requirements with
stories and then assigning story points
to each story. The cumulative story
points are the amount of effort to
estimate the amount of effort required
to deliver each story. The story points
are then calculated against the teams
velocity to create an estimate on how
much the team can deliver in a
particulariteration.
Glossary
Release
The transition of an increment of
potentially shippable product from the
development team into routine use by
customers. Releases typically happen
when one or more sprints has resulted
in the product having enough value to
outweighthecosttodeployit.
Release Burndown Chart
The release burndown chart is a "big
picture" view of a release's progress. It
showshowmuchworkwaslefttodoat
the beginningof each sprint comprising
a single release. The scope of this chart
is a single release; however, a product
burndownchartspansallreleases.
AlsoseeProductBurndownChart.
Release Planning
At the beginning of a project the team
willcreateahighlevelreleaseplan.The
team cannot possibly know everything
up front so a detailed plan is not
necessary. The release plan should
address:thenumberanddurationofthe
iterations, how many people or teams
shouldbeonthisproject,thenumberof
releases, the value delivered in each
release,theshipdateforthereleases.
Scrum Master
The Scrum Master is responsible for
making sure a Scrum team lives by the
values and practices of Scrum. The
Scrum Master protects the team by
making sure they do not overcommit
themselves to what they can achieve
duringasprint.
Scrum Team
TheScrumTeambuildstheproductthat
the customer is going to consume: the
software or website, for example. The
team in Scrum is "crossfunctional" it
includes all the expertise necessary to
deliver the potentially shippable
product each sprint and it is "self
organizing", with a very high degree of
autonomyandaccountability.
Shippable Product
A fully tested unit of code which meets
acceptance criteria, that is delivered at
theendofaniteration.
Service Level Agreements
Formalagreementsthatcontractlevelof
serviceandperformance.
Solution Assessment and Validation
The set of tasks that are performed in
order to ensure that solutions meet the
business need and to facilitate their
successful implementation. These
activities may be performed to assess
and validate business processes,
organizational structures, outsourcing
agreements, software applications, and
any other component of the
solution.
Spike
An experiment to explore potential
solutions or build a partial solution.
Spikesarecreatedtofigureoutanswers
totoughtechnicalordesignproblems.
Sprint
An iteration of work during which an
increment of product functionality is
implemented.
Sprint Backlog
Itemsselectedfromtheproductbacklog
tobedeliveredinthecurrentsprint,and
theirtasks.
Glossary
Sprint Goal
The Sprint Goal sprint goal is a short
description of what the sprint will
attempttoachieve.
Sprint Planning Meeting
TheSprintPlanningMeetingisattended
bytheproductowner,scrummaster,the
entire scrum team, and any interested
and appropriate management or
customer representatives. During the
sprint planning meeting the product
owner describes the highest priority
features to the team. The team asks
enoughquestionsduringthismeetingso
that they can go off after the meeting
and determine which tasks they will
move from the product backlog to the
sprintbacklog.
Sprint Retrospective
The Sprint Retrospective is the main
mechanism for taking the visibility that
Scrum provides into areas of potential
improvement,andturningitintoresults.
Sprint Review Meeting
Ameetingwherethescrumteamshows
what they accomplished during the
sprint.Typicallythistakestheformofa
demo of the new features. Participants
inthesprintreviewtypicallyincludethe
product owner, the scrum team, the
scrum master, management, customers,
and engineers from other projects.
During the sprint review the project is
assessed against the sprint goal
determined during the Sprint planning
meeting.Ideallytheteamhascompleted
each product backlog item brought into
the sprint, but it is more important that
they achieve the overall goal of the
sprint.
Standup Meeting
SeeDailyMeeting.
Story
SeeUserStory.
Story Mapping
AStoryMapisatooltoassistincreating
understanding of product functionality,
the flow of usage, and to assist with
prioritizing product delivery (such as
releaseplanning).
Task Board
The task board shows all the work the
team is doing during an iteration. It is
updated continuously throughout the
iteration if someone thinks of a new
tasktheywriteanewcardandputsiton
the board. Either during or before the
daily meeting, estimates are changed
(up or down) and cards are moved
aroundtheboard.
Team Velocity
The rate at which a team can
consistently deliver software features
per iteration. Typically, it can be
estimated by viewing previous sprints,
assuming the team composition. and
sprintdurationarekeptconstant.Itcan
alsobeestablishedonasprintbysprint
basis, using commitmentbased
planning.
Theory of Constraints
Developed by Dr. Eli Goldratt, the
Theory of Constraints (TOC) holds that
everysystemhasatleastoneconstraint
limiting it. TOCs goal is to increase
efficienciesbyidentifyingandmitigating
theseconstraints.
Glossary
UML
Unified Modeling Language (UML) is a
standardized language used to visually
articulate elements of a piece of
software.
User Acceptance Criteria
Test cases that users employ to judge
whether the delivered system is
acceptable. Each acceptance test
describes a set of system inputs and
expectedresults.
User Story
A highlevel, informal, short description
of a solution capability that provides
value to a stakeholder. A user story is
typically one or two sentences long and
provides the minimum information
necessary to allow a developer to
estimate the work required to
implementit.
User Story Mapping
A workflow of a business process that
breaksdowntasksforeachprocessand
representsthesetasksbasedonpriority.
Value driven development
A process used to prioritize
requirementsorbacklogitemsbasedon
businessvalue.
Velocity
SeeTeamVelocity.
Waterfall
follows an orderly series of sequential
stages. Requirements are agreed upon,
design is created and then the code is
developed,andtested.
Whole Team Testing
The concept embraced by may agile
methodologies where the entire project
team is responsible for quality
assuranceandtestingthecode.
Glossary
appendix B Bibliography
Thefollowingworkswerereferencedby
contributorstoTheAgileExtensionto
theBABOK
Guide.Incaseswhere
multipleeditionsofaworkwere
consulted,onlythemostrecentedition
islisted.
Inadditiontotheworkslistedhere,
manyothersourcesofinformationon
businessanalysiswereconsultedby
contributorsandreviewersor
otherwiseorinfluencedthe
developmentofTheAgileExtensionto
theBABOK
Guide,includingarticles,
whitepapers,websites,blogpostings,
onlineforums,seminars,workshops,
andconferences.
Withonlyaveryfewexceptions,the
ideasandconceptsfoundinTheAgile
ExtensiontotheBABOK
Guidewerenot
createdoriginallyforororiginaltoit.
Guideisasynthesisofyearsofresearch
intohowagiledevelopment
methodologiesareutilizedandmethods
thatcanbeusedtoidentifypotential
improvements.Theworkslistedbelow,
themselvesbuildonthethoughtsand
researchofmanyothers.
Adlin,TamaraandJohnPruitt.2010.The
EssentialPersonaLifecycle:YourGuideto
BuildingandUsingPersonas.Morgan
Kaufmann.
Adzic,Gojko.2009.Bridgingthe
CommunicationGap:Specificationby
ExampleandAgileAcceptanceTesting.
NeuriLimited.
Adzic,Gojko.2011.Specificationby
Example:HowSuccessfulTeamsDeliver
theRightSoftware.Manning
Publications.
Ambler,Scott.IntroductiontoUser
Stories.AgileModelling.http://
www.agilemodeling.com/artifacts/
userStory.htm.
Arthur,Jay.2006.LeanSixSigmaDe
mystified:ASelfTeachingGuide.McGraw
HillProfessional.
Berenbach,Brian,DanielJ.Paulish,
JuergenKazmeier,andArnoldRudorfer.
2009.Software&SystemsRequirements
Engineering:InPractice.McGrawHill
OsborneMedia.
Chelimsky,David,DaveAstels,Bryan
Helmkamp,andDanNorth.2010.The
RSpecBook:BehaviourDriven
DevelopmentwithRspec,Cucumber,and
Friends.PragmaticBookshelf.
Bibliography
Cohn,Mike.2004.UserStoriesApplied:
ForAgileSoftwareDevelopment.
AddisonWesleyProfessional.
Cohen,Mike.2006.AgileEstimatingand
Planning.PrenticeHall.
Cooper,Alan.2004.TheInmatesare
RunningtheAsylum.SamsPearson
Education.
Cottmeyer,MikeandV.LeeHenson.
2009.TheAgileBusinessAnalyst.
VersionOne,WhitePaper.http://
www.agiledad.com/Documents/
BAWhitepaperJune.pdf.
Courage,CatherineandKathyBaxter.
2005.UnderstandingYourUsers:A
PracticalGuidetoUserRequirements
Methods,Tools,andTechniques.Elsevier
ScienceandTechnologyBooks,Inc.
Derby,EstherandDianaLarsen.2006.
AgileRetrospectives:MakingGoodTeams
Great.PragmaticBookshelf.
DSDMConsortium.2003.DSDM:
BusinessFocusedDevelopment,Second
Edition.PearsonEducation.
Evers,Marc.September23,2009.
WorkingwithUserStoryMapping.
Dreamfeed:MarcsWeblog.http://
blog.piecemealgrowth.net/working
withuserstorymapping/.
ExtremeProgramming.September28,
2009.ExtremeProgramming:AGentle
Introduction.http://
www.extremeprogramming.org/
index.html.
Goldratt,Eliyahu.2004.TheGoal:A
ProcessofOngoingImprovement.North
RiverPress.
Gottesdiener,EllenandMaryGorman.
August2010.SlicingRequirementsfor
AgileSuccess.EbgConsulting.http://
ebgconsulting.com/Pubs/Articles/
SlicingRequirementsForAgileSuccess_G
ottesdienerGorman_August2010.pdf.
Gottesdiener,Ellen.February4,2009.
TheAgileBusinessAnalyst:Eyesfor
Waste.Modernanlyst.com.http://
www.modernanalyst.com/Resources/
Articles/tabid/115/articleType/
ArticleView/articleId/811/TheAgile
BusinessAnalystEyesforWaste.aspx.
Gottesdiener,Ellen.2005.Software
RequirementsMemoryJogger.GoalQPC
Inc.
Gray,Dave,SunniBrown,andJames
Macunafo.2010.Gamestorming:A
PlaybookforInnovators,Rulebreakers,
andChangemakers.O'ReillyMedia.
Highsmith,Jim.2009.AgileProject
Management:CreatingInnovative
Products(2ndEdition).AddisonWesley
Professional.
Hohmann,Luke.2006.Innovation
Games:CreatingBreakthroughProducts
ThroughCollaborativePlay.Addison
WesleyProfessional.
IIBA(2009).AGuidetotheBusiness
AnalysisBodyofKnowledge
(BABOK
Guide),Version2.InternationalInstitute
ofBusinessAnalysis.
Bibliography
Jonasson,Hans.2008.Determining
ProjectRequirements.CRCPress.
Karol,RobinandBeebeNelson.2007.
NewProductDevelopmentforDummies.
JohnWiley&Sons.
Kent,Stuart.June30,2004.
Storyboarding.MSDNBlogsStuartKents
Blog.http://blogs.msdn.com/b/
stuart_kent/archive/2004/06/30/
169599.aspx.
Kerth,Norman.2001.Project
Retrospectives:AHandbookforTeam
Reviews.DorsetHouse.
Kim,W.ChanandReneeMauborgne.
2005.BlueOceanStrategy.Harvard
BusinessPress.
King,James.December28,2010.
Estimationtoolkit:Someuseful
techniques.InfoQ.com.http://
www.infoq.com/articles/estimation
toolkit.
LeanEnterpriseInstitute.Principlesof
Lean.http://www.lean.org/whatslean/
principles.cfm.
Leffingwell,Dean.2011.AgileSoftware
Requirements:LeanRequirements
PracticesforTeams,Programs,andthe
Enterprise.AddisonWesley
Professional.
LencionimPatrick.2006.Silos,Politics
andTurfWars:ALeadershipFableAbout
DestroyingtheBarriersThatTurn
ColleaguesIntoCompetitors.JosseyBass.
Maassen,OlavandChrisMatts.June
2008.RealOptionsunderlieAgile
Practices.InfoQ.com.http://
www.infoq.com/articles/realoptions
enhanceagility.
Matts,Chris.October29,2003.Zero
Documentation.TheAgileBusiness
Coach.http://abc.truemesh.com/
archives/000103.html.
Matts,Chris.2009.RealOptionsatAgile
2009.R.O.S.E.Comics.http://
www.lulu.com/product/paperback/
realoptionsatagile2009/5949485.
ManifestoforAgileSoftware
Development.http://agilemanifesto.org.
Merrifield,Ric,JackCalhoun,Dennis
Stevens.2008.TheNextRevolutionin
Productivity.HarvardBusinessReview.
Middleton,PeterandJamesSutton.
2005.LeanSoftwareStrategies:Proven
TechniquesforManagersandDevelopers.
ProductivityPress.
North,Dan.March2006.Introducing
BDD.DanNorth.net.http://
dannorth.net/introducingbdd/.
Patton,Jeff.BuildingBetterProductsby
UsingUserStoryMapping.http://
www.slideshare.net/nashjain/user
storymapping.
Patton,Jeff.October8,2008.Thenew
userstorybacklogisamap.
AgileProductDesign.com.http://
agileproductdesign.com/blog/
the_new_backlog.html.
Patten,Jeff.February26,2010.User
CentredDesignandStoryMapping.
InfoQ.com.http://www.infoq.com/
interviews/pattonstorymap.
Bibliography
Pixton,Pollyanna,NielNickolaisen,
ToddLittle,andKentMcDonald.2009.
StandBackandDeliver:Accelerating
BusinessAgility.AddisonWesley
Professional.
Pols,AndyandChrisMatts.2004Five
BusinessValueCommandments.Agile
ProjectManagementAdvisoryService
ExecutiveUpdate.Vol.5,No.18.Cutter
Consortium.http://cdn.pols.co.uk/
papers/cutterbusinessvaluearticle.pdf.
Pyzdek,Thomas.2003.TheSixSigma
Handbook,RevisedandExpanded.
McGrawHill.
Rosenberg,DougandMattStephens.
2007.UseCaseDrivenObjectModeling
withUML:TheoryandPractice.Apress.
Rother,MikeandJohnShook.1999.
LearningtoSee:ValueStreamMapping
toCreateValueandEliminateMUDA.The
LeanEnterpriseInstitute,Inc.
Sayer,NatalieJ.andBruceWilliams.
2007.LeanForDummies.JohnWiley&
Sons.
Schwaber,Ken.2007.AgileProject
ManagementwithScrum.Microsoft
Press.
Schwaber,Ken;Sutherland,Jeff.2010.
ScrumGuide.Scrum.org.http://
www.scrum.org/storage/scrumguides/
Scrum%20Guide.pdf.
Shore,James.2007.TheArtofAgile
Development.O'ReillyMedia.
Sims,Chris.March23,2009.Story
MappingGivesContexttoUserStories.
InfoQ.com.http://www.infoq.com/
news/2009/03/storymap.
Womack,andJamesP.,andDanielT.
Jones.2003.LeanThinking:Banish
WasteandCreateWealthinYour
Corporation,RevisedandUpdate.Free
Press.
Wells,Don.2009.IterationPlanning.
XPProgramming.com.http://
www.extremeprogramming.org/rules/
iterationplanning.html.
Wynne,Matt,andAslakHellesy.2011.
TheCucumberBook:BehaviourDriven
DevelopmentforTestersandDevelopers.
ThePragmaticBookshelf.
appendix C Contributors
IIBA
andTheAgileAlliance
wouldliketothankthefollowingcontributorstoThe
AgileExtensiontotheBABOK
Guide.WithouttheireffortsandcommitmentThe
AgileExtensiontotheBABOK
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
Contributors
www.iiba.org
IIBA International Institute of
Business Analysis
About International Institute of Business
Analysis (IIBA)
International Institute of Business Analysis (IIBA) is an
independent nonprofit professional association serving
the growing field of Business Analysis. For individuals
working in a broad range of roles business analysis,
systemsanalysis,requirementsanalysisormanagement,
project management, consulting, process improvement
and more IIBA can help you do your job better and
enhanceyourprofessionallife.
IIBA has created the Business Analysis Body of
Knowledge (BABOK) Guide, the collection of
knowledge within the BA profession, reflecting the
current generally accepted practices. We help business
analystsdeveloptheirskillsandfurthertheircareersby
providing access to unique and relevant content.
Membershipbenefitsincludeaccesstothefollowing:
CopyofthelatestBABOKGuide
Online library with access to hundreds of BA
relatedbooks
Webinars on a range of professional
developmenttopics
BA Competency Model and BA SelfAssessment
Tool
JobsearchcapabilitiesusingtheCareerCenter
Discounted fees to apply for, recertify and sit
exams for professional accreditation Certified
Business Analysis Professional
TM
(CBAP)
designation and Certification of Competency in
BusinessAnalysis
TM
(CCBA
TM
)designation.
Monthly"BAConnection"newsletter
Chapters
IIBAisdedicatedtothedevelopmentandmaintenanceof
standardsforthepracticeofbusinessanalysis,andforthe
certificationandrecognitionofpractitioners.
Certified Business Analysis Professional
TM

(CBAP)
TheCertifiedBusinessAnalysisProfessional
TM
(CBAP)
designation is a professional certification for individuals
withextensivebusinessanalysisexperience.Withatleast
7500hoursofhandsonBAexperience,CBAPrecipients
aretheelite,seniormembersoftheBAcommunity.
Certification of Competency in Business
Analysis
TM
(CCBA
TM
)
The Certification of Competency in Business Analysis
TM
(CCBA
TM
) designation is a professional certification for
business analysis practitioners who want to be
recognized for their expertise and skills by earning
formalrecognition.Withatleast3750hoursofhandson
BAexperience,theyhavedevelopedessentialBAskills.
MoreinformationregardingCertificationscanbefoundat
www.iiba.org/certification.
IIBA Chapters
IIBAChaptersadvancethemissionandobjectivesofthe
organization by promoting professional standards and
practices at the local level. Ongoing professional
developmentisakeybenefitofyourIIBAmembership
and is supported at the chapter level through activities,
meetings, and educational programs. A list of IIBA
Chapters and more information regarding them can be
foundatwww.iiba.org/chapters.
Membership in IIBA
When you join IIBA, you become a member of an
international association dedicated to developing and
promoting the Business Analysis profession. More
information regarding IIBA can be found at
www.iiba.org.
www.iiba.org
The Agile Alliance
The Agile Alliance is a nonprofit organization with global membership, committed to advancing Agile development
principlesandpractices.AgileAlliancesupportsthosewhoexploreandapplyAgileprinciplesandpracticesinorderto
makethesoftwareindustrymoreproductive,humaneandsustainable.Weshareourpassiontodeliversoftwarebetter
everyday.
Agile methods have proven their effectiveness and are transforming the software industry. As agile methods evolve
and extend, Agile Alliance fosters a community where organizations and individuals find ways to transition to and
advanceAgilepractices,regardlessofmethodology.
The Agile Alliance website offers an information hub where members can access a wide variety of resources an
articlelibrary,videos,presentations,localusergrouplistingsandlinkstoadditionalagileresources.
Agile Alliance organizes the largest, most diverse and comprehensive agile conferences each year. Conference
participants learn from hundreds of sessions spanning the entire agile organization and lifecycle, make business
connections,andconversewithagilethoughtleaders,practitioners,andauthors.
Inadditiontothesemajorconferences,AgileAllianceprovidesfinancialandorganizationalsupporttoscoresoflocal,
regionalandspecialinterestconferencesandusergroupsworldwide.
TheAgileAllianceoperatesontheprinciplesoftheAgileManifesto.http://www.agilemanifesto.org
TheAgileAlliancewebsiteis:www.agilealliance.org.
Changing the Way Organizations Change
Business analysis is the set of tasks and techniques used to work as a liaison among
stakeholders in oder to understand the structure, policies, and operations of an
organization, and to recommend solutions that enable the organization to achieve its
goals.
Business analysis involves understanding how organizations function to accomplish
their purposes and defining the capabilities an organization requires to provide
products and services to external stakeholders. It includes the definition of
organizational goals, understanding how those goals connect to specific objectives,
determiningthecoursesofactionthatanorganizationhastoundertaketoachievethose
goalsandobjectives,anddefininghowthevariousorganizationalunitsandstakeholders
withinandoutsidethatorganizationinteract.
The Agile Extension to the BABOK
Guide contains descriptions of generally accepted

practices and techniques used by those to practice business analysis within an agile
development framework. The content has been verified through reviews by
practitioners,consultationwithrecognizedexpertsinthefield,andclosecollaboration
betweenIIBA
andtheAgileAlliance.
The BABOK
Guide is recognized around the world as a key tool for the practice of
business analysis and has become a widelyaccepted standard for the profession, with
over 200,000 copies downloaded from the IIBA
website. The Agile Extension to the

BABOK
Guide builds on the practices found in the BABOK
Guide, and describes

businessanalysisareasofknowledge,theirassociatedactivitiesandtasks,andtheskills
necessary to be effective in their execution within the framework of agile software
development.

The Agile Extension

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

The Agile Extension

Caricato da

Copyright:

Formati disponibili

International Institute

Guide contains descriptions of generally accepted

website. The Agile Extension to the

Guide builds on the practices found in the BABOK

Guide, and describes

Potrebbero piacerti anche