The Easy Way to Writing Good User StoriesFiled 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
And [some more context]…
And [another outcome]…
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.