1. Agile User Stories

2. What is a User Story? User stories are 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 agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality.  As a, I want so that. They strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.

3. Examples Epic level:  As a user, I can backup my entire hard drive. Because an epic is generally too large for an agile team to complete in one iteration, it is split into multiple smaller user stories before it is worked on. The epic above could be split into dozens (or possibly hundreds), including these two:  As a power user, I can specify files or folders to backup based on file size, date created and date modified.  As a user, I can indicate folders not to backup so that my backup drive isn't filled up with things I don't need saved.

4. How to add detail to User Stories  By splitting a user story into multiple, smaller user stories.  By adding “conditions of satisfaction.” As a vice president of marketing, I want to select a holiday season to be used when reviewing the performance of past advertising campaigns so that I can identify profitable ones. Detail could be added to that user story example by adding the following conditions of satisfaction:  Make sure it works with major retail holidays: Christmas, Easter, President’s Day, Mother’s Day, Father’s Day, Labor Day, New Year’s Day.  Support holidays that span two calendar years (none span three).  Holiday seasons can be set from one holiday to the next (such as Thanksgiving to Christmas).  Holiday seasons can be set to be a number of days prior to the holiday.

5. Who writes User Stories  THE TEAM!

6. When do we write User Stories?  All the time; it is part of the Scrum process

7. Other thoughts: Non-functional Requirements  As a customer, I want to be able to run your product on all versions of Windows from Windows 95 on.  As the CTO, I want the system to use our existing orders database rather than create a new one, so that we don't have one more database to maintain.  As a user, I want the site to be available 99.999 percent of the time I try to access it, so that I don't get frustrated and find another site to use.  As someone who speaks a Latin-based language, I might want to run your software someday.  As a user, I want the driving directions to be the best 90 percent of the time, and reasonable 99 percent of the time.

8. Other thoughts: Use cases v. User Stories User stories aren’t use cases. By themselves, user stories don’t provide the details the team needs to do their work. The Scrum process enables this detail to emerge organically, (largely) removing the need to write use cases. Use acceptance criteria:  As a conference attendee, I want to be able to register online, so I can register quickly and cut down on paperwork, the acceptance criteria could include:  A user cannot submit a form without completing all the mandatory fields  Information from the form is stored in the registrations database  Protection against spam is working