spinning stories the agile way - meetupfiles.meetup.com/3261132/dcsug - spinning stories the agile...

SpinningStoriesTheAgileWay

PresentedBy

ManjitSinghEnterpriseAgileTransformationCoach

President,AgiliousLLC

www.agilious.com @agilious

2 2

20 years of software development, management

& delivery experience

Consulted, trained, or coached with people and

teams from IBM, SRA, UMUC, NSF, DOJ, DOL, NSF

20 years of agile experience; started using XP in

2000 at IBM

MS Computer Science at SUNY Albany

Founder & organizer DC Agile User Group

Agile Coach & Trainer Manjit


3

Accelerating Agility

Agile Consulting

3

Coaching

Mentoring

High Performing

Team

Training

Engineering Practices

Agile Transformation •  Team and One-on-One

Agile coaching

•  Customized Agile Methodology training

•  Product Owner/Scrum Master/Team Member mentoring

•  Practical, hands-on learning of Software Engineering Practices (TDD, ATDD, Continuous Integration, Pair Programming, etc.)


4

Agile Product Development

Software Products

Mobile Apps

Web Apps

Enterprise Applications

Web Sites



5

Agile Training

Roles

•  Agile Business Analyst •  Agile Product Ownership •  Agile Team Facilitation •  Agile Project Management

Enginee-ring

•  Agile Testing •  Agile Test Automation •  Agile Programing Techniques

Team •  Agile Fundamentals



6 6

Primary Problem in Software Development

https://flic.kr/p/6fE1TN


7 7

Guess?

•  Software requirements is a communication problem.

•  People who want the software must communicate with those who will build it.


8 8

Requirements is a Communication Problem!

https://flic.kr/p/ehKDpk


9 9

Challenges

1.  Who defines requirements?

2.  How are they “discovered”?

http://www.officeclipart.com/office_clipart_images/document_being_search_by_a_magnifying_glass__search_icon_0515-1007-3003-0748_SMU.jpg


10 10

So Who Defines The Requirements?

…functionality and dates are mandated with little regard for reality

…done regardless of whether developers understand

…features are progressively dropped as the deadline nears

…lengthy upfront requirements negotiation and signoff

If the Business define them…


11

•  Assume everything is knowable in

advance •  Are time-consuming to write and

tedious to read •  Treat learning as a “Change of

Scope” •  Don’t lend themselves to iterative,

incremental delivery process

Why Not Requirements Documents? Expectation of Full & Complete Requirements Upfront


12 12

So Who Defines The Requirements?

...technical jargon replaces the language of the business

…may define incomplete or wrong requirements

…may not have full understanding of the business vision and/or the target users

…may trade quality for additional features

…may only partially implement a feature

…may solely make decisions that should involve the business

If the Developers define them…


13 13

What is the Solution?

Business and technical teams collaborate on defining and elaborating the requirements.


14 14

Capture requirements as User Stories

What does your customer want?

What value or benefit will they realize?

So What Do We Do?


15 15

What is a User Story?

•  Short descriptions of functionality–told from the perspective of a user

•  Are valuable to either a user of the software or the customer of the software.


16 16

What is a User Story?

The basic user story template is simplistic, it helps us remember a need while providing context.

Image credit Lithespeed


17 17

Why Use Stories?

•  Comprehensible •  Developers and customers understand them •  People are better able to remember events if

they are organized into stories†

•  Right size for planning

•  Support and encourage iterative development

•  Can easily disaggregate closer to development time


18 18

What User Stories Are NOT

User Stories ≠ Requirements

User Stories è Requirements

37

Context (Project Vision, Business Case, etc.)

User Story Conversation(s) Acceptance

Criteria

+ + Supporting Information

+

Common Understanding of a Need

Requirement

=

37

Requirements, More than Just a Story

Image credit Lithespeed


19 19

User Story Development

Comprised of three aspects:

1.  Written description of the story

2.  Conversations about the story that serve to flesh

out the details of the story

3.  Tests that convey and document details that can be

used to determine when a story is complete


20

•  Card–Storieswri+enonnotecardswithannota1onsasneeded(es1mates,notes,etc)

•  Conversa*on–Detailsbehindstorycomeoutthroughconversa1onswiththeProductOwner

•  Confirma*on–Acceptancetestsconfirmthestorywascodedcorrectly

Ron Jeffries 3 C’s


21

•  User or customer need •  Product description •  Used for planning

Starting point to understand User Stories are a Conversation


22

•  User*–HowdoIdescribewhatIwant?•  Stakeholder–WhatdoIneedinmyproducttobe

successful?

•  PM–HowdoItrackandschedulethiswork?•  BA–Whatarethedetailsofthisfeature?

•  UX–HowdoIunderstandtheusersneeds?•  Developer–WhatarethedetailsofthetasksI

needtoworkontoday?•  QA–HowdoIvalidatethiscompletedwork?

User Stories Facilitate Conversations


23 23

User Story Format

As a <user>,

I want to <take an action/accomplish a goal>

So that I <realize a benefit or value>

Description and Acceptance Criteria

Acceptance Criteria: 1.  Criteria A 2.  Criteria B 3.  Etc.


24

•  ASA–“Asabusinessowner…”

•  IWANT–“I’dliketheabilityto…”

•  SOTHAT–“SothatIcan…”

•  AcceptanceCriteria–VerifiableandtestablecriteriathatcanbetestedbasedonTHENclause.

•  OrSimply:“Asa<usertype>,Iwantto<func:on>sothatIcan<businessvalue>

Four Main Components of a User Story


25

ASA–“Asabusinessowner…”-  Wewantuserstobetangiblewithneeds

-  Buildout“Personas”or“UserRoles”–Standarduserdefini1ons(Sacred–Addedwithpurpose)

-  Avoidgenericterms

1. As a


26

IWANT–“I’dliketheabilityto…”/“Ineedtoac1on/func1on…”-  Thisisthemeatandpotatoesofthestory

-  Thisiswhereyoudescribethefunc1ons

2. I want


27

SOTHAT–“SothatIcan…”/“SothatIreceive…”-  Thisistoshowtheintrinsicvalueofthestory

-  Thevalueistothepersona,user,orauthor

3. Then


28

AcceptanceCriteria–Verifiableandtestablecriteriathatcanbetested;andifmetconfirmthatthe“ac1on”canbesuccessfullyperformed.-  Theseareessen1allytests–Condi1onsofsa1sfac1on

-  Example:Asauser,Iwanttocancelareserva*on.-  Verifythatapremiummembercancancel-  Verifythatuserreceivedaconfirma1onmessage-  Verifythataemailconfirma1onissent

4. Acceptance Criteria


29

AcceptanceCriteria–Verifiableandtestablecriteriathatcanbetested;andifmetconfirmthatthe“ac1on”canbesuccessfullyperformed.-  Theseareessen1allytests–Condi1onsofsa1sfac1on

-  Example:AsaPremiumMember,Iwanttocancelareserva*on.-  Icancancelareserva*on.-  Ireceiveaconfirma*onmessageaIercancela*onissuccessful.

-  Ireceiveanemailconfirma*onaIerIcancelareserva*on.

4. Acceptance Criteria Alternative Method


30

•  UserInterviews– Selectrightinterviewees– Askopen-ended,context-freeques1ons

•  Ques1onnaires– Largerpopula1onofusers– Whenyouneedspecificanswerstoques1ons

•  Observa1on– Bestforin-housedevelopments

•  Storywri*ngworkshops

GatheringUserStories


31 31

Let’s Write Some User Stories…

Practice time…


32 32

Exercise

Let’s Write Some User Stories… http://www.iubenda.com/blog/wp-content/uploads/2010/10/Schermata-2010-10-24-a-18.24.46.png


33

1.  EachtableisaScrumTeam2.  Iden1fyaProductOwner3.  Iden1fyaScrumMaster

4.  Eachteammemberindividuallywritesuserstories–asmanyastheycanorwantto!

5.  Take15minstowritestories6.  Take10minstoreviewthemall

7.  POselects5“best”stories8.  Putyour5bestuserstoriesontheflipchart9.  ScrumMasterfacilitatesandkeepstheteamwithinthe

allo+ed1meboxes.

Instructions


34

Product Vision Statement

For Busy families with kids Who Want to go on a kid-friendly vacation Our ZappVacation Service

Is a web site that offers curated kid-friendly vacation choices

That Allows consumers to buy a “vacation package” that includes all travel arrangements

Unlike Existing travel sites that do not offer vacation packages for families with kids

Our product Provides a smooth way to plan a vacation by searching for and discovering new vacation destinations.


35

Release Planning

https://www.versionone.com/agile-101/agile-project-management-customer-management-best-practices/agile-development-release-planning/


36

•  Independent–Oneuserstoryshouldbeindependentofanother(asmuchaspossible).

•  Nego*able–DetailsofthestorycanbeworkedoutduringanItera1onplanningmee1ng.

•  Valuable–Valuetothecustomer.

•  Es*mable–Thereneedstobeenoughdetailforthedeveloperstoes1mateauserstoryandtoallowpriori1za1onandplanningofthestory.

•  Small–Agoodstoryshouldbesmallineffort,typicallynomorethan2-3personweeksofeffort(smallerisbe+er)!

•  Testable–Userstoriesshouldbetestablewithcertainacceptancecriteria.

Bill Wake’s INVEST Model

INVESTModel


37

Questions


38

10311 Motor City Drive Suite 750 Bethesda, MD 20817

www.agilious.com

[email protected]

240.244.3311

www.facebook.com/agilious

@agilious

ADDRESS:

WEBSITE:

EMAIL:

TELEPHONE:

Our Contact Details

THANK YOU



39

ExtraSlides


40

Forpa*entswhohaveahard*meschedulingmedicalexamsandconsulta*onscoveredbytheirhealthinsurance…-  theDoctorFinderisaschedulingsystem

-  …thatmatchesthepa1ent’sneedwiththeavailabilityofthedoctororclinic.

-  Insteadofcallingseveraldoctorsandclinics,oursystemallowsthepatenttochoosefromviablegivenop1ons.

Scenario


41

AcceptanceStories–Verifiableandtestablecriteriawri+eninacceptancetestform.-  Scenario1:TITLE

-  GIVEN[context]-  And[somemorecontext]-  When[event]-  Then[outcome]-  And[anotheroutcome]

4a. Acceptance Stories


42

AcceptanceConfirma*on–Verifiableandtestablecriteriawri+enin“Success”and“Failure”terms-  Success–validuserloggedin

-  “Remembermyusername”selected–storecookie/automa1cloginnext1me

-  “Remembermyusername”notselected–forceloginnext1me

-  Failure–displaymessage:-  “Emailaddressinwrongformat”-  “Incorrectpassword,pleasetryagain”-  “Serviceunavailable,pleasetryagain”-  Etc.

4b. Acceptance Confirmation