How to Turn Requirements into User Stories
Editorial Note: I originally wrote this post for the SmartBear blog.
Let me ask you something. When you read the title of this post, did you envision it laying out some onerous process for converting gigantic Word documents full of requirements into “user stories” in JIRA? If so, I’ll set your mind at ease right now. It’s not that.
Indeed, I am not talking about the mechanics of taking the square peg of “traditional, waterfall-style requirements document” and jamming it into the round hole of some ALM suite’s agile workflow. Instead, I’m talking about the more labor intensive practice of taking a document like that and using it to generate actual, agile-style user stories. There is absolutely a difference, and not even a subtle one. Putting, “1.4.2.3 System shall cause cursor to blink twice after user types A key” into Jira and calling it a “user story” does not make it one.
Anatomy of a User Story
It bears asking, then, “since you say that’s not a user story, what is a user story?” The most common way one sees it defined is via a mad lib. “As a ______ I want to ________ so that _________.” The definer then creates an example, such as, “As a personal banking customer, I want to know my account balance so that I don’t overdraft with my next withdrawal.”
To get a bit more philosophical, the user story has three components: persona, action, and value proposition. The person is the “who” and it typically involves a description of a user or “actor” in the broader context of the system. Some groups will actually define personas, give them names and characteristics, and then use the names, instead. “Dave is a 35 year old stock broker with a checking and savings account, who…” The user story is then, “As Dave, I want to know my account balance so that I don’t overdraft at my next withdrawal.”
The action is the way in which the user interacts with the system. It is not framed in terms of minutiae and sequential, detailed actions. Rather, it is framed in terms of goals that can be accomplished in a sitting. There is a certain amount of art and subjectivity to what is an appropriate goal, but you’ll get the hang of it with practice.
And finally, there is the value proposition of the user story. In my experience, this is the part that is both most frequently omitted and most important. (It is also the part that is hardest to grok for people used to waterfall/contract-style requirements). The value proposition explains why the person in question wants to do the thing in question. And including it is particularly urgent for two reasons.
- If the value proposition is weak or nonexistent, you may deprioritize or eliminate this story altogether.
- If you hit a roadblock during a implementation of the action, you can immediately start thinking of other, more technically feasible ways to achieve the value proposition.
