What are User Stories?

User stories exist to help the programmer implement some functionality.

The user story starts the conversation between the user (knows what the software must do) and the programmer (knows how to make it do things). In order to get detail on exactly how it should work, the two must have an exchange of ideas - a conversation.

• Face-to-face with a whiteboard - by far the best method.
• Voice-to-voice (phone) - much less effective.
• Chat - Even worse and time-consuming but may be the best for long-distance teams.
• Emails - Terrible! For Pete's sake avoid email.

A great user story is ...

• Written by the user.
• Simpler is better.
• Informal is better.

Don't be afraid to INVEST in your user stories.

• Independant - Stories should be decoupled. A story should not require another one to be done first.
• Negotiable (And Negotiated) - The story isn't a contract. It requires a back-and-forth between programmer and user/author. The conversation is the key.
• Valuable - If we can't articulate how it helps the business, we have no business coding it.
• Estimable - From the story, we should be able to provide a ballpark estimate in ideal hours.
• Small - Small stories tend to allow us to release quicker, thereby getting functionality to users quicker and with less risk. Typical stories should be on the scale of a couple of hours to a couple of days. If they're larger than that, they can probably be broken into smaller stories.
• Testable - If you can't easily envision how you'll test this functionality, you don't understand it well enough. Testability is an absolute requirement for TDD.

(This awesomely sticky INVEST anagram comes from William Wake.)

Story Descriptions

Description should be in this format:

In order to [business's goal]
As a [user's role]
I want [software's new behavior].

We're placing the "In order to" in the front to emphasize the value that it has. If we can't easily put it into words, we should really consider omitting the feature.

(Adapted from: Liz Keogh's blog.)

Good articles on user stories

• Extreme Programming

User Stories vs. Use Cases - When to use each?

The programmer is supposed to write software that does the job, right? But how do they know what it is supposed to do? There are lots of ways including:

1. Functional Requirements - One-sentence description of functionality.
2. Design Document - Very technical description of behind-the-scenes workings.
3. Specification (aka. Specs) - Detailed technical description of parts of the program.
4. Use Cases - A detailed document written in layman's terms. Usually an expansion of a functional requirement.
5. User Stories - A very brief description of behavior.

Now functional requirements and design documents are needed but were never intended to tell the developer what he is supposed to be writing. Most groups write specs, use cases, or user stories. ... and they'll never switch. This sucks the life out of a project.

Which is best?

At the start of a project, use cases do the best job. But after it is underway, user stories become much more appropriate.

Why? Because at the start of a project we need to build forms and know what the back-and-forth between user and software should look like. Use cases provide that and user stories do not.

After the forms are created, the detail that use cases provide merely gets in the way of the developer who needs to know the main point of a change in functionality. The user story's brevity forces its writer to elimate all the fancy packaging and get to the point.

How will you know when to switch?

Not as big a decision as you might think. Start with use cases and wait until you have one screen shot/storyboard of each form. Then begin to poll your use case writers regularly. When you start hearing heavy sighs and hear things like "Do I have to?", "Oh, no", or other exclamations that are equally depressing, begin to transition some writers to user stories.

At this point be ready for an accelleration. You'll start to see the writers getting way ahead of the programmers with a large backlog of programming work to do. You managers may be able to move some of your writers back to programming duty (which all real programmers will thank you for profusely).

After the switch, listen again. If you start to hear complaints about lack of detail, you've likely switched too soon. Transition the basic functionality back to use cases.

This back-and-forth will be healthy and will allow you to keep your balance. Just don't make the mistake of thinking that you have to be married to one method or the other.

Let's be agile, after all.