Summary
User stories are a powerful agile technique to describe requirements from the perspective of the customers and users. Unfortunately, I find it not uncommon that user stories fail are not applied successfully and fail. This post describes two common failure causes and discusses how you can avoid them.
Wrong Context
As their name suggests, user stories tell a story: They describe in plain language how a customer or user employs the product. Instead of specifying every little detail, user stories offer an informal way to capture the requirements. This works, if the stories are complemented with a conversation that takes place between the product manager/product owner and the development team. In this conversation, the product person tells the story to the team; the team members ask questions and suggest adjustments. Ideally, the conversation takes place face-to-face with everyone being in the same room. The benefits of this informal and collaborative approach are twofold: It leads to better requirements and it saves time by shifting from written requirements to tacit knowledge.
Unfortunately, I see organisations apply user stories even if an effective conversation is very hard to achieve. Instead of discussing and refining the stories together, they are handed off to the development team. Often, the team is remote and has limited knowledge about the market and the product. To account for the missing conversation, the product manager or owner tries to write elaborate, detail-rich, and precise stories. This turns user stories into something they were not designed to be: formal requirements.
If you find yourself in a similar situation, then you have two choices: Make sure that an effective conversation does take place, for instance, by having regular onsite workshops or using videoconferences to discuss and adjust the stories with the development team. Alternatively use a different requirements description technique, such as use cases. Use cases offer more structure and make it easier to precisely describe a requirement, for instance, by using pre conditions and exception scenarios.
Wrong Job
User stories describe end user requirements. They were not designed to capture technical requirements. You can, of course, tell stories about how a product is built and use technical stories. But I find that natural language is not well suited to capture technical requirements and I prefer to work with a modelling language like UML (Unified Modeling Language). Why bother describing an interface or API in natural language when you can model and visualise it using a UML artefact?
If you find that your teams heavily rely on technical requirements, then this may indicate that you work with component teams – teams that are organised around architecture building blocks, such as components, services, and layers. An effective way to reduce the need for technical requirements is to reorganise the teams by forming feature teams – teams that implement user stories end-to-end in form of a vertical slice.
But it’s not only technical requirements that should not be captured as user stories. Complex user interactions, such as workflows and scenarios, and user interface requirements are also difficult to describe as a user story. Take, for instance, an online shop that requires the users to discover a product, select it and place it in the basket, and to pay for it. If you attempted to describe these steps with one story, you would either end up either with a big compound story or you would use the acceptance criteria to describe the workflow. Neither is desirable in my mind. A better solution is to use stories to describe discrete functional requirements and to complement them with other techniques, such as story maps, scenarios, workflow diagrams, and storyboards. I discuss this approach in more detail in my post User Stories are Not Enough to Create a Great User Experience.
| Reference: | Why User Stories Fail from our JCG partner Roman Pichler at the Pichler’s blog blog. |
