27
User Stories RAJEEV SINGH (954) 305-7782 www.AgileMontage.com

User stories

  • Upload
    udairaj

  • View
    533

  • Download
    0

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: User stories

User Stories

RAJEEV SINGH(954) 305-7782 www.AgileMontage.com

Page 2: User stories
Page 3: User stories

The product shall have a gas engine.

The product shall have four wheels.

The product shall have a rubber tire mounted to each wheel.

The product shall have a steering wheel.

The product shall have a steel body.

Requirements

Page 4: User stories

Requirements

Page 5: User stories

Requirements

Page 6: User stories

The product shall have a gas engine.

The product shall have high torque.

The product shall have four large wheels.

The product shall have high ground clearance.

The product shall have a tough body.

The product should be able to haul heavy cargo.

Requirements

Page 7: User stories
Page 8: User stories

Verbal communication?

Comprehensible by everyone?

Right size for planning?

Work for iterative development?

Encourage deferring detail?

Encourage participatory design?

Build up tactical knowledge?8

Myths and Challenges

Page 9: User stories

Simple

User observable behavior

Right focus – delivering business value, not internal tasks

Prioritized9

User Stories

Page 10: User stories

A story is a promise of a conversation --Mike Cohn, “User Stories Applied”

10

User Stories

Not Detailed. Defers details.

Verbal Communication

Reminder

Tool for implementing

not just documenting

By Design …..

Page 11: User stories

Written in this format: As an X , I want Y, so that Z

Written from the user perspective

Should NOT specify implementation

Looks Like This

Page 12: User stories

Lightweight documentation

To be able to code without performing business analysis

Context for the story requirement and actionable content12

Story Narrative

Page 13: User stories

13

Page 14: User stories
Page 15: User stories

15

Format: Given <>, When <>, Then <>

Defines what has to be built to implement a story

Defined by the customer, QA and analysts

Page 16: User stories
Page 17: User stories

Keep stories short & business language focused

Seek a level of granularity that can be completed in a few days

Do not include implementation details

Do not stop talking 17

Independent

Negotiable

Valuable

Estimable

Small

Testable

Criteria / Guidelines

Page 18: User stories

Too Big?

Too Small?

18

Rule of Thumb

Page 19: User stories

19

Ext. interfaceDBBus. LogicControllerUI

A good story thinks like this

Not like this

Its Vertical

Page 20: User stories

20

Ext. int.

DB

Bus. Logic

Cntlr

UI

Ext. int.

DB

Bus. Logic

Cntlr

UI

Ext. int.

DB

Bus. Logic

Cntlr

UI

Ext. int.

DB

Bus. Logic

Cntlr

UINot like this either

Thin Slices

Page 21: User stories

Goldplating

Too many details

Including user interface detail too soon

Think too far ahead (not JIT)

Analysis Paralysis

Split too many stories 21

Common Mistakes

Page 22: User stories

Scope difference

Difference in level of completeness

Written for difference purpose

Use Cases

Page 23: User stories

EMR System > Clinical Documentation > Encounter Management

EMR System > Messaging Center > View Messages

As An XYZ I want to edit information associated with a patient record so that it can be corrected.

Example

Page 24: User stories

181 - As a physician I want to manually correct information associated with a patient's record so that patient records are accurate

181.1 – As a physician I want to be able to change encounter information and mark entry as an error if applicable, entering reason(s) why information has been erroneous so that patient's medical record is accurate.

181.2 – As a provider I want to be able to reassociate associated patient information (while retaining history for original patient) so that the patient's medical record is accurate.

Page 25: User stories

183 - As a physician I want to manually associate messages that can't be automatically associated with a patient's record

183.1 - As a physician I want to be able to create a sticky note message so that I can share information with interested parties 183.2 - Send message

183.3 - As a physician I want to be able to forward messages to interested parties so that I can send my messages to them

Page 26: User stories

Title Send a Message

Story As a physician I want to be able to forward messages to interested parties so that I can send my messages to them

Context (Some portions Out of Scope for this story) The user will be allowed to create a new message, which may or may not be attached to patient details, in story 183.1 This story relates to the validation and sending of that message. It also includes recording the fact that the message was sent, for later retrival/display with story 171.2 (View sent sticky note message). Note that, for the purposes of this story, sending tasks with attached due dates and/or recurrence (created in story 193) are NOT in scope.

Acceptance Criteria: GIVEN (THAT) WHEN THEN I have created a sticky note message with a valid individual recipient and no attached patient

I request the message to be sent

Then the message is delivered to the recipient's message queue and added to the sender's sent items

I have created a sticky note message with a valid individual recipient and an attached patient that the recipient is NOT allowed to see

I request the message to be sent

I see an error message informing me that the recipient cannot view the patient AND The message will not be added to the recipient's message queue or added to the sender's sent items

Out of Scope 183.1 - Create Message

171.2 - View Sent Sticky Note Messages

New - Allow an unsent message to be saved as a draft message

Open Items: 1. Is auditing in scope for this story?

- Auditing is done when a patient is loaded. No additional auditing is required on message send.

Page 27: User stories

User Stories

RAJEEV SINGH(954) 305-7782 www.AgileMontage.com