2. Verbal communication?
Comprehensible by everyone?
Right size for planning?
Work for iterative development?
Encourage deferring detail?
Encourage participatory design?
Build up tactical knowledge?
2

3. Simple
User observable behavior
Right focus – delivering business value, not internal tasks
Prioritized
3

4. 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

5. Written in this format: As an X , I want Y, so that Z
Written from the user perspective
Should NOT specify implementation
5

6. Lightweight documentation
To be able to code without performing business analysis
Context for the story requirement and actionable content
6

7. 7
Format: Given <>, When <>, Then <>
Defines what has to be built to implement a
story
Defined by the customer, QA and analysts

8. 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

9. 9
Too Big?
Too Small?

10. 10
A good story thinks like this
Not like this

11. 11

12. Goldplating
Too many details
Including user interface detail too soon
Think too far ahead (not JIT)
Analysis Paralysis
Split too many stories
12

13. Scope difference
Difference in level of completeness
Written for difference purpose

14. 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.

15. 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.

16. 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

17. 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.