User stories

1,563 views
1,381 views

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,563
On SlideShare
0
From Embeds
0
Number of Embeds
140
Actions
Shares
0
Downloads
30
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • User stories are a simple way of describing and tracking project requirements.User stories describe user observable features the system needs to provide.User stories keep us focused on delivering value to end users, rather than focus on internal tasks.Prioritized by the customer
  • Difference between use cases and stories: - Longevity - Use Cases are more prone to include details of the user interfaces. With stories, the user interfaces will come up during the conversations with the customerA user story is similar to a single scenario of a user caseA use case is a generalized description of a set of interactions between the system and one or more actors, which could be either a user or another systemScope differenceStories are kept smaller in scope for the purpose of schedulingDifference in level of completenessStory card + acceptance tests = use case main success scenario – James GrenningWritten for difference purposeUse cases are written for both customers and developers to read and agree to on a “design by contract” basisUser stories are written to facilitate release and iteration planning, and serve as a placeholder for conversations about the user’s detailed needs
  • EMR System: Communication within a practice and between practice and the patient is the single most important element of a good EMR system. Patient communication involves appointment scheduling, obtaining histories (medical, social, fianancial, etc.), receiving incoming messages from labs, etcEMR System > Messaging Center > View MessagesEMR System > Clinical Documentation > Encounter ManagementAs an XYZ I want to edit information associated with a patient record so that it can be corrected.
  • 181 - As a physician I want to manually correct information associated with a patient's record that is incorrectly associated with a patient's record 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 errored 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 184.1 - As a physician I want to be able to forward messages to interested parties so that I can send my messages to them
  • User stories

    1. 1. Verbal communication? Comprehensible by everyone? Right size for planning? Work for iterative development? Encourage deferring detail? Encourage participatory design? Build up tactical knowledge? 2
    2. 2. Simple User observable behavior Right focus – delivering business value, not internal tasks Prioritized 3
    3. 3. 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
    4. 4. Written in this format: As an X , I want Y, so that Z Written from the user perspective Should NOT specify implementation 5
    5. 5. Lightweight documentation To be able to code without performing business analysis Context for the story requirement and actionable content 6
    6. 6. 7 Format: Given <>, When <>, Then <> Defines what has to be built to implement a story Defined by the customer, QA and analysts
    7. 7. 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
    8. 8. 9 Too Big? Too Small?
    9. 9. 10 A good story thinks like this Not like this
    10. 10. 11
    11. 11. Goldplating Too many details Including user interface detail too soon Think too far ahead (not JIT) Analysis Paralysis Split too many stories 12
    12. 12. Scope difference Difference in level of completeness Written for difference purpose
    13. 13. 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.
    14. 14. 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.
    15. 15. 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
    16. 16. 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.

    ×