User Stories and Use Cases

User Stories are one of the key agile artifacts for helping implementation teams deliver the most important capabilities first. They differ from use cases in some important ways, but share more commonalities than you might think.

User Stories Applied

Mike Cohn wrote User Stories Applied: For Agile Software Development. It is the book for understanding how to write, estimate, and use user stories. If you’re thinking about trying out “agile” for the first time – and you haven’t read his book, you need to. He provides great detail and anecdotes about how to write, manage, and utilize user stories.

What are user stories?

A user story is a user-centric description of the goals that one or more people will achieve by using your product. User stories are applicable whenever there is a person, interacting with an interface to a product, to achieve a goal. They aren’t just for software – even though the tone of this article may imply it (since I live in a software mindset most of the time).

A user story is written in the format

• As a [person in a role] I want to [perform some activity] so that [some goal is achieved].

That’s it. No more. Perfectly atomic, very concise and unambiguous. Where did this elegant idea come from?

User-centered design (UCD) is an approach to product design that can almost be considered a philosophy. In college, I used to say that industrial designers designed things from the outside in, and engineers designed things from the inside out. The ideal products are the ones that marry form (outside) and function (inside) in an elegant solution that blurs the lines of distinction. The first designers of engineered products were the engineers, and the first designers of software were the programmers – they were the only ones who knew what could be accomplished. Anyone who has used an application with a user interface designed by a database expert can remember what that was like. Eventually, someone successfully adopted the mindset of designing a product based on what someone could use it to do instead of looking at what it could do and figuring out how to use it. That under-emphasizes the importance of UCD, but you get the idea.

Out of UCD come different things that really drive how we create products today. Kessler and Sweitzer focus on understanding these user goals in Outside-In Software Development. Stakeholder goals drive (arguably, are) requirements. But it is difficult to develop actionable implementation plans directly from goals. You need something to bridge that gap.

A user story, in an agile process, bridges that gap. In Wiegers’ world of structured requirements, that gap is spanned with use cases.

Conceptually, a user story crosses the same chasm as a use case. A user story defines what people need to accomplish (e.g. faster call processing), in order to achieve the goals of the company (e.g. lower call-center costs), given a solution approach (write software versus outsource to lower-cost call center employees).

Now we find ourselves in a confusing situation – there are user stories, use case scenarios, and at least three different kinds of use cases – formal and informal use cases, and use case briefs. How are they different, and how are they the same?

Usage Descriptors

Use cases, use case scenarios, and user stories all document descriptions of how a product will be used. They vary, along a continuum, in terms of the amount of overhead required to create each.

• Formal use cases require the most effort. They have a lot of pomp and circumstance going on, but they describe all the permutations of how some person does some activity (or its variations).
• Informal use cases are pretty much the same – just less formal. The challenge is to provide the right level of detail, without the guide-rails of the formal use case to remind you.
• Use case briefs have almost no overhead, but have the same “how much is enough” challenges of informal use cases, only more so. Think of it as a single-paragraph description of a formal use case.
• User stories have the least overhead, and provide the least context.

Use case scenarios are a slightly different breed. Like a user story, a use case scenario describes one path through a multi-path use case. But you can’t (or at least I’ve never seen anyone) create a use case scenario without first creating the formal use cases. This artifact basically combines the weakness of a formal use case (high overhead) with that of a user story (limited context). It can be very handy for developing test cases if your testing team is not well versed in writing test cases. We’ll leave use case scenarios out of the rest of the discussion.

The cost of high overhead in documentation comes with a benefit – increased detail.

Because a user story captures a single path through a use case, while having less overhead, it also captures less detail. This is ok, because an agile process stresses communication over comprehensive documentation. You start to run into inefficiencies when the amount of conversation (especially when repeated) is burdensome. The amount of conversation required is a function of the amount of domain expertise, or context, that the implementation team already has.

Should I write User Stories or Use Cases?

It depends on your audience. The formal and informal use cases, in addition to having more overhead, also provide more context, and allow you to describe more complex usage patterns of your product. Some uses are so complicated that you have to use a use case to describe them. Others are so simple that anything other than a story is wasted effort. The interpretation of complicated and simple, though, is not purely an assessment of what the users want to do – it varies with the level of domain expertise of your implementation team.

Some teams simply aren’t equipped to consume user stories or use case briefs. You have to write your requirements for the readers, so you need to know when people are struggling to implement solutions based upon stories or briefs, and give them more structure and formality. You have to adapt to the realities of your current situation, and the experience of your team.

You could replace the words “Reader Domain Expertise” with “Writer Trust of the Team” if you wanted, and the graph would look about the same. This is another concept that is critical to a team working effectively – trust equates to delegation.

If you can trust your team to come up with a solution that matches the story, delegate that “next level of detail” to them. If you can’t trust them, then don’t. But you should. One of the benefits of agile is that your team will quickly give you a solution, and then you can give them feedback. If they don’t create a solution that meets your interpretation of your user’s needs, then give them feedback, and they will change it. The agile process actually relies on this dynamic to allow less-verbose artifacts to still be effective. Someone on the team will sketch out what the solution will look like, and get your feedback, before implementing. The more this collaboration happens, the more effective a light-weight document will be.

Conclusion

Don’t just rely on platitudes about stories and use cases. Think about the nature of the different artifacts. Think about their strengths and weaknesses. Consider how you interact with your team. Should you trust your team? Do you trust your team? Determine what they need, and give it to them.