38 www.agilerecord.com

Adult children. Jumbo shrimp. Seriously funny. I’m sure yourecognize these expressions as oxymorons—self-contradictoryphrases,oftenwithanironicmeaning.

Shouldweadd“Agilerequirements” to the list?DoesAgilede-velopmentfit inwith traditional requirementspractices?And ifso,how?

Once More into the BreachTraditionally,definingrequirementsinvolvescarefulanalysisanddocumentationandcheckingandrecheckingforunderstanding.It’sadisciplinedapproachbackedbydocumentation,includingmodelsandspecifications.Formanyorganizations,thismeansweeksormonthsofanalysis,minimalcross-teamcollaboration,andreamsofdocumentation.

In contrast, Agile practices—Lean (http://www.leanprimer.com/downloads/lean_primer.pdf),Scrum(http://www.scrumalliance.org/), XP (http://www.extremeprogramming.org/), FDD (http://www.featuredrivendevelopment.com/), Crystal (http://www.am-azon.com/exec/obidos/ASIN/0201699478),andsoon—involveunderstandingsmallslicesofrequirementsanddevelopingthemwithaneyetowardusingtestsastruth.Youconfirmcustomers’needsbyshowingthemdeliveredsnippetsofsoftware.

However, Agile projects still produce requirements and docu-mentation,andtheyinvolveplentyofanalysis.OnthebestAgileprojects, requirements practices combine discipline, rigor, andanalysis with speed, adaptation, and collaboration. Becausesoftwaredevelopmentisaknotty“wickedproblem”withevolvingrequirements,usingiterativeandAgilepracticesisnotonlycom-monsensebutalsoeconomicallydesirable.

Indeed,AgilerequirementsdriveidentifyinganddeliveringvalueduringAgileplanning,development,anddelivery.

PlanningAgileteamsbaseproductrequirementsontheirbusinessvalue—forexample,boostingrevenue,cuttingcosts,improvingservices,complyingwithregulatoryconstraints,andmeetingmarketgoals.Ifyou’reagile,itmeansthatyoufocusonvalueandjettisonany-thingintheproductorprocessthat’snotvaluable.

Planning covers not only the “now-view” (the current iteration)butalsothe“pre-view”(therelease)andthe“big-view”(thevi-sionandproductroadmap),withcloseattentiontononfunctional(http://www.agile2010.org/express.html#5210)aswellasfunc-tionalrequirements.Theproductroadmapiscrucialforkeepingyoureyesontheprize,especiallyinlarge,complexproducts.Youdon’thavetoknoweachspecificroute,buttheoverallwaymustbeclear.It’sdrivenbytheproductvisionandmarkedbyindustryevents,dates,orkeyfeaturesthatmustbeachievedalongtheroute.

Customers (or “product owners,” in Scrum terminology) driveAgileplanning,constantlyreprioritizingrequirementsandevalu-ating risks anddependencies.Close customer collaboration isessential.OneoftheoriginalAgilemethods,DSDM(http://www.dsdm.org/),hascustomerinvolvementasthefirstprinciple.

Your Agile backlog, or catalog, of product needs changes con-stantly—wheneveryoudoplanning(e.g.,forareleaseoriteration)

© iStockphoto.com

/graphicphoto

Agile Requirements: Not an Oxymoronby Ellen Gottesdiener

39www.agilerecord.com

or,ifyou’reusingakanban/flowmodel,everytimeyou’rereadytopullinanotherrequirement.Plansarebasedondecidingwhattobuild,andwhen.

AnAgiledeliveryteamworksahead,preparingrequirementsfordevelopmentandtesting.Thispreparationisvitaltodeliverthevalueassoonaspossible,withsmoothflowandnothrashingorinterruptionsindeliveryandtesting.

DevelopingAnAgileteam’sworkisbasedonbuildingconcise,fine-grainedrequirements (typically captured as user stories). Developersneedsmall,tamped-downrequirementstoworkfrom.Smallre-quirementsthathaveclearconditionsofsatisfaction(doneness)minimizerisk.

Theteammayalsosketchorganicdatamodels,statediagrams,and interface mockups. These are like micro-specifications:“ready” requirements forpulling intodelivery.The teamknowsenoughtoestimate,develop,test,anddemonstratetherequire-ments.

Donenessisakeyaspectofrequirements.Iwroteabout“done”requirementsinmyfirstbook(2002,http://www.ebgconsulting.com/Pubs/reqtcoll.php): theteamandcustomerneedtoknowwhen they understand the requirements enough to build andtest.ThisconceptisusedofteninAgiledevelopmentandrefersnotonlytorequirementsbutalsotothebuild,test,andreleaseprocess.

DeliveringRequirementsarebuiltandreleasedbasedontheteam’sclearunderstandingofrequirementsdependencies,whichalsodrivearchitecturetrade-offdecisions.Requirementsaredependentoneachotherwheneachrelieson(andthusconstrains)theother.

SmartAgileteamsanalyzedevelopmentanddeliverydependen-cies(http://www.agile2010.org/express.html#5364)tooptimizevalue.Traditionalrequirementsmodelsareusefulfordependen-cyanalysisandtosupplementAgile’s lightweightrequirements(suchasuserstories).

It’s All Good“Agilerequirements”isn’tanoxymoron,althoughitmaybeabitofaparadox—inthesamewaythattheconciseenablesthecom-plex,thesmallgivesrisetothelarge,incompletenessfacilitatesthefinish,andyoumustslowdown tospeedup. Indeed,Agilerequirements are central to Agile planning, development, anddelivery.

Ellen GottesdienerEBG Consulting, Inc. Princi-pal Consultant and Found-er Ellen Gottesdiener helps business and technical teams collaborate to de-fine and deliver products customers value and need. Ellen is an internationally recognized facilitator, trai-ner, speaker, and expert

on requirements development and management, Agile business analysis, product chartering and roadmap-ping, retrospectives, and collaborative workshops. Author of two acclaimed books Requirements by Col-laboration and The Software Requirements Memory Jogger, Ellen works with global clients and speaks at in-dustry conferences. She is co-authoring a book on agile practices for discovering and exploring product needs. View her articles, tweets, blog, and free eNewsletter on EBG’s web site.

> About the author