Author: Andrew Hayward

When to use User Stories, Use Cases and IEEE 830 Part 1

A hammer is good for nails, not so good for fixing televisions. A scooter is the best way to get around town, unless you’re in Montreal in January. Choosing one method to describe the customer’s need across projects, teams and environments actually hinders good analysts, architects and developers as much as it helps. What is much more valuable is having an analyst who understands and has the ability to use all of the tools, and relying on her to work with her team to decide whether to hammer the nail or take the subway.

Use Cases, IEEE 830 style “The system shall…” requirement statements, and User Stories each have advantages and disadvantages. A good analyst, or project manager, should know the advantages and have the ability to choose which is most appropriate for the project.

Over the next few posts I’m going to discuss the advantages and disadvantages of all three of these methods, while providing examples that are based on the same functionality for comparison. This post will start with User Stories.

User Stories

As a customer, I can reserve a hotel room with a credit card

User stories are vague. Any developer reading this would have 100 questions – Which credit cards? What does it mean to reserve a room? Can they choose a specific room in the hotel? and so on.

This is intentional. A user story is not a statement of need so much as a placeholder for a conversation. The user story has enough information in it, initially, to remind the person who submitted it what it was about and for developers to give a rough estimation of work. By rough estimation, I mean identifying how complex or difficult it is compared to other user stories, not how many hours it will take. Estimation of a user story provides a comparison so the customer can prioritize the user story against other user stories. Estimating a user story is not an estimate to be used in budgeting and resource allocation.

There are a couple of acronyms people refer to when providing guidance for the writing of User Stories. CCC (Card, Conversation, Confirmation) emphasizes that the user story should fit on a 4×6 inch card (written with a fat marker preferably). This limitation in size is enforced to discourage the reliance on the User Story card as a specification. Understanding the detail should be through conversations with the customer rather than the written information. During these conversations, acceptance criteri