User Stories RAJEEV SINGH (954) 305-7782 www.AgileMontage.com
User Stories
RAJEEV SINGH(954) 305-7782 www.AgileMontage.com
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
Requirements
Requirements
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
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
Simple
User observable behavior
Right focus – delivering business value, not internal tasks
Prioritized9
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 …..
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
Lightweight documentation
To be able to code without performing business analysis
Context for the story requirement and actionable content12
Story Narrative
13
15
Format: Given <>, When <>, Then <>
Defines what has to be built to implement a story
Defined by the customer, QA and analysts
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
Too Big?
Too Small?
18
Rule of Thumb
19
Ext. interfaceDBBus. LogicControllerUI
A good story thinks like this
Not like this
Its Vertical
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
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
Scope difference
Difference in level of completeness
Written for difference purpose
Use Cases
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
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.
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
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.
User Stories
RAJEEV SINGH(954) 305-7782 www.AgileMontage.com