User stories are great. When used effectively, they help turn the dauntingly complicated task of software development into a manageable and intelligent workflow. User stories are a powerful and important tool that developers depend on to foster better collaboration with their teams and to ensure that the final product meets real business needs.
But they’re not enough. User stories enable the success of Agile development by segmenting the process into precise units of development, but they don’t provide the overall coherence that projects sorely need to stay on track.
Three primary attributes of user stories—their small size, their independence from each other, and their open-endedness—create a need for a mechanism that ties the individual statements into a big picture.
First, a quick word on user stories and how they work. User stories are constructed in a very particular way. Each one is a small narrative in three parts: the who, the what, and the why.
The “who”, or persona, identifies a user according to their role , whether that person is a customer, a product manager, an executive, or anyone else who engages with the software. The “what” states the action that the user will take. The “why” describes the outcome of that action, in terms of the benefit the user obtains from it.
Here’s the classic formulation of a user story, which is most commonly associated with Mike Cohn, one of the inventors of the Scrum development methodology and a key proponent of Agile practices:
As a (role) I want (something) so that (benefit).
But as the product designer Alan Klement writes, the first two parts of this sequence often outweigh the rationale of the user story itself, resulting in a critical loss of context. “Often, because people are so focused on the who and how, they totally miss the why. When you start to understand the why, your mind is then open to think of creative and original ways to solve the problem.”
User stories are built for maximum efficiency and heightened collaboration, but achieving those outcomes means segmenting the work into distinct units, which can obscure their interconnectedness. For user stories to work, they need to possess three attributes:
- Small size: User stories need to be small enough that scrum teams—the small groups of people that collaborate closely to accomplish specific tasks on a development project—can finish them quickly, often within a few days. User stories that are too large or vague defeat the purpose of working in Agile.
- Independence: User stories are usually designed to be independent of each other, because team members want to be able to develop them in any sequence, which promotes efficiency.
- Flexibility: Because Agile emphasizes collaboration so strongly, user stories are meant to facilitate problem-solving, not answer every question ahead of time. User stories shouldn’t be over-determined, because developers want to be able to negotiate how their implemented.
Segmenting user stories according to these three principles is a very useful strategy, but the narrow focus also makes it harder for scrum teams to understand how all the stories come together. After all, the user doesn’t interact with the product as a collection of separate elements or as a sequence of actions, but as an integrated experience.
Writing broadly about this issue, Klement says, “It’s still too rare to witness a designer talk about how their work maps to a mission, drives a vision forward, or how it is placed within product architecture, with the weight that these things deserve. This should be the norm, not the exception.”
With the right tools, developers can continue to employ user stories as they were intended—to express business value as efficiently as possible using dynamic collaboration—while keeping the broader context constantly in focus.
Of course, one tool that most Agile developers already employ is the epic, which is essentially a bigger user story that can be broken down into multiple smaller ones. To use the puzzle analogy, if each piece is a user story, the epics are the larger groupings: the sky, the field, the sea, and the house on the hill. (In Scrum methodology, an epic takes longer than single sprint, or work cycle, to complete.)
But epics only give context for individual user stories. To accurately express the conditions and relations of all the components of a project, developers also need visualization tools, such as business process flows and site maps, as well as tools to express standardized elements. For example, user stories capture functional requirements, but they don’t readily express non-functional requirements—security, compliance, certification, response time, and so on.
Agile developers don’t need to sacrifice comprehensive, multi-level articulation of project goals and execution in order to foster dynamic collaboration. To see how all the different elements map together on a single platform. To learn more about how Blueprint can help you with your user stories, please contact us today.
