Subscribe via RSS

The Easy Way to Writing Good User Stories

Filed Under Software Process

Writing

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.
Index Cards
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.

RSS Icon

  Don't miss a drop! Subscribe now via RSS or email.

Comments

13 Responses to “The Easy Way to Writing Good User Stories”

  1. Arjan`s World » LINKBLOG for August 20, 2008 on August 20th, 2008 3:12 pm

    [...] 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 ‘ [...]

  2. Dew Drop - August 21, 2008 | Alvin Ashcraft's Morning Dew on August 21st, 2008 8:11 am

    [...] The Easy Way to Writing Good User Stories (Max Pool) [...]

  3. Writing User Stories the Easy Way | foojam.com on August 21st, 2008 5:51 pm

    [...] 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 [...]

  4. Russell Ball on August 23rd, 2008 11:02 pm

    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…

  5. Bookmarks about Writing on September 19th, 2008 7:14 pm

    [...] – 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 [...]

  6. User Stories « Peltier On Software on October 25th, 2008 9:12 am

    [...] 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 [...]

  7. Confluence: Development Guidelines on February 13th, 2009 1:20 pm

    Scrum Development Process…

    this page contains references to the Scrum development process About Scrum What is Scrum?…

  8. Agile disciplines in architecture: Test Driven Architecture « The Agile Architect on August 29th, 2010 8:27 pm

    [...] key aspect of Scrum User Stories is the inclusion of Acceptance Criteria.  Acceptance Criteria serve to elaborate or further [...]

  9. User stories? « The Software Configuration Revolution Blog on November 15th, 2010 8:48 am

    [...] 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 [...]

  10. David on November 29th, 2010 7:14 am

    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.

  11. Die besten Ressourcen zu User Stories « Produktmanagement und Vermarktung von Internet-Anwendungen on March 22nd, 2011 3:07 am

    [...] The Easy Way to Writing Good User Stories [...]

  12. susan on April 13th, 2011 4:03 pm

    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

  13. The Best Resources About User Stories « Product Owner for web applications on January 1st, 2012 8:44 am

    [...] The Easy Way to Writing Good User Stories [...]

Max Pool - © 2014 - {codesqueeze}. Sycorr Banking Solutions