A Lean and Scalable Requirements Information Model for ... · PDF fileLean and Scalable...
Transcript of A Lean and Scalable Requirements Information Model for ... · PDF fileLean and Scalable...
1 ALeanandScalableRequirementsInformationModelfortheAgileEnterpriseCopyright2009,Leffingwell,LLC.
Leffingwell,LLC.
Whitepaper
ALeanandScalableRequirementsInformation
ModelfortheAgileEnterprise
By Dean Leffingwell with Juha‐Markus Aalto
Abstract:Inthiswhitepaper,wedescribeaLeanandScalableRequirementsInformationModelthatextendsthebasicteam‐basedagilerequirementspracticestotheneedsofthelargest,lean‐thinkingsoftwareenterprise.Whilefullyscalabletoalllevelsoftheproject,programandportfoliolevels,thefoundationofthemodelisaquintessentiallyleanandagilesubsetinsupportoftheagileprojectteamsthatwriteandtestallthecode.
2 ALeanandScalableRequirementsInformationModelfortheAgileEnterpriseCopyright2009,Leffingwell,LLC.
Contents
Introduction .......................................................................................................................................... 3
TheBigPictureofEnterpriseAgility ...................................................................................................... 3
TheRequirementsModelforAgileTeams ........................................................................................ 4
StoriesandtheIterationBacklog ...................................................................................................... 5
UserStories.......................................................................................................................................... 5
StoriesareImplementedviaTasks ...................................................................................................... 6
AcceptanceTests:AllCodeisTestedCode.......................................................................................... 7
SummaryoftheModelforAgileTeams............................................................................................ 7
WhytheTeamModelisLeanandScalable ....................................................................................... 8
TheModelforAgilePrograms............................................................................................................... 8
Feature .............................................................................................................................................. 9
TheFeature(Release)Backlog ........................................................................................................ 10
ExpressingFeaturesinStoryCanonicalForm .................................................................................... 10
TestingFeatures .............................................................................................................................. 10
OnSystemQualitiesandNon‐functionalRequirements................................................................. 11
TestingNon‐FunctionalRequirements............................................................................................ 12
WhytheProgramModelisLeanandScalable ................................................................................ 12
TheModelfortheAgilePortfolio:StrategicProductThemesandEpics ............................................ 13
StrategicProductThemes ............................................................................................................... 13
WhyInvestmentMixRatherthanBacklogPriority? ....................................................................... 14
Epics ................................................................................................................................................ 15
DiscriminatingEpics,FeaturesandStories...................................................................................... 16
OK,it’sEvenBiggerNow,IsitStillLeanandScalable? ................................................................... 17
Summary–TheFullLeanandScalableRequirementsModel............................................................. 18
AbouttheAuthors............................................................................................................................... 18
3 ALeanandScalableRequirementsInformationModelfortheAgileEnterpriseCopyright2009,Leffingwell,LLC.
Introduction
Agiledevelopmentpracticesintroduced,adoptedandextendedtheXP‐originated“UserStory”astheprimarycurrencyforexpressingapplicationrequirementswithintheagileenterprise.Thejust‐in‐timeapplicationoftheuserstorysimplifiedsoftwaredevelopmentandeliminatedthepriorwaterfalllikepracticesofoverlyburdensomeandoverlyconstrainingrequirementsspecificationsforagileteams.
However,aspowerfulasthisinnovativeconceptis,theuserstorybyitselfdoesnotprovideanadequate,norsufficientlylean,constructforreasoningaboutinvestment,system‐levelrequirementsandacceptancetestingacrossthelargersoftwareenterprisesprojectteam,programandportfolioorganizationallevels.Inthiswhitepaper,wedescribeaLeanandScalableAgileEnterpriseRequirementsInformationModelthatscalestothefullneedsofthelargestsoftwareenterprise,whilestillprovidingaquintessentiallyleanandagilesubsetfortheagileprojectteamsthatdomostofthework.
The Big Picture of Enterprise Agility InmyBigPictureblogseries1,I’veattemptedtocapturetheessenceofenterpriseagilityinasinglegraphic,soastobettercommunicatethegestaltof“whatthiswillalllooklike”afteranagile
implementation.Asthisservesasthelargerorganizational,processandrequirementsartifactcontext
1http://scalingsoftwareagility.wordpress.com/category/the‐big‐picture/
4 ALeanandScalableRequirementsInformationModelfortheAgileEnterpriseCopyright2009,Leffingwell,LLC.
fortherequirementsinformationmodel,Figure1belowisanillustrationoftheBigPicture.
Figure 1 ‐ The Big Picture of Enterprise Agility
Whilethedetailsofthispictureareoutsidethescopeofthiswhitepaper,relevanthighlightsinclude:
• Developmentoflargescalesystemsisaccomplishedviamultipleteamsinasynchronized"Agile
ReleaseTrain"‒astandardcadenceoftime‐boxediterationsandreleases.
• Releasesarefrequent,typicallyat60‐120daymaximumboundaries.• Thereisaseparationofproductdefinitionresponsibilitiesattheproject,programandportfolio
levels.• Differentrequirementsartifacts‐Stories,Features,andEpics‐areusedtodescribethesystem
atthesedifferentlevels.
The Requirements Model for Agile Teams Ofcourse,sincetheAgileTeamsdevelopandtestallthecode,theyplaythemostcriticalrolewithinthe
agileenterprise.IntheBigPicture,theyaredepictedatthe“projectlevel”asindicatedbelow.
5 ALeanandScalableRequirementsInformationModelfortheAgileEnterpriseCopyright2009,Leffingwell,LLC.
Figure 2 ‐ The Agile Team in the Enterprise
Stories and the Iteration Backlog Sincetheefficiencyoftheseteamsisparamount,weneedtoassuretheyapplythesimplestandleanest
possiblerequirementsmodel.Inagile,thattypicallytakestheformofthesimplestory,eachofwhichiscontainedinaprioritizedbacklog,asfigure3illustrates.
Figure 3 ‐ A Story is a kind of backlog item
First,wenotethatStoryisa“kindof”BacklogItem.(Aswewillsee,thisalsoimpliesthatthereareother
kindsofbacklogitemsaswell.)IntheBigPicture,wedescribedthisparticularbacklogastheIteration(Story)Backlogascanbeseenbelow.
Figure 4‐Stories and the Iteration Backlog
Theteam’sIteration(Story)Backlogconsistsofalltheworkitemstheteamhasidentified.Intherequirementmodel,wecalltheseworkitemsStoriesbecausethat’swhatmostagileteamscallthem.
(Strictlyspeaking,“workitems”isprobablyabetterterm,butwearen’ttryingtofightagilegravitywiththismeta‐model!)Soa Story is a work item contained in the team’s iteration backlog.
User Stories
6 ALeanandScalableRequirementsInformationModelfortheAgileEnterpriseCopyright2009,Leffingwell,LLC.
Whilethatdefinitionissimple,itbeliestheunderlyingstrengthofagileinthatitistheUser Storythatdeliversthevaluetotheuserintheagilemodel.Indeed,theuserstoryisinseparablefromagile’sgoalof
insane focus on value delivery,anditisthereplacementforwhathasbeentraditionallyexpressedassoftware requirements. OriginallydevelopedwithintheconstructsofExtremeProgramming,UserStoriesarenowendemictoagiledevelopmentingeneralandaretaughtinScrumaswellasXP.
AUser Storyisa brief statement of intent which describes something the system needs to do for the
user.Ascommonlytaught,theuserstoryoftentakesacanonical(standard)formof:
As a <role> I can <activity> so that <business value>
LOTShavebeenwrittenonapplyingUserStoriesinagiledevelopmentsothereisnoneedtoelaboratefurtherhere.However,inthemodelsofar,theUserStoryisnotexplicitlycalledout,butratheris
impliedbytheStoryclass.TomaketheUserStoryexplicit,weneedtoextendthesimplemodelalittleasseenbelow:
Figure 5‐Stories can be user stories or other work items
Withthissmalladdition,wenowseethatthebacklogiscomposedofUserStoriesandOtherWork
Items,whichincludethingslikerefactors,defects,support,research spikesandinfrastructure development.
Stories are Implemented via Tasks
While,onthesurface,agiledevelopmentmayappeartobelessdisciplinedthantraditionaliterativeorwaterfalldevelopment,inreality,nothingcouldbefurtherfromthetruth.Agileisthemostdisciplinedsoftwaredevelopmentmodelinusetoday.Partofthatdisciplineisassuringthatstoriescanbe
developed,testedanddeliveredtothebaselineinthecourseofshortiteration.Assuringthatrequiresdailyandintensecooperationfromteammates.Therefore,eachteammemberestimatestheTasksthatarenecessarytoachieveastory.SinceTasksareexplicitinagile,theymustbeexplicitinourmodelas
well:
Figure 6‐Stories are implemented via tasks
Asimpliedbythe1‐to‐many(1..*)relationshipexpressedinthemodel,thereisoftenmorethanonetasknecessarytodeliverevenasmallstory.
7 ALeanandScalableRequirementsInformationModelfortheAgileEnterpriseCopyright2009,Leffingwell,LLC.
Acceptance Tests: All Code is Tested Code
RonJeffries,oneofthecreatorsofXP,usedtheneatalliteration,Card,ConversationandConfirmationtodescribethethreeelementsofaUserStory.
• Cardrepresentsthe2‐3sentencesusedtodescribetheintentofthestory.
• Conversation representsfleshingoutthedetailsoftheintentofthecardinaconversationwiththecustomerorproductowner.
• Confirmation representsthe Acceptancetestswhichwillconfirmthestoryhasbeen
implementedcorrectly.
WiththissimplealliterationandXPszealousnessfor“allcodeistestedcode”wehaveanobjectlessoninhowqualityisachievedduring,ratherthanafter,actualcodedevelopment.Inourmodel,however,wetreattheAcceptanceTestanartifactdistinctfromthe(User)Storyitself,andassociateeachstory
withoneormoreacceptancetestsasindicatedbelow:
Figure 7‐ A story is not done until it passes an acceptance test
Insodoing,themodelisexplicitonitsinsistenceontherelationshipbetweentheStoryandAcceptanceTest,therebyassuringquality.Thisisseeninthe1tomany(1..)relationship(i.e.everystoryhasoneormoreAcceptanceTests)andinthefactthataStorycannotbeconsideredcomplete(done when passes)
untilithaspassedtheAcceptanceTest(s).
Summary of the Model for Agile Teams Perhapsthisdidn’tseemlikeanoverlycomplexdiscussion,andformostagileteams,thesefewunarguably‐agileartifacttypesareallthatisneededforalightweightagileprocess.Andyet,theapparentsimplicitydisguisesasomewhatmorecomplexbackground,asthesummarymodelshows:
8 ALeanandScalableRequirementsInformationModelfortheAgileEnterpriseCopyright2009,Leffingwell,LLC.
Figure 8‐The full model for agile teams
Why the Team Model is Lean and Scalable Relativetothe“advertisingclaims”ofourleanandscalablemodel,it’sworthnotingwhythemodelis
leanandscalable:
It is Lean It is Scalable Simplestpossibleagileartifacttypes NolimittothenumberofteamsJust‐in‐timestorydevelopmenteliminatesrequirementsspecificationandinventory
Nolimittothenumberofstories
Allcodeistestedcode–nountestedcodeinventoryeither
Ifallcodeistestedcode,thesystemwillhaveinherentqualitytoo
Simplebacklogconstructfacilitatesapull/kanbansystem
Separationofbacklogssimplifiesadministrationandtooling
The Model for Agile Programs Forsmallersoftwareprojectsandsmallnumbersofteams,thismodelisfullyadequatetosupportqualitydevelopmentinanagilemanner.Indeed,themodelandartifactssofararesosimpleandcommonlyusedthatonewouldnotconsiderittobea“requirementsmodel”atall.
However,atenterprisescale,thingsaremorecomplexandthissimplisticmodeldoesnotscalewelltotheenterprisechallenge.Thereasonisfairlysimple,asniftyasthestoryconstructis,itistoofinegrainedaconstructfortheenterprisetoreasonwithwhencommunicatingvision,planningorassessing
status.Oneproblemisinthemath.Let’sassume:
• Amodestsizedenterprise(orsystemorapplicationwithinalargerenterprise)thatrequiressay,200practitioners,or25teamstodeliveraproducttothemarket.
• Theenterprisedeliverssoftwaretothemarketevery90daysinfive,twoweekiterations(plus
onehardeningiteration).• Eachteamaverages15storiesperiteration• Numberofstoriesthatmustbeelaboratedanddeliveredtoachievethereleaseobjective=
25*5*15=1,875!
Howisanenterprisesupposedtoreasonaboutsuchaprocess?
1. Whatisthisnewproductgoingtoactuallydoforourusers?2. Ifweknowwehave900storiescomplete,wemaybeabout50%done,butwhatdoweactually
haveworking?Howwouldwedescribe900workingthings?
3. Howwillwegoaboutplanningareleasethancontains1,875things?
AsecondproblemisinthelanguageoftheUserStory.EvenifIknow100thingsthat“as a <role> I can <activity> so that <business value>”,cando,whatFeaturesdoesthesystemoffertoitsuserand
whatbenefitsdoesitprovide?
Soformanyenterprises,thesimplerteammodeldoesnotscaletotheprogramlevelsetofchallenges,andanewmodelmustbeapplied:
9 ALeanandScalableRequirementsInformationModelfortheAgileEnterpriseCopyright2009,Leffingwell,LLC.
Figure 9‐The model for agile programs
Inthismodel,thelevelofabstractionofdefiningsystembehavioriselevatedtothesystem/featurelevel,andthelevelofplanningandmanagementiselevatedtotherelease.
Feature ByusingthewordFeatureforthishigherlevelabstraction,wehavethesecurityofreturningtoamore
traditionaldescriptionofsystembehavior,asFeatureisatraditionalartifactthathasbeenwelldescribedinanumberofsoftwarerequirementstexts2.Generally,Featuresareservices provided by the system that fulfill a user need. Theyliveatalevelabovesoftwarerequirementsandbridgethegapfrom
theproblem domain(understandinguserneeds)tothesolution domain(specificrequirementsintendedtoaddresstheuserneeds)asthegraphicfromthattextbelowshows:
Figure 10‐Traditional "requirements pyramid"
Wealsopositedinthattextthata system of arbitrary complexity can be described with a list of 25‐50 such features.Thatsimpleruleofthumballowedustokeepourhighleveldescriptionsexactlythat,highlevel,andsimplifiedourattemptstodescribecomplexsystemsinashorterform.
Ofcourse,insodoingwedidn’tinventeithertheword“Feature”ortheusageoftheword.Rather,we
simplyfellbackonindustrystandardnormstodescribeproductsintermsof,forexample,a Features and Benefits Matrix aswasoftenusedbyproductmarketingtodescribethecapabilitiesandbenefitsprovidedbyanewsystem.Moreover,byapplyingthisfamiliarconstructinagile,wealsobridgethe
languagegapfromtheagile project team/product ownertothesystem/program/product managerlevelandgivethosewhooperateoutsideouragileteamsatraditionallabel(Feature)tousetodotheirtraditionalwork(i.e.describethethingthey’dlikeustobuild).
2ManagingSoftwareRequirements:AUseCaseApproach.LeffingwellandWidrig.AddisonWesley,2003.
10 ALeanandScalableRequirementsInformationModelfortheAgileEnterpriseCopyright2009,Leffingwell,LLC.
Also,theabilitytodescribe a system in terms of its proposed featuresandtheability to organize agile teams around the features givesusastraightforwardmethodtoapproachbuildinglarge‐scalesystems
inanagilemanner.
The Feature (Release) Backlog Returningtothemodel,wemodelFeaturesasreleaselevelBacklogItems:
Figure 11‐Features are another kind of backlog item
Atreleaseplanningtime,FeaturesaredecomposedintoStories,whichistheteam’simplementationcurrency.Planned FeaturesarestoredinaBacklog,inthiscasetheFeature(Release)Backlog.
Inbacklogform,Featuresaretypicallyexpressedinbulletform,oratmost,inasentenceortwo.For
example,youmightdescribeafewfeaturesofGoogleMailsomethinglike:
• Provide“Stars”forspecialconversationsormessages,asavisualreminderthatyouneedtofollow‐uponamessageorconversationlater.
• Introduce“Labels”asa“folder‐like”conversation‐organizingmetaphor.
Expressing Features in Story Canonical Form
Asagilists,however,wearealsocomfortablewiththesuggested,canonicalStoryformdescribedearlier:as a <role> I can <activity> so that <business value>. ApplyingthisformtotheFeatureconstructcanhelpfocustheFeaturewriteronabetterunderstandingoftheuserroleandneed.Forexample:
As a modestly skilled user, I can assign more than one label to a conversation so that I can find or see a conversation from multiple perspectives
Clearlythereareadvantagestothisapproach.However,thereisalsothepotentialconfusionfromthe
factthatFeaturesthenlookexactlylikeStoriesbutaresimplywrittenatahigherlevelofabstraction.Butofcourse,that’swhattheyreallyare!
Testing Features Intheteammodel,wealsointroducedtheagilemantraall code is tested code andattachedanAcceptanceTesttoeachStorytoenforcethatdiscipline.AttheProgramlevel,thequestionarisesasto
whetherornotFeaturesalsodeserve(orrequire)AcceptanceTests.Theansweris,mosttypically,yes.WhileStoryleveltestingshouldassurethatthemethodsandclassesarereliable(unittesting)andthe
11 ALeanandScalableRequirementsInformationModelfortheAgileEnterpriseCopyright2009,Leffingwell,LLC.
Storiessuitstheirintendedpurpose(functionaltesting),thefactisthataFeaturemayspanmultipleprojectteamsandmany,many(hundreds)ofStories.
Whileperhapsideally,eachprojectteamwouldhavetheabilitytotestallFeaturesatthesystemlevel,
thefactisthatthatisoftennotpractical(orperhapsevendesirable‐afterall,intheabsenceof100%automation,howmanyteamswouldwewanttocontinuouslytestthesamefeature!).Also,manyindividualprojectteamsmaynothavethelocalresources(testbed,hardwareconfigurationitems,other
applications)necessarytotestafullsystem.Inaddition,therearealsoamyriadofsystem‐level“whatif”considerations(thinkalternateuse‐casescenarios)thatmustbetestedtoassuretheoverallsystemreliability;manyofthesecanonlybetestedatthefullsystemlevel.
Forthisreason,Featurestypicallyalsorequireoneormorefunctionalacceptanceteststoassurethat
theFeaturemeetstheuser’sneeds.ToreflecttheadditionofAcceptanceTeststoFeatures,itisnecessarytoupdatetheinformationmodelwithanassociationfromFeaturetoAcceptanceTestasthegraphicbelowshows.
Figure 12‐Features have acceptance tests too
Inthismanner,weillustratethateveryFeaturerequires oneormoreAcceptanceTests,andaFeaturealsocannotbeconsidereddoneuntilitpassesitstest.
On System Qualities and Nonfunctional Requirements Fromarequirementsperspective,theUserStoryformandFeatureexpressionsareusedtodescribethe
functionalrequirementsofthesystem;thosesystembehaviorswherebysomecombinationofinputsproducesameaningfuloutput(result)fortheuser.
Withallduerespecttothatniftyagileinvention,however,littlehasbeendescribedinagileastohowtohandletheNon‐functional Requirements (NFRs)forthesystem.Traditionally,thesewereoften
describedasthe“ilities”–quality,reliability,scalability,etc.–andservedtoremindusthattheseareimportantandcriticalelementsofsystembehavior.Forifasystemisn’treliable(crashes)ormarketable(failuretomeetsomeimposedregulatorystandard)orscalable(doesn’tsupportthenumberofusers
required)then,agileornot,wewillfailjustasbadlyasifweforgotsomecriticalfunctionalrequirement.
Inoneperspective,alloftheseitemscanbeconsideredtobeconstraintsonnewdevelopment,inthateacheliminatessomedegreeofdesignfreedomonthepartofthosebuildingthesystem.Forexample:
12 ALeanandScalableRequirementsInformationModelfortheAgileEnterpriseCopyright2009,Leffingwell,LLC.
“everyproductinthesuitehastobeinternationalized(constraint),butonlytheOrderEntrymodulemustbelocalizedtoKorean(Feature)forthisrelease.”
Sointheinformationmodel,wehavemodeledthemassuch:
Figure 13‐Backlog items are constrained by Nonfunctional Requirements
Weseethata)some Backlog ItemsmaybeconstrainedbyzeroormoreNonfunctional Requirements
(0…*)andb)Nonfunctional Requirementsapplytozeroormorebacklogitems(0..*).
Testing NonFunctional Requirements WhenwelookatthelonglistoflistofpotentialBacklogConstraints–(SCRUPLED:Security,Copyright,Reliability,Usability,Performance,Localization,EssentialstandardsandDesignConstraints)‐the
questionnaturallyarisesastowhethertheseconstraintsaretestable.Theanswerismostlyyes, asmostoftheseconstraintsmustbeobjectivelytestedtoassuresystemquality,asillustratedbelow:
Figure 14‐A system is compliant when it passes System Validation Tests
RatherthancallingthesetestsAcceptanceTestsandfurtheroverloadingthatterm,we’vecalledthem
SystemValidationTests.ThisisintendedtobetterdescribehowthissetoftestshelpassurethatthesystemisvalidatedtobeincompliancewithitsNonfunctionalRequirements.Themultiplicity(1..*and0..*)furtherindicatesthatnoteveryNFRhasavalidationtest.Howevermostdo(..*)andeverysystem
validationtestshouldbeassociatedwithsomeNFR(1..*),otherwisetherewouldbenowaytotellwhetheritpasses!
Why the Program Model is Lean and Scalable Ofcourse,aswescaleourmodeluptotheprogramlevel,wemustconstantlycheckthatwearestilldrivinglean,agileandscalablebehavior.Butindeedweare:
It is Still Lean It is Quite Scalable Teamsapplyonlytheprojectlevelstoryabstractions
Featuresareimplementedbystories,andcanbetracedwithtooling
Featuresprovideahigherlevelabstractionforprogrammanagement
Higherabstractionsimplifiesreasoningandassessmentforlargeprograms
13 ALeanandScalableRequirementsInformationModelfortheAgileEnterpriseCopyright2009,Leffingwell,LLC.
Just‐in‐timefeatureelaborationeliminatestooearlyrequirementspecificationinventory
OneFeaturebacklogcandriveStoriesformanyteams
Featurebacklogconstructfacilitatessystem levelpull/kanbansystem
Separationofbacklogssimplifiesadministrationandtooling
The Model for the Agile Portfolio: Strategic Product Themes and Epics Formanysoftwareenterprises,includingthoseofmodestscopeofafewhundredpractitioners,theProjectModel(primarilyStories,Tasks,andAcceptanceTests)plustheProgramModel,(addingFeaturesandNon‐Functionalrequirements)isallthatisneeded.Inthesecases,driving the releases with a
Feature‐based visionanddriving iterations with stories that are created by the teams,isasscalableasisrequired.
However,thereisanotherclassofenterprises—enterprisesemployingmanyhundredstothousandsofpractitioners—whereinthegovernanceandmanagementmodelfornewsoftwareassetdevelopment
needsadditionalartifacts,andstillhigherlevelsofabstraction.IntheBigPicture,thisisillustratedasthePortfolio levelasindicatedbelow:
Figure 15‐Portfolio level of the Big Picture
Thislevelintroducestwonew,additionalartifacttypesEpicsandStrategic Product Themes.
Strategic Product Themes Strategic Product Themes(alsocalled“InvestmentThemes”or“Themes”forshort)representthesetofinitiativeswhichdrivetheenterprisesinvestmentinsystems,productsandapplications.Thesetof
Themesforanenterprise,orbusinessunitwithinanenterprise,establishestherelativeinvestmentobjectivesfortheentityasthepiechartbelowillustrates:
14 ALeanandScalableRequirementsInformationModelfortheAgileEnterpriseCopyright2009,Leffingwell,LLC.
Figure 16‐Strategic Product Themes portfolio mix
TheseThemesdrivetheVisionforallproductteamsandnewEpicsarederivedfromthisdecision.The
derivationofthesedecisionsistheresponsibilityofthosewhohavefiduciaryresponsibilitiestotheirstakeholders.Inmostlargerenterprises,thishappensatthebusinessunitlevelbasedonannualortwiceannualbudgetingprocess.
Withinthebusinessunit,thedecisionsarebasedonsomecombinationof:
1. Investmentinexistingproductofferings–enhancements,supportandmaintenance2. Investmentinnewproductsandservices‐productsthatwillenhancerevenueand/orgain
newmarketshareinthecurrentorneartermbudgetperiod3. Investmentinfutures‐productandserviceofferingsthatrequireinvestmenttoday,butwill
notcontributetorevenueuntiloutlyingyears.
TheresultofthedecisionprocessisasetofThemes‐key product value propositions that provide
marketplace differentiation and competitive advantage.ThemeshaveamuchlongerlifespanthanEpics,andasetofThemesmaybelargelyunchangedforupayearormore.
Why Investment Mix Rather than Backlog Priority? AsopposedtoEpics,FeaturesandStories,InvestmentThemesarenotcontainedorrepresentedinaBacklog(theyarenot“akindofBacklogItem”)asthemodelshows.
Figure 17‐Portoflio Model adds Epics and Strategic Product Theme
15 ALeanandScalableRequirementsInformationModelfortheAgileEnterpriseCopyright2009,Leffingwell,LLC.
BacklogItemsaredesignedtobeaddressedinpriorityorder.StrategicProductThemesaredesignedtobeaddressedon“apercentageoftimetobemadeavailablebasis.”Forexample,thelowestpriority
Storyonaniterationbacklogmaynotbeaddressedatallinthecourseofaniterationandyettheiterationcouldwellbeasuccess(meetitsstatedobjectivesandbeacceptedbytheproductowner).However,ifthelowestpriority(smallestinvestmentmix)StrategicProductThemeisnotaddressedover
time,theenterprisemayultimatelyfailinitsmissionasitisnotmakingitsactualinvestmentsbasedonthelongertermprioritiesithasdecided.
StrategicProductThemesalsodonotsharecertainotherBacklogItembehaviors.Forexample,ascriticalastheyare,theyarenotgenerallytestable,astheirinstantiationoccursfirstthroughEpicsand
thenfinally,viaactualimplementationinFeaturesandStories,whichhavethespecificitynecessarytobetestable.
Epics Epic,then,representthehighestlevelexpressionofacustomerneedasthishierarchicalgraphicshows.
Figure 18‐Epics are the highest level requirements artifact
DerivedfromtheportfolioofStrategicProductThemes,Epicsaredevelopmentinitiativesthatare
intendedtodeliverthevalueofthethemeandareidentified,prioritized,estimatedandmaintainedintheEpicBacklog.Priortoreleaseplanning,EpicsaredecomposedintospecificFeatures,whichinturn,driveReleasePlanning3intheBigPicture.
3http://scalingsoftwareagility.wordpress.com/category/release‐planning/
16 ALeanandScalableRequirementsInformationModelfortheAgileEnterpriseCopyright2009,Leffingwell,LLC.
Figure 19‐Release Planning in the Big Picture
Epicsmaybeexpressedinbulletform,asasentenceortwo,invideo,prototype,orindeedinanyform
ofexpressionsuitabletoexpresstheintentoftheproductinitiative.WithEpics,clearly,theobjectiveisVision,notspecificity.Inotherwords,theEpicneedonlybedescribedindetailsufficienttoinitiate a further discussionaboutwhattypesofFeaturesanEpicimplies.
Discriminating Epics, Features and Stories It’sapparentbynowthatEpics,FeaturesandStoriesareallformsofexpressinguserneedandimplied
benefit,butatdifferentlevelsofabstraction.Whilethereisnorigorouswaytodeterminewhethera“thingyouknowyouwanttodo”isanEpic,FeatureorStory,thefollowingtableofdiscriminatorsshouldhelp:
Type of
InformationDescription Responsibility
Time frame &
SizingExpression format Testable
Strategic
Product Theme
BIG,hairy,
audacious,gamechanging,
initiatives.Differentiating,
andprovidingcompetitive
advantage.
Portfolio
fiduciaries
Spanstrategic
planninghorizon,12‐18+months.
Notsized,controlledby
percentageinvestment
Any:text,prototype,PPT,
video,conversationNo
Epic
Bold,Impactful,marketable
differentiators
Programandproduct
management,businessowners
6‐12months.Sized.
Mostany,includingprototype,mockup,
declarativeformoruserstorycanonicalform
No
17 ALeanandScalableRequirementsInformationModelfortheAgileEnterpriseCopyright2009,Leffingwell,LLC.
Feature
Short,descriptive,valuedeliveryand
benefitorientedstatement.
Customerandmarketing
understandable.
ProductManagerand
ProductOwner.
Fitsinaninternalrelease,divideinto
incrementalsub‐featuresas
necessary.Sizedinpoints.
Declarativeformoruserstorycanonicalform.
Maybeelaboratedwithsystemusecases.
Yes
Story
Smallatomic.Fit
forteamanddetaileduser
understanding
ProductOwner
andTeam.
Fitsinasingle
iteration.Sizedinstory
points.
Userstorycanonicalform Yes
Table 1‐Discriminating Themes, Epics, Feature and Stories
OK, the Model is Even Bigger Now, Is it Still Lean and Scalable? Weadmitthatthemodelappearstogrowincomplexityasitscalestotheneedsofthefullenterprise.However,wepositthatthisisaneffectofthecomplexityofthechallengethattheenterprisefaces,
ratherthanthemodelitself,andfailuretoaddressthiscomplexitywithprimaryartifactscreatesanevenmorecomplexmodelandlessleanapproach.(Imaginereasoningabout5,000flatrequirements,or20,000stories!).Soyes,itisstilllean,anditisstillscalable.
18 ALeanandScalableRequirementsInformationModelfortheAgileEnterpriseCopyright2009,Leffingwell,LLC.
It is Still Lean It is Scalable Portfolioplannersneedonlytwo,light‐weight,highlevelabstractions.
Portfoliofocusonbusinesscaseandinvestmentmix,ratherthansystemrequirements
Thereareonlyafewinvestmentthemesatanyonetime
Lighterweight,higherlevelartifactssimplifiesreasoningaboutlargenumbersofprograms
Therearejustafewepicsofinterestinplayatthevariousprogramreleaseboundaries
Epic‐to‐featurehierarchyassuresinvestmentfollowsstrategicobjectivesacrossthefullenterprise
Summary – The Full Lean and Scalable Requirements Model Insummary,thefullleanandscalablerequirementsmodelfortheagileenterpriseappearsbelow.
Figure 20‐Full enterprise requirements model
Whilethismodelmayappeartobemorecomplexthatmostagilistshavetypicallyappliedtodate,itscalesdirectlytotheneedsofthefullenterprisewithoutburdeningtheagileteamsoradding
unnecessaryadministrativeorgovernanceoverhead.Inthismanner,theenterprisecanextendthebenefitsofagility—fromtheproject—tothesystem—totheportfoliolevel,andtherebyachievethefullproductivityandqualitybenefitsavailabletotheincreasinglyagileenterprise.
AbouttheAuthors Dean Leffingwellisanentrepreneur,executive,consultantandtechnicalauthorwhoprovidesproduct
strategyandenterprise‐scaleagilitycoachingtolargesoftwareenterprises.Mr.LeffingwellhasservedaschiefmethodologisttoRallySoftwareandformerlyservedasVicePresidentofRationalSoftware,nowIBM’sRationalDivision,wherehewasresponsiblefortheRUP.HislatestbookisScaling Software
19 ALeanandScalableRequirementsInformationModelfortheAgileEnterpriseCopyright2009,Leffingwell,LLC.
Agility: Best Practices for Large EnterprisesandheistheleadauthorofthetextManaging Software Requirements: First and Second Editions,bothfromAddison‐Wesley.Hecanbereachedthroughhisblog
athttp://www.scalingsoftwareagility.wordpress.com.
Juha‐Markus AaltoisDirector,OperationalDevelopmentoftheS60SWunitofNokiaDeviceswherehehasbeenleadingagileadoption.Mr.AaltohasworkedforNokiafortwentyyearsinvariousdevelopment,qualityandleadershippositionsrelatedtolargescalesoftwaredevelopment.Heisoneof
theauthorsofthebookTried & True Object Development – Industry‐proven Approaches with UML,CambridgeUniversityPress/SIGSBooks,1999.