There is more to User Stories than filling out a form. The "as a <user>, I want <something> so that I can <some benefit>" template is intentionally inadequate to capture details. Why is that? The general answer is that the details emerge from a conversation with the actual user. You may have heard the statement that User Stories are not about documentation; they are about conversation. This is true, but the conversation is more than just a further elicitation of detail.

User Stories are about possibilities!

How often have you delivered exactly what the customer asked for, only to have them discover when they attempt to use it, that it doesn't actually do what they need? User Stories are designed to avoid this outcome.

A basic tenet of Agile is that we are operating in an environment where there are unknowns. Therefore, thinking that what the customer states in the initial version of the User Story is the right fit for their need is bound to be wrong. The initial version of the story is necessarily the least informed version of the story because it is written when the least is known about the actual need. The initial version of the User Story is just a starting point. The User Story technique helps us explore the possibilities.

To support the idea of the initial version being the starting point, the <something> in the User Story template should be expressed as a need rather than a solution. For example, if I have shaky hands and I want to take a non-blurry picture with my camera, I might say "As a photographer, I want my photos to be sharp so that viewers can make out the detail". The lack of a solution in this User Story encourages further exploration: What is “sharp”? Why are the current pictures not sharp? Who is the “viewer”? Why is “detail” desired? and so on. If the solution is already included in the User Story, for example, a tripod, further exploration might be seen as unnecessary. Let's just get to work on that tripod! While a tripod is a potential solution to steady a camera, we don't know if a tripod is a practical solution without further conversation. So hold off on a solution until more is known.

At the beginning of a discussion about a User Story, everyone is likely to have a different perception of the need and different ideas for potential solutions. This variety of opinions is both expected and desired. It is expected because at the beginning of the conversation, we are ignorant. It is desired because we wish to surface the possibilities and reveal that ignorance.

Divergent thinking is an essential part of the discovery process. As long as we are diverging, we know that we are not on the same page as to need or solution. Through a creative, collaborative conversation we begin to converge on a shared understanding of the real user need. Only when we’ve converged on a shared understanding of need, should we start a second cycle of divergent to convergent thinking on potential solutions.

Generally, in relatively short order we arrive at the User Story to be worked and delivered. And once the “done” User Story is in use, chances are there will be requests for a new, improved version. And so the cycle of possibilities, divergence and convergence continues. And that is what User Stories are good for!