Agile requirements through user stories and scenarios · Agile requirements through user stories...

23
TDT 4242 Inah Omoronyia Agile requirements through user stories and scenarios TDT 4242 Institutt for datateknikk og informasjonsvitenskap

Transcript of Agile requirements through user stories and scenarios · Agile requirements through user stories...

TDT 4242

Inah Omoronyia

Agile requirements through user stories and scenarios

TDT 4242

Institutt for datateknikk og informasjonsvitenskap

TDT 4242

Agenda •  Key principles of agile requirements

•  User stories

•  INVEST

•  Prioritizing stories

•  User story mapping

•  Challenges

•  Conclusion

KeyPrinciplesforAgileRequirements

•  Ac#veuserinvolvementisimpera#ve

•  Agileteamsmustbeempoweredtomakedecisions•  Requirementsemergeandevolveasso9wareisdeveloped

•  Agilerequirementsare‘barelysufficient’•  Requirementsaredevelopedinsmall,bite‐sizedpieces

•  Enough’senough–applythe80/20rule•  Coopera#on,collabora#onandcommunica#on

betweenallteammembersisessen#al

RequirementsareaCommunica8onProblem

•  Wri;enrequirements–  canbewellthoughtthrough,reviewedandedited–  provideapermanentrecord–  aremoreeasilysharedwithgroupsofpeople–  #meconsumingtoproduce–  maybelessrelevantorsupersededover#me–  canbeeasilymisinterpreted

•  Verbalrequirements–  instantaneousfeedbackandclarifica#on–  informa#on‐packedexchange–  easiertoclarifyandgaincommonunderstanding–  moreeasilyadaptedtoanynewinforma#onknownatthe#me–  cansparkideasaboutproblemsandopportuni#es

User Stories

seek to combine the strengths of written and verbal communication,

where possible supported by a picture. *Kent Beck coined the term user stories in Extreme

Programming Explained 1st Edition, 1999

WhatisaUserStory?•  Aconcise,wriMendescrip#onofapieceof

func#onalitythatwillbevaluabletoauser(orowner)oftheso9ware.

•  Storiesare:– User’sneeds– Productdescrip#on– Planningitem– Tokenforaconversa#on– Mechanismfordeferringconversa#on

UserStoryCardshave3parts

1.  Card‐AwriMendescrip#onoftheuserstoryforplanningpurposesandasareminder

2.  Conversa8on‐Asec#onforcapturingfurtherinforma#onabouttheuserstoryanddetailsofanyconversa#ons

3.  Confirma8on‐Asec#ontoconveywhattestswillbecarriedouttoconfirmtheuserstoryiscompleteandworkingasexpected

UserStoryDescrip8on

‐  Asa[userrole]Iwantto[goal]soIcan[reason]

-  As a [type of user] I want to [perform some task] so that I can [reach some goal]

Forexample:•  AsaregistereduserIwanttologin

soIcanaccesssubscriber‐onlycontent

UserStoryDescrip8on

•  Who(userrole)

•  What(goal)

•  Why(reason)–  givesclarityastowhyafeatureisuseful–  caninfluencehowafeatureshouldfunc#on

–  cangiveyouideasforotherusefulfeaturesthatsupporttheuser'sgoals

UserStoryDescrip8onSteps:

•  Startwitha#tle.

•  Addaconcisedescrip#ono9enusingthisusefultemplates.

•  Addotherrelevantnotes,specifica#ons,orsketches

•  Beforebuildingso9warewriteacceptancecriteria(howdoweknowwhenwe’redone?)

UserStoryExample:FrontofCard

UserStoryExample:BackofCard

HowdetailedshouldaUserStorybe?

Detailedenoughfortheteamtostartworkfrom,andfurtherdetailstobeestablishedandclarified

atthe#meofdevelopment.

INVESTinGoodUserStories

•  Independent–UserStoriesshouldbeasindependentaspossible.

•  Nego#able–UserStoriesarenotacontract.Theyarenotdetailedspecifica#ons.Theyareremindersoffeaturesfortheteamtodiscussandcollaboratetoclarifythedetailsnearthe#meofdevelopment.

•  Valuable–UserStoriesshouldbevaluabletotheuser(orowner)ofthesolu#on.TheyshouldbewriMeninuserlanguage.Theyshouldbefeatures,nottasks.

•  Es#matable–UserStoriesneedtobepossibletoes#mate.Theyneedtoprovideenoughinforma#ontoes#mate,withoutbeingtoodetailed.

•  Small–UserStoriesshouldbesmall.Nottoosmall.Butnottoobig.

•  Testable–UserStoriesneedtobewordedinawaythatistestable,i.e.nottoosubjec#veandtoprovidecleardetailsofhowtheUserStorywillbetested.

15

Priori8zingstoriesintoabacklog

•  Agilecustomersorproductownerpriori#zestoriesintoabacklog

•  Acollec#onofstoriesforaso9wareproductisreferredtoastheproductbacklog

•  Thebacklogispriori#zedsuchthatthemostvaluableitemsarehighest

16

UserStoryMapping

•  UserStoryMappingisananapproachtoOrganizingandPriori#zinguserstories

•  Unliketypicaluserstorybacklogs,StoryMaps:–  makevisibletheworkfloworvaluechain

–  showtherela#onshipsoflargerstoriestotheirchildstories

–  helpconfirmthecompletenessofyourbacklog

–  provideausefulcontextforpriori#za#on–  Planreleasesincompleteandvaluableslicesoffunc#onality.

17

UserStoryMapping

•  Spa#alarrangement:–  Byarrangingac#vityandtask‐centricstorycardsspa#ally,wecantellbiggerstories

–  Arrangeac#vi#esle9torightintheorderyou’dexplainthemtosomeonewhenaskedtheques#on:“Whatdopeopledowiththissystem?”

time

18

UserStoryMapping

•  Overlapusertasksver#callyifausermaydooneofseveraltasksatapproximatelythesame#me

–  IfintellingthestoryIsaythesystems’usertypically“doesthisorthisorthis,andthendoesthat,”“or’s”signalastackingver#cally,“andthen’s”signalsteppinghorizontally.

time

19

UserStoryMapping

•  Themapshowsdecomposi#onandtypicalflowacrosstheen#resystem.

•  Readingtheac#vi#esacrossthetopofthesystemhelpsusunderstandend‐to‐enduseofthesystem.

time

Beloweachac#vity,orlargestoryarethechildstoriesthatmakeitup

20

UserStoryMapping‐priori8zing

•  Priori#zingbasedonproductgoal– Productgoalsdescribewhatoutcomeorbenefitreceivedbytheorganiza#ona9ertheproductisinuse

– Useproductgoalstoiden#fycandidateincrementalreleases,whereeachreleasedeliversbenefit

21

UserStoryMapping‐priori8zing–  Createhorizontalswim‐lanestogroupfeaturesintoreleases

–  Arrangefeaturesver#callybynecessityfromtheuser’sperspec#ve

–  Splittasksintopartsthatcanbedeferred#lllaterreleases–  Usetheproductgoalsfromyourhandoutstoiden#fyslicesthatincrementallyrealizeproductgoals

op

tion

alit

y

necessary

less optional

more optional

22

Agile‐Challenges

•  Ac#veuserinvolvementcanbeverydemandingontheuserrepresenta#ve's#meandrequireabigcommitmentforthedura#onoftheproject.

•  Itera#onscanbeasubstan#aloverheadifthedeploymentcostarelarge

•  Agilerequirementsarebarelysufficient:

–  Thiscanmeanlessinforma8onavailabletonewstartersintheteamaboutfeaturesandhowtheyshouldwork.

•  Usuallynotsuitableforprojectswithhighdeveloperturnoverwithlong‐termmaintenancecontract

•  Arguablynotsuitableforsafetycri#calsystems.

UserStoriesSummary

•  UserStoriescombinewriMenandverbalcommunica#ons,supportedwithapicturewherepossible.

•  UserStoriesshoulddescribefeaturesthatareofvaluetotheuser,wriMeninauser’slanguage.

•  UserStoriesdetailjustenoughinforma#onandnomore.

•  Detailsaredeferredandcapturedthroughcollabora#onjustin#mefordevelopment.

•  TestcasesshouldbewriMenbeforedevelopment,whentheUserStoryiswriMen.

•  UserStoriesshouldbeIndependent,Nego#able,Valuable,Es#matable,SmallandTestable.