Off topic, but damn hilarious – Happy Friday.

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.

Even good teams are susceptible to degrading into undesciplined cowboy coders – and it all starts with a single broken window.

What I mean by a “single broken window” is in reference to the Broken Window Synodrome which states:

If a window in a building is broken and left unrepaired all the rest of the windows will soon be broken. . . . One unrepaired window is a signal that no one cares, so breaking more windows costs nothing. . . . Untended property becomes fair game for people out for fun or plunder.

If disorder goes unchecked, a vicious cycle begins. First, it kindles a fear of crime among residents, who respond by staying behind locked doors. Their involvement in the neighborhood declines…they cease to exercise social regulation over little things like litter on the street, loitering strangers, or truant schoolchildren. When law-abiding eyes stop watching the streets, the social order breaks down and criminals move in.

Understanding that such a vicious cycle exists is important in creating a higher level of discipline and ownership in your current projects. Teams who are not vigilant about immediately fixing broken unit tests or builds, are in a sense, creating a downward spiral within the project. Team members who witness a single blatant act of project vandalism will undoubtedly give into the lazy human nature and retaliate with the common quote, “Well if he isn’t going to do that, than neither am I…”. The sprial begins…

You can never execute and deliver like a disciplined team if you are not disciplined enough to immediately fix the glaring problems. Don’t live with broken windows as having the will power to keep your house in order is the easiest win in the disciplined team game. If you allow your windows to stay broken you may just lose the house and neighborhood.