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:
- Understand the drivers and goals
- Break down the problem into broad themes
- Write the user stories
- 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.
For a technique I look to business process modeling, preferably BPMN 2.0, to provide context for user stories. If you model both current and desired state, you can identify the delta as new functionality and describe them as user stories.
Overall, access to business people (subject matter experts) for developers is crucial for agile, it is crucial for any requirements elicitation, It does not matter what methods are used if that access is not available,
Agreed, very good point, especially for systems that have specialized users (e.g. ERP systems) vs. consumer apps.
Very much in agreement David. When implementing existing workflows and processes into your system , BPMN diagrams are invaluable. I'm often told that using BPMN/UML is not the 'agile' thing to do, but that's just people wildly mis-interpreting the Agile manifesto IMHO.
I very much agree with this post. In fact I have stopped thinking in terms of user stories and prefer to analyse requirements (including user stories) into their constituent requirement domain entiites (namely stakeholders, goals, capabilities and features). This provides scope, context and traceablity, all of which are lacking when all you have is a stack of user stories. I fully describe this methodology in my book Managing Software Requirements the Agile Way .
Thanks Fred, that sounds like a good approach, will take a look at your book.
thanks Adam, I'd be very interested in your opinion. If you don't mind, I'll have the publisher send you a copy for free.
Wow, Fred, that is very kind of you. You can send it to my office address:
Inflectra, 8121 Georgia Ave, Suite 504, Silver Spring, MD 20910
Regards
Adam