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 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?

User Story

Transcript: Epic/User Story 9/20/2018 © 2009-2018 CRM Web Solutions, LLC. All Rights Reserved. Scrum Master Presented By: Time-Box By Scrum Master 15 Minutes Agenda Agenda 1. What is Epic? 2. What is a user story? 3. Who writes user stories? 4. Template of user story 5. Benefits of user stories Epic An Epic can be defined as a big chunk of work that has one common objective. It could be a feature, customer request or business requirement. In backlog, it is a placeholder for a required feature with few lines of description. It tells compactly about final output of user needs. In the beginning, it may not contain all the details that team needs to work on. These details are defined in User Stories. An epic usually takes more than one sprint to complete. The Epics we are working today has the duration of 6 months. Epic Epic The Basic unit of work defined in Scrum is user story. But very often, when Product Owner/Stakeholders writes a user story for a feature or against customer request, that looks simple in the beginning. But, while covering all related work and scenarios, same user story expands so much that it can not fit either in a week or a sprint time-frame. It is the time to consider this big user story as epic and start slicing it in smaller user stories. "Think of epic as a book and user stories are its’ chapters". Epic Example Future Single Center Success As a single center owner, I wear many hats which means I do not have time in the middle of the day to implement a new system nor do I have the time to sit through trainings. Because I need this system, I want an ‘out of the box’ solution that just works and that doesn’t involve a lot of interaction on my part so that I can spend more time running my business, working with my staff, the families and most importantly – the kids. Given how busy I am during my workday and dealing with limited resources, when I sign up for ChildCareCRM I will then have a seamless on-boarding experience that I can execute on my own. Acceptance Criteria: • Ability to self-onboard from signup to billing • Comprehensive training videos and user guides available • Customer success already knows how to assist me when I may need help • Ability to pay for ChildCareCRM to deploy my system for me Example Example Center-Based User Experience (Epic 1) Future Single Center Success (Epic 2) Partnerships for the User's Benefit (Epic 3) User Story User Story A short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. All user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality or outcomes. Slim and High-Level Requirements A good way to think about a user story is that it is a reminder to have a conversation with your customer (in Scrum project stakeholders are called customers). User story is just-in-time analysis. In short, user stories are very slim and high-level requirements. A user story represents a small piece of business value that a team can deliver in an iteration. Who writes user stories? Anyone can write user stories. It's the product owner's responsibility to make sure a product backlog of agile user stories is there. Also, note that who writes a user story is far less important than who is involved in the discussions of it. When are user stories written? User stories are written throughout the Scrum project. Usually a Story-writing workshop is held near the start of the Sprint. Everyone on the team participates with the goal of creating a product backlog that fully describes the functionality to be added over the course of the project or a three to six-month release cycle within it. How to Write Good User Stories User’s requirements written from that end user’s perspective. A user story is not a context less feature, written is “dev” speak. User story can be written in simple words. You don't need to use any technical language. Describe user story in your own words. How is detail added to user stories? Detail can be added to user stories in two ways: By splitting a user story into multiple, smaller user stories. By adding “Conditions of Satisfaction/Acceptance Criteria ” Acceptance Criteria Goals To clarify what the team should build before they start work To ensure everyone has a common understanding of the problem/need of the customer To help team members know when the story is complete To help verify the story via automated tests User Story Template They typically follow a simple template: As a <type of user/persona>, I want <some feature> so that <some reason> Let’s break this down one step further; As a <type of user/persona> — this is the WHO. Who are we building this for? Who is the user? I want <some feature> — this is the WHAT. What are we building? What is the intention? So that <some reason> — this is they WHY. Why are we building it? What is the value for the customer? “As a [persona], I [want to], [so that].”

Now you can make any subject more engaging and memorable