What’s the Problem with User Stories?

The Agile Manifesto was written in part to get away from the baggage and waste associated with traditional waterfall projects. Those who have been in the software industry awhile will remember those nightmare projects where you spent months with the client documenting the requirements, and as soon as you started building the system, you realized that all of that work was worthless.

It’s like the famous military quote from Prussian commander Helmuth van Moltke, “No plan survives first contact with the enemy.” Likewise, no requirements survive first contact with the real system.

To mitigate this problem, agile projects focus on customer interactions and very lightweight, simple requirements embodied in user stories.

However, there are some major problems with relying solely on user stories (and aggregations such as epics, features, themes, and capabilities that are used in SAFe) for your definition of requirements:

• They are subject to interpretation, requiring frequent access to the customer and end-users to clarify, which may not always be possible
• They’re not as good for visual thinkers who may find diagrams, prototypes, and process flows more intuitive
• It’s hard to look back and justify earlier decisions for systems that remain in production for long periods
• The lack of specificity in user stories can make testing more difficult than with more verbose requirements
• Many industries require more detail than user stories provide to be able to develop software and be compliant with legal regulations and standards (the GDPR, CFR Part 11, ISO, DO-178C, DOD5000, NERC-CIP, etc.)

Writing Better Requirements

The following diagram illustrates a good roadmap for thinking about ways to write better requirements:

As you go from left to right, you are starting with defining the general business drivers and motivations—this is important context to have when understanding the requirements for the project and system—and moving toward defining and describing the project’s requirements.

In each of the parts of the roadmap, the items marked with an asterisk are effectively the activities it always makes sense to perform:

1. Understand the drivers and goals
2. Break down the problem into broad themes
3. Write the user stories
4. Update the stories and write acceptance tests as you develop the system

This will be pretty typical for most agile projects. At each stage, you should also ask these questions:

• How easy is it to get live access to the end-users who will use the system being developed?
• What rules, laws, and other mandatory requirements will apply to the system?
• Do you have a separate business analysis team, or is the agile team responsible for the requirements of the system?
• How do the different members of your team think—are they visual thinkers, literal thinkers, abstract thinkers?

Based on the answers to those questions, consider some of the additional activities in each step of the roadmap. By only doing the activities that make sense for your project and your context, you can keep your process lightweight and agile but still fulfill the necessary requirements.

Adam Sandman is presenting the session Think User Stories Are Enough? Think Again! at the entirely remote Agile + DevOps Virtual conference, June 8–11, 2020.