The vocabulary of your user stories frames the domain of discourse: what are your stories about?
It’s helpful to think of “the headline” and “the rest”. “The headline” is what you’d write on an index card or as a title in an electronic system – a few words summarizing the story. “The rest” is other things you might include – bullet points expanding on the approach, test ideas, or other notes.
We’ll focus our analysis on the headline.
Vocabulary – The Role
Who is your story about? The best stories are about people (or other systems) interacting with your system.
Some common users:
“The User” – Some systems only have one user, or one type of user.
A Role – One of a set of “hats” that people may have. For example, a medical system might have the roles Doctor, Patient, and Nurse. The same person might act in more than one role; even a Doctor is sometimes a Patient.
A Differentiated Role – Beyond the basic roles, you may add adjectives: First-time Patient, Distracted Emergency-room X-ray Technician.
“The System” – Sometimes, it’s easier to refer to the system you’re creating as an agent. For example, we might speak of “the system” generating a scheduled report.
Another System – Some systems act as users of other systems. (Not all systems are used directly by humans!)
Roles on Your (Development) Team – Developer, tester, product owner, etc.
[None] – Some teams don’t mention the user or role in their stories.
Vocabulary – The Action
What action or behavior is your headline about? Several domains are common:
1. Problem Domain: Words typically used by people with the problem that your system addresses (regardless of whether they use your system or any other).
You’ll have to make a judgement about what the domain is, as there is flexibility in framing the level of the problem:
- Am I trying to read a book?
- Am I buying an item?
- Am I entertaining or teaching myself?
Each frames this as a different problem.
2. Your Solution Domain: Words unique to the solution you’re delivering, reflecting the mindset, terms, and metaphors that users of your system see.
For example, your stories may talk about a shopping cart or a profile. These are are not inherent in the idea of online shopping, but may be conceptual parts of your solution domain.
3. Implementation Domain (Widgets): Some stories are written at the level of widgets and screens. For example, “the blue button”, “the bullet list”, “the settings dialog”.
4. Your Process: Activities your team does, such as having meetings, refactoring, or testing; or artifacts your team produces (such as code or test plans).
Analysis
- Is there a pattern? What types of roles or action domains do you most often focus on?
- Is it clear why these words are used? Are actions clear about the outcome that the user would hope for? Actions that are in the solution domain, or even worse the implementation domain, can be hard for the user to value.
- Do the stories focus on the development team’s roles, actions, or processes? This is not a good sign. It suggests the team is focused internally rather than on the user’s goals, or that the team’s “user” stories are really development tasks. When stories are actually tasks, they are incomplete, not able to traded off as independent capabilities.
- Do you lean on “The User” or implicit roles too much? Some systems only have one role, but in other cases other roles have been forgotten about.
- Do the verbs represent discrete actions (not continuous processes like “monitor”)? Do the verbs represent real-world action, not mental states?
Unsolicited Advice
The most important thing is that stories work effectively within your team. If people remember what they’re talking about with a particular headline, that’s great. That said…
For roles, I only default to “The User” if there really is only one role, or if I’m talking about something that applies to all users of the system. Naming the real roles can help suggest when roles are missing. For example, I’ve seen teams fail to consider operations as a user of the system, or the managers who need reports on the global system flow.
For domains, I like to stay in the problem domain where it makes sense, using words that apply to any solution that we would create. This allows more scope for creative solutions. That said, it’s fine to have stories in the solution domain (and I find it common as a system grows).
When roles or actions are focused solely on the development team, I worry – teams working this way are creating silos within the team, defining stories that are incomplete. Sometimes this is to get “velocity credit” – ugh. Such “stories” make it hard for the team to understand what’s going on from the user perspective.
Conclusion
Terms aren’t everything, but I believe they subtly shape how we conceive of the problem and the solution we’re creating. Consider this for the next stories you write!