user stories

18
USER STORIES

Upload: udairaj

Post on 16-Dec-2014

1.138 views

Category:

Technology


7 download

DESCRIPTION

 

TRANSCRIPT

Page 1: User stories

USER STORIES

Page 2: 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?2

Myths Of Requirements

Page 3: User stories

Simple

User observable behavior

Right focus – delivering business value, not internal tasks

Prioritized3

User Stories

Page 4: User stories

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

4

User Stories

Not Detailed. Defers details.

Verbal Communication

Reminder

Tool for implementing not just documenting

By Design …..

Page 5: User stories

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

Written from the user perspective

Should NOT specify implementation

5

Looks Like This

Page 6: User stories

Lightweight documentation

To be able to code without performing business analysis

Context for the story requirement and actionable content6

Story Narrative

Page 7: User stories

7

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

Defines what has to be built to implement a story

Defined by the customer, QA and analysts

Page 8: 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 8

Independent

Negotiable

Valuable

Estimable

Small

Testable

Criteria / Guidelines

Page 9: User stories

9

Too Big?

Too Small?

Rule of Thumb

Page 10: User stories

10

Ext. interfaceDBBus. LogicControllerUI

A good story thinks like this

Not like this

Its Vertical

Page 11: User stories

11

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 12: User stories

Goldplating

Too many details

Including user interface detail too soon

Think too far ahead (not JIT)

Analysis Paralysis

Split too many stories12

Common Mistakes

Page 13: User stories

Scope difference

Difference in level of completeness

Written for difference purpose

Use Cases

Page 14: 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 15: 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 16: 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 17: 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.