User Stories as the Haiku of Business Analysis
Well written user stories are much like haiku — they are easy to read and comprehend, and therefore, sometimes seem easy to create. However, just as not every phrase looking like haiku is a poetry, not every requirement is useful when presented as a user story.
The similarity is even deeper when we compare the inner structure of the two forms. Let’s take this haiku from the 17th century, by Matsuo Basho:
We can see that this haiku leads to insight by opposition of the thesis and antithesis. Another optional yet common element is the reference to a season, not necessarily literal. Now look at the user story:
User story is a brief, comprehensive statement of function or quality that brings value to the actor in a certain context. Like haiku, it has three elements:
- Who (actor): role or persona in a context.
- What: required action, behavior, property, and/or quality.
- Why: value to the actor.
You may also note that like haiku can mention a season, a user story can provide some reference to a context for its actor.
A user story is the analyst’s presentation of a requirement to the team from the stakeholder’s point of view. Like any representation, it comes with some pros and cons.
Pros of user stories
Written quickly — due to the comprehensive format, user stories can be created quickly to cognize and shape your stakeholders’ needs. This ease is often delusional, especially to managers who never actually write user stories but expect others to do this at pace.
Focus on value — user story is the analyst’s best opportunity to explain why the requirement is important, so use it and do not ignore the value part.
Understood by all stakeholders — compared to other requirement formats, such as use cases or diagrams, user stories are closer to the natural language, so they do not require any special preparation of their readers.
A unit of planning, tracing and acceptance — thanks to the ease of understanding, communication between all stakeholders smoothly builds around the user stories at all stages of implementation. This is what managers love about the user stories so much that they commonly see user stories as tickets and may demand your entire requirements covered with user stories. And now we are going into the cons.
Cons of user stories
Need to understand the context — a single user story is often too fragmental, and your other stories are too numerous so that stakeholders may need your assistance to see the forest for the trees and understand how many stories link together to build up a value for multiple actors.
Do not describe solution in detail — while this is actually a great thing about a user story that it gives freedom of solution to your team, some inexperienced readers may expect a detailed solution right in the story, and inexperienced analysts may tempt to include these details in it. Keep your designs close to the user stories, trace them to each other, but don’t mix them. Doing so will facilitate other people’s work on designs, be they UX designers, architects, engineers, or system analysts. The separation of solution details also makes user stories an inconvenient starting point for solution knowledge transfer.
Require acceptance criteria — user story is a statement of need, not itself an agreement of when to consider it done. While the acceptance criteria are shaped by the story, they are a separate form of requirements, so don’t hesitate to use appropriate formats: checklists, Gherkin scenarios, use case scenarios.
Stories do not read themself — user story is not a form to preserve a requirement for a future reader, rather it is an invitation to discuss it now with everyone involved and agree on acceptance criteria and design. Communicate your stories proactively.
Problems with user stories
For a business analyst, the sign of a problematic user story is when it doesn’t start a productive discussion and you find yourself discussing some other things instead. The problem can be structural to the story:
- Who: unspecific or proxy actor like a ‘customer’, ‘user’, ‘product owner’. Specify your actor before you write a story of them. Keep actor definition separate from the user stories, like in your glossary or personas, and reuse it.
- What: path instead of goal, elements of solution or UI design. Are you going to constrain your team’s thinking or enhance it?
- Why: skipped or repeating actor’s goal. A user story with no clear value is not worth discussing.
Another kind of problem can be with how you treat user stories, not how you write them:
Create but not discuss — a good haiku can wait for its audience, but it’s too optimistic to wait for others to discuss your user stories proactively. It’s like you invite but don’t attend. The story should be not only discussed — it should be discussed right before the implementation, or a changing context may invalidate it.
Use for any possible requirements — people do not speak haiku; they create haiku for a specific purpose. The hint is in the technique name, user stories work best for the requirements of stakeholders directly interacting with the solution. If your other stakeholders demand all requirements to be a ‘story’ type tickets, at least you shouldn’t be bound by the who–what–why story format. Have courage to choose useful representations for their needs. Labored ‘stories’ do not facilitate discussion of requirements.
Skip acceptance criteria — if you do not agree with the actor on the conditions when the story is considered done, you will end up discussing it on the solution review. This late discussion will be under pressure and may bring many surprises to everyone involved.
No trace to business requirements — haiku exists for the sake of beauty, but a user story must relate to business requirements to exist. The value to an actor and importance of that actor’s values can be questioned along with the changing context. Be ready to explain how every story is adding to the bigger picture.
Importance of context
Just as haiku portrays some moment in time, a user story captures an actor in their moment of need. Function or quality is not equally valuable to an actor any time, rather in a specific situation, in context. You can explain the user story in context by tracing it to the higher-level requirements, process model, or user journey with the story mapping technique.
Epic can be instrumental in setting the context by grouping user stories aligned in the value creation chain. Combine stories in epic according to the story mapping to describe certain actors’ journey towards their goal. Use epic description for common acceptance criteria.
INVEST quality criteria
Checking your user stories against these criteria helps to identify problematic stories and understand where to improve them. A good user story is:
Independent — from other user stories.
Negotiable — implementation is not prescribed but left for discussion.
Valuable — brings value to actor.
Estimable — the team can loosely estimate the effort required to deliver.
Small — enough to be implemented in one sprint by your team.
Testable — acceptance criteria can be verified by an independent tester.
You may read this article about INVEST criteria to understand them deeper.
Think first, then write your stories
I use this activity list as I write user stories:
- Define actors or personas — who uses the solution?
- Start with epics — what are the actors’ goals? How do they move towards their goals? How do they measure if their goals are achieved?
- Split each epic into activities — you have the stories identified.
- Keep together all stories of one epic as you write them.
- Trace up to business requirements. Prepare to explain why each story is written.
- Trace connections — how user stories align in the user journey?
- Check written stories for problems using INVEST criteria.
Do not overwork your user stories, rather look to cover the epic and communicate to get feedback. With quick feedback, you can improve your stories faster and effectively.
Communicate your user stories
Communicate user stories one epic at time as soon as its stories are written.
Who is involved?
- Start with another business analyst, if available, for peer review.
- Proceed with your team and stakeholders. Developers better contribute to and benefit from user stories discussion together with stakeholders representing the story actors.
Schedule a workshop (call it backlog grooming or feature review) and start with the context:
- Remind actor definitions.
- Show epic among other epics, in the process model if you have it.
- Show story map or user journey.
As you proceed to show and explain the stories:
- Display stories of one epic together in a list, don’t open them one by one. Maintain view of the bigger picture.
- Ask your stakeholders for the acceptance criteria, for if you rush with your own suggestions, you can block their thinking.
- Not all user stories are equally important. Propose to discuss story priorities.
When done, secure all feedback in meeting minutes which you can use as the source of newly identified requirements and to-do list for your story’s updates.
In conclusion, user stories are a powerful tool for presentation and discussion of requirements, especially when you put extra effort to deliver them in context, traced up to business requirements and backed with acceptance criteria. Be mindful of user stories limitations when applied to solution requirements and documentation, especially when the stakeholders’ expectation is to manage your entire requirements as ‘stories’. Don’t let usefulness of your requirements be affected by a ubiquitous user story format.
