You're about to create your best presentation ever

User Story Presentation Template

Create your presentation by reusing one of our great community templates.

User Story

Transcript: www.your-website.com A Good User Story Insert some text here March 2017 Story should be from user point of view Definition of User Story A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. A Little Video Insert your own text here. Talk about something related to your first topic or just put some placeholder text here. A Little Video... INVEST Invest is the way to go! 3 C's of User Story INVEST For a good user story: What comprises of a good user story Some examples of Good user story Some examples of Good user story GROWTH-597 As a User, I want to be taken to a landing page upon clicking on the unsubscribe link at the bottom on the email alert email so that I can see the confirmation that I have been unsubscribed. TPS-653 As a Marketing manager, I would like to provide correct information regards to the Auction Type to the buyers looking at a TPS Online asset on the native app so that I am not at any legal risk and not misrepresenting an online foreclosure sale. TPS-639 Automation Scripts from sprint 16 TPS-614 We need to create the flag to support old and new version of emails. TPS-512 REO PDP | Instrumentation | Page Load and initial items TPS-393 ADC RTK 2.0 Upgrade - TPS PDP REO-4 API | Short Sales | Update Search API (we do not have "Short Sale" filter on UI yet) Bad Stories Bad Stories Suggestions: Suggestions: Story should only be created by Product (Not by Dev, QA) Story should be a user story (Follow INVEST) API support / FE support/ Instrumentation should not be a story by themselves. They should be a sub task to a story Automation ticket should be a Task linked to the story (not a sub task. It should not block a story from being closed) How to manage features where backend work can start one sprint before the FE work? Open Questions Open Questions

User Story Workshop

Transcript: Workshop User Story What/Why A user story should be small enough to fit into a sprint, descriptive enough to let the team know what is needed, but general enough to let the team find the best solution What Primary means of expressing needed functionality. They largely replace the traditional requirements specs. 'As a (user role), I want (activity) to, so that (business value) What Why User stories are broken down slices of larger projects. We want user stories to fit within a sprint and be the smallest piece of a project that can (hopefully) offer some value. Why Breakdown Epic Feature Feature User Story User Story User Story User Story User Story Epic = Project Timing of an epic can be anywhere from 3 months to 3 years Epic Elements of a good user story Elements Your title should be able to be read and understood by the stakeholder Meaningful titles Title It's important to state what you are looking for, but not direct the team how. Ex: I would like to be able to see all of my account information when I click on the 'me' button. A clear summary Summary Acceptance criteria provide the the information needed to ensure that the story is implemented correctly and covers the relevant functional and NFRs. Given, When, Then Acceptance Criteria Acceptance criteria It is more important to have a shared understanding "Individuals and Interactions over process and tools" Make it a conversation Conversation Feature breakdown Exercise In your smaller groups, break down a feature into user stories Ex:?? Story Mapping Story Splitting

User Story Mapping

Transcript: Reference Create your own user story map Create your own user story map Details and Release Form Groups Allows you to see "big picture" in backlog Tool for making decisions about grooming and prioritizing your backlog Visual alternative to traditional project plans Useful for discussion and managing scope Promotes silent brainstorming and a collaborative approach to generating user stories Form a group of 3-5 people Any less and you might miss ideas Any more then it slows the process User Story Mapping Create your own user story map Arrange the groups left to right in the order a user would typically complete the tasks You now having a skeleton of of your user story map Walk the skeleton to confirm you have not missed any major user tasks or activities You can now add more detailed user stories below each user task Break user story map into releases Create your own user story map In silence the team groups the post-its that are similar to each other Things that are dissimilar to each other should be moved farther apart Using another colour post-it, name each group and put the post-it on top of the group, these are called the user activities User Activities Google "user story mapping" or visit the website http://winnipegagilist.blogspot.ca www.cardboardit.com User Tasks Start by gathering the major user tasks of the project/application in silence - the "things people do" (ex. Compose E-mail, Create Contact, etc) Each person takes the same coloured post-it and silently writes down one user task per post-it Each person reads their post-it aloud and places them on the table in front of the group If there are duplicates, they should be removed at this point Benefits

User story Estimation

Transcript: low-tech and high-touch. dynamically reorganize cards schema-free markup reminders for much bigger ideas cards are extremely portable The requirement itself is communicated from customer to programmers through conversation: an exchange of thoughts, opinions, and feelings.The story text we write on cards is less important than the conversations we have. No matter how much discussion or how much documentation we produce, we can’t be as certain as we need to be about what is to be done. The third C in the user story’s key aspects adds confirmation that we sorely need. This component is the acceptance test. Is a collection of defining attributes that characterize a population of users and their intended interactions with the system We need Roles: For Usage Center Design To avoid missing Stories To Avoid Unused Stories For better business understanding Acceptance Criteria: Admin interface with ACL management demo the validation of the resource and resource operation Split Story Patterns As a role I want to goal so that motivation As a role I need feature so that business value As a user I need/want feature so that benefit In order to receive benefit as a role, I want goal/desire Story Decomposition Example: Estimation? Product vs Sprint Backlog User Story Format? 1.Workflow Steps 2. Business Rule Variations 3. Major Effort 4. Simple/Complex 5. Variations in Data 6. Data Entry Methods 7. Defer Performance 8. Operations (e.g. CRUD) 9. Break Out a Spike Share Your Pain? Independent Negotiable Valuable Estimable Sized appropriately or Small Testable What's wrong? Grooming vs Planning 'User story is User Story!' I N V E S T User Story As a PO, I want to have a unify ACL for different API (SOAP, REST) When to Split?

Now you can make any subject more engaging and memorable