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.