Creating Effective User Stories

Are you struggling to create user stories that are truly useful to your team and customer? Learn the strategies for creating great User Stories, as well as tips for avoiding the common pitfalls many teams fall into.
Course info
Rating
(490)
Level
Intermediate
Updated
Jul 25, 2014
Duration
2h 17m
Table of contents
Description
Course info
Rating
(490)
Level
Intermediate
Updated
Jul 25, 2014
Duration
2h 17m
Description

Do you love the idea of capturing customer requirements with lightweight user stories rather than formal requirements documents? Of course you do, but many teams find that while the idea of user stories sounds great, they struggle to create effective user stories that are truly useful for communicating between themselves and their customer. In this course, we'll learn concrete strategies for creating lightweight user stories that truly capture our customer's needs, as well as tips for avoiding the most common pitfalls that many teams fall into when they first begin working with user stories.

About the author
About the author

Jeremy Jarrell is an agile coach and author who helps teams get better at doing what they love. He is heavily involved in the technology community, both as a highly rated speaker throughout the United States.

More from the author
Groovy: Getting Started
Beginner
1h 18m
Nov 8, 2018
Empowering Your Team with ICAgile
Intermediate
2h 4m
Aug 14, 2018
Achieving an Agile Mindset with ICAgile
Beginner
1h 50m
Jul 20, 2018
More courses by Jeremy Jarrell
Section Introduction Transcripts
Section Introduction Transcripts

Getting to Done
My name is Jeremy Jarrell, and welcome to Getting to Done, part of the Creating Effective User Stories course series. What gets a story to done? Getting a story to done usually involves two parts, meeting the customer's expectations, or ensuring that the story does what the customer expects it to do, and meeting the team's expectations, which means that the team is happy with the overall implementation of the story. Ensuring that the customer is happy with the overall outcome of the story usually involves such criteria as, the story does what the customer expects it to do. The feature doesn't crash while the customer is working with it. And the feature is easy to use, and quick for the customer to pick up. On the contrary, the team may have their own criteria for being happy with the outcome of the story. This criteria may have more of a technical bend, such as the code was written in a high quality manner. The code has been tested, and has great automated test coverage. And the code has been peer reviewed, or was written using pair programming. Getting a story to done involves identifying the specific criteria that would ensure both the customer and the development team are happy with the end result. In the next segment, we'll look at how to clarify, and capture the customer's expectations in a manner that allows both the team, and the customer to agree on the outcome of the story.