A Lean and Scalable Requirements Information Model for Agile

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.


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


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/


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.


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


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.


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:


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:


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.


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


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:


“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


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:


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


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/


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


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.


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


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.

Documents

A Lean and Scalable Requirements Information Model for Agile