Users
As its name suggests, a user story describes how a user or customer uses the productāa digital product is capturedĀ from the perspective of the users. This avoids a solution-centric viewĀ where we worry more about how to provide and implement the product features than why and how people will use them.
Understanding who the users are and how the product will benefit them is central to discovering and creating the right stories. In other words, if you do not know who your users are and what problem they want to see addressed or which benefit they would like to experience, then youĀ should not createĀ stories! Otherwise, you are in danger of speculating about the product features rather than deriving themĀ from the user needs.
Iād like to take this further and suggest that you should meet theĀ users. This is not to say that the users will be able to correctly tell you whatĀ the product should doāitās your job to figure this out.Ā I know that product managers and product owners donāt always have access to the users and are sometimes shielded from them by the sales team or management. I also understand that development team members tend to see users even less frequently. But if youĀ want to leverageĀ user stories to develop a successful product, then you should do try to observe and talk toĀ the people who will use it. How else can you truly understand their needs and empathise with them?
Conversation
When I first came across user stories over 15 years ago, I was surprisedĀ by their lack of detail. I was used to working with use cases, and it took me a while toĀ get my head around their sketchiness. They seemed less like requirements and more like notes. And thatās exactly what storiesĀ are meant to beānotes that capture the essence of a conversation.
On its own, a user story is pretty useless. It needs to be complemented withĀ a conversation between the person in charge of the product, the product manager or product owner, and aĀ cross-functional development team.
Maybe itās helpful to take a quick look at the context in which user stories emerged. Stories were first used in Extreme Programming in combination with the role of an onsite customer. The onsite customer isĀ a member of the user community who isĀ collocated with the development team. The individual would discuss withĀ the team what should be built in the next iteration, andĀ captured the conversation asĀ stories toĀ remind everyone of what was discussed.
Agile approachesĀ happily accept tacit knowledge, knowledge that is not explicitly expressed and written down, and they prefer face-to-face conversation over documentation. Why? To speed things up, to allow the team to quickly implement some functionality and to validate it by exposingĀ it to the users.
I find it evenĀ better to co-create user stories by inviting the development team members to help discover new stories and amendments to existing onesābased on the feedback and data gatheredĀ from the users. This leverages the teamās collective knowledge and creativity and tends to result in better, clearer stories. To do so, make collaborative story workĀ part of your product backlog grooming or refinement process.
But if you cannot have at least a meaningful conversation, if product owner and team cannot discuss new stories together so that the team understands the stories and can make suggestions for improving or splitting them, then you should not use user stories. The conversation is not optional; it isĀ an essential part of user stories. Without it, the story is not usable or it becomes bloated with details.Ā If you find that you need to capture more details or hand-off requirements, then use a different approachĀ like use cases instead.
Use cases tend to be more effort to create and update but they offer more structure. They come with pre- and post-conditions, triggers, a main success scenario, alternative success scenarios, and exception scenarios. This allows you to describe the product functionality in more detail, which may be necessary when working with remote teams.
Simplicity
User stories are a very simple toolāwe simply tell stories about how users are likely to interact with the product and capture their essence. Thatās it. Unfortunately, I have seen a fair amount of stories that were far from simple and straightforward.
I find it helpfulĀ to remember that in theĀ early days of agile, people didnāt talk so much about user stories. Instead, they used the term story cards. The reason for this is simple: stories were captured on paper cards. These have two advantages: they facilitate collaboration and visualisation. Everybody can write on a piece of paper, and the cards can be easily arranged on theĀ table or office wall. Electronic tools are less conducive to teamworkĀ in my experience; one person is usually in control of the keyboard and tool. Whatās more, itās much harder toĀ display the stories and prevent them from being hidden away. I would therefore encourage you to experiment with paper cards to capture your storiesāat least when you create new stories. You can key them into your favourite electronic tool afterwards if you wish. But be warned: Iāve seen teams who decided after some experimentation to switch from electronic to paper-based stories.
Another area that can benefit from simplificationĀ are the acceptance criteria. As their name says, the criteria want to communicate what needs to be in place so that the story can be considered as done and the corresponding functionality can be exposed to a user or customer. Acceptance criteria should be no big deal but follow naturally from the narrative by asking, āhow can we tell the story is done?ā If you make the criteria more complicated, the storiesĀ become harder to understand and start to slow youĀ down.
Limits
User stories are great at capturing product functionality, things people can do with a digital product like searching, evaluating, and purchasingĀ products online. You can also use stories to capture non-functional aspects of a product, such as performance, robustness, and interoperability.
But when it comes to the user interface and user interaction, user stories are less suitable. Sketches and mock-ups are better at describingĀ the UI design. And scenarios, workflow diagrams, storyboards, and story maps are better suited to capture user interactions that comprise several steps.
Additionally, writing user stories is worthwhile when you develop software thatās likely to be reused. But if you want to quickly create a throwaway prototype or mock-up to validate an idea, then writing stories may not be necessary. Remember: User stories are not about documenting requirements; they want to enable you to move fast and develop software as quickly as possibleānot to impose any overhead.
User stories should therefore be one of the tools in your product tool box, not the only one.
| Reference: | User Story Reflections from our JCG partner Roman Pichler at the Pichler’s blog blog. |
