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].”