User stories generally follow the following template:
“As a <role>, I want <goal/desire> so that <benefit>”
but the shorter version is commonly used as well:
“As a <role>, I want <goal/desire>”
I was truly shocked that they introduce the “shorter version” without a word of caution. In my opinion the “so that”-part is the most important part of the whole user story! Without it a user story is little more than work instructions.
- A user story is an invitation to talk and the “so that” is the conversation starter
- Knowing the underlying goal of a task keeps the solution space open
- Helps make the right decisions in tradeoffs: an instruction like “display figures” has very different helpful solutions for realtime tracking vs. hindsight analysis
“[…] avoid unnecessary work by forcing the user/customer to supply a solid, tangible business benefit as a reason for the existence of this feature.
It is not unheard of that features get added just because someone thought they sounded cool, or because other software has it, so ours must have it, too. More often than not, those are at least completely unneccessary, if not actively harmful.
However, it is usually easy to spot those features, because the people proposing them generally will have trouble supplying a convincing business reason for them.”
(Jörg W. Mittag on programmers.stackexchange.com)
I’d like to add a warning to the Wikipedia articles – the English entry as well as its German counterpart – but I need to back up my personal opinion with something more authorative, i.e. a linkable reference. Can you think of something? Then comment or improve the articles directly! They’re both in dire need of some love. Not even the 3Cs are mentioned…
Share this article: