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

Upload: phamcong

Post on 01-May-2018

221 views

Category:

Documents


1 download

TRANSCRIPT

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.