The Easy Way to Writing Good User Stories
Filed Under Software Process
Many development shops have opted to writing user stories over traditional feature/requirement documents; however, almost all of them struggle when writing their first batch of user stories. This is not at all uncommon, just like riding a bike, it does take a little bit of practice (but once you get it – you get it).
Writing user stories is dead simple if you follow these simple steps:
1. As a [role], I can [feature] so that [reason]
When writing user stories, using this pattern is a for sure bullseye. Let’s look at an example:
As a account owner, I can check my balance online so that I can keep a daily balance 24 hours a day.
Pretty easy right? However, in some instances I find that the “so that” suffix reads redundantly so go ahead and have that be optional if you wish.
As a account owner, I can check my balance online.
Feel free to use slight deviations of this template using synonyms:
- As a [role], I want [feature] because [reason]
- As a [role], I can [feature]
- As a [role], I can [feature] so that [reason]
2. Use index cards and a Sharpie
When creating new user stories, always hand write your new stories on a single side of a index card using a Sharpie marker. I realize that a majority of shops use issue trackers like Jira; however, doing this physical activity will aid you in creating the correct size of user story.
The theory is simple – if you use any larger than a 3″ x 5″ index card you will write too much. Likewise, if you use anything smaller than a marker (aka ball point pen) – you will write too much.
User stories are suppose to be short and sweet. They are suppose to aid in further communication and not to tell the entire long-winded version of the story. Sticking to these physical constraints will help.
P.S. If you don’t use a tracking system, you can always get some double stick side tape and then stick it on your wall 🙂
3. Make it testable with acceptance stories
If use stories are short and sweet – how are we suppose to know all the different acceptance criteria? Again easy as pie, just write out any of your acceptance tests using this template:
Scenario 1: Title
Given [context]
And [some more context]…
When [event]
Then [outcome]
And [another outcome]…
For example:
Scenario 1: Account balance is negative
Given the account’s balance is below 0
And their is not a scheduled direct deposit that day
When the account owner attempts to withdraw money
Then the bank will deny it
And send the account owner a nasty letter.
Again, one trick I learned to keep my user stories small is to only allow enough scope so that all of my acceptance stories can be written using a ball point pen on the backside of the user story index card. Another physical constraint! (I love these types of hacks btw).
If your user story has more than 3-4 acceptance stories, really analyze the story and see if it makes sense to break it down even further so you can fit all its acceptance tests on the back of the card. Doing so might help you break down those larger stories into more digestible pieces.
4. Connect the dots
Like I have said before, write out all the possible user stories you can currently think of. I guarantee that you will be missing some of the project scope; however with a little luck, you will be able to connect the dots and see the entire project picture.
13 Responses to “The Easy Way to Writing Good User Stories”
[…] The Easy Way to Writing Good User Stories – Max Pool ‘ Many development shops have opted to writing user stories over traditional feature/requirement documents; however, almost all of them struggle when writing their first batch of user stories ‘ […]
[…] The Easy Way to Writing Good User Stories (Max Pool) […]
[…] Pool over at codesqueeze has a great article on how to write a good user story. I’ve seen developers equate a user story with a software requirement before without […]
Nice post max.
This would have come in handy when we first started down the agile path in my old job. After much dinking around, I think we got the story card part down right, but never figured out the formula for user acceptance testing that was as concise and effective as you just described.
Now if I can only get my current employer to get on the Agile bandwagon…sigh…
[…] – bookmarked by 6 members originally found by zaidlearn on 2008-08-25 The Easy Way to Writing Good User Stories http://www.codesqueeze.com/the-easy-way-to-writing-good-user-stories/ – bookmarked by 4 members […]
[…] are conducive to wordiness. One suggestion to mitigate this risk is to write them initially on index cards–presumably if you’ve filled up the card, you know you’ve written enough or too […]
Scrum Development Process…
this page contains references to the Scrum development process About Scrum What is Scrum?…
[…] key aspect of Scrum User Stories is the inclusion of Acceptance Criteria. Acceptance Criteria serve to elaborate or further […]
[…] to happen without having to initially go into too much detail (luckily I found a great reference here. With that Steve and agreed that our first collaboration would be to successfully act out the […]
Traditionally, engineers are not good at writing, and software engineers can only write code (presumably). Writing about user experiences is a good approach but requirements specs are still necessary, along with design documents.
[…] The Easy Way to Writing Good User Stories […]
I don’t think stories should list “features”as this narrows the discussion before designers or developers can try to solve the problem. Stories should talk about capabilities or actions.
Also, if the story is about “want” we don’t understand that they are about user need versus preference.
As a [role], I need [action] because [reason]
As a [role], I can [action]
As a [role], I can [action] so that [reason]
This is what has worked for my teams – my two cents!
s
[…] The Easy Way to Writing Good User Stories […]