Recommended
Recommended
More Related Content
Similar to User stories
Similar to User stories (20)
More from udairaj
Recently uploaded
Recently uploaded (20)
User stories
- 3. 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.
- 6. 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.
- 8. Verbal communication? Comprehensible by everyone? Right size for planning? Work for iterative development? Encourage deferring detail? Encourage participatory design? Build up tactical knowledge? 8
- 9. Simple User observable behavior Right focus – delivering business value, not internal tasks Prioritized 9
- 10. Not Detailed. Defers details. Tool for implementing not just documenting A story is a promise of a conversation --Mike Cohn, “User Stories Applied” User Stories Verbal Communication Reminder 10
- 11. Written in this format: As an X , I want Y, so that Z Written from the user perspective Should NOT specify implementation
- 12. Lightweight documentation To be able to code without performing business analysis Context for the story requirement and actionable content 12
- 13. 13
- 15. Format: Given <>, When <>, Then <> Defines what has to be built to implement a story Defined by the customer, QA and analysts 15
- 17. Independent Negotiable Keep stories short & business language focused Seek a level of granularity that can be completed in a few days Valuable Estimable Small Do not include implementation details Testable Do not stop talking 17
- 19. Not like this A good story thinks like this 19
- 20. 20
- 21. Goldplating Too many details Including user interface detail too soon Think too far ahead (not JIT) Analysis Paralysis Split too many stories 21
- 22. Scope difference Difference in level of completeness Written for difference purpose
- 23. 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.
- 24. 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.
- 25. 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
- 26. 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) I have created a sticky note message with a valid individual recipient and no attached patient I have created a sticky note message with a valid individual recipient and an attached patient that the recipient is NOT allowed to see WHEN I request the message to be sent I request the message to be sent THEN Then the message is delivered to the recipient's message queue and added to the sender's sent items 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.
Editor's Notes
- As comical as it may come across, at some point we have all had similar conversations. User stories help these situations.
- It’s a myth that requirements have the right level of detail. It’d be a herculean task to create such a requirement. It’s a grocery list, but you don’t have the recipe.
- It’s a myth that requirements have the right level of detail. It’d be a herculean task to create such a requirement.
- It’s a myth that requirements have the right level of detail. It’d be a herculean task to create such a requirement.
- It’s a myth that requirements have the right level of detail. It’d be a herculean task to create such a requirement.
- Stories are written such that they convey the gist with simplicity. Just as this picture does. Common knowledge isn’t documented, titles are self-descriptive.
- 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, financial, 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