User stories are a popular technique to organize software development. While many use them to record future work, they’re much more valuable as a means to enable effective communication. By using the As A, I Want, So That format, we capture three important things: who, what and why. The latter is what matters most. We can alter who and what, but if we don’t know why we’re doing something, we’re simply taking marching orders. We have no ability to adapt to what we learn and alter what we do to ensure success. We can only carry out the desired task.
It’s no surprise many see “so that” as optional. Surveying examples of user stories online, I’ve found “so that” is typically a restatement of what, not why:
As a user I want a green button So that I can push the green button.
Of course this type of conversation is contrived and a waste of time. If however, we talk about why:
As a user I want a green button So that I can easily contact support for help.
Then we can ask ourselves things like, is a green button the best way for someone to easily contact support for help? Perhaps red would stand out more? Is that the problem, is the support button hard to find? Perhaps we could change the text of the button. What does it read now? What problems are people frequently reporting? Can we do something to minimize common problems so users don’t have to contact support?