user stories

There is a universe somewhere in which my blog is always on topic, I have a theme and I always produce posts which accord with that theme. However, in this universe my mind flits around and, for better or worse, this blog carries what is on my mind at the time. Sometimes that is grand strategy, sometimes hands-on-detail, sometimes the nature of digital work and sometimes frustration.

This week I’m dusting off my slides for next months User Stories workshop so I thought I’d share my User Stories 10 rules of thumb:

1 – Stories are usually written about a hands on user, someone who actually puts their hands on the keyboard

2 – If your story begins “As a user” then save the ink and delete the words, “as a user” adds nothing. “As a customer” isn’t a lot better. In both cases think harder, come up with a better “user”. Be as specific as you can.

3 – Stories which have systems in the user role should be rethought (“As Order Entry System I want the E-Mail System to send e-mail so that I can notify the humans”). Step back and think “Who benefits from System-E and System-F working together?” then rework the story with that person in mind seeing a combined system (e.g. “As a Branch Manager I want e-mail notifications sent when an order is entered.”)

4- Stories should be big enough to deliver business value but small enough to be complete in the near future, I’m prepared to accept a maximum of 2 weeks but others would challenge that and say “2 days is the max.” (Small and valuable actually constitute my 2 Golden Rules, where I also discuss Epics and Tasks.)

5 – There is no universal right size for a story. Teams differ widely in terms of the best (most efficient, most understandable, quickest to deliver, biggest bang for your buck…)

6 – In general the greater the gap (physical distance, cultural norms, history working in the domain, employment status, education level, etc. etc.) between the story writer (e.g. BA) and receiver (e.g. Tester or Coder) the more detail will be expected by one side or the other.

7 – If the User Story format “As a … I want to … So that …” isn’t readable then write something that it. Who, What and Why are really useful to know and he standard format usually works well but if it doesn’t write something that is. There are no prizes for “the perfect story.”

8 – Beware stories about team members: a story which begins “As a Tester I …” or “As a Product Owner …” are red flags and should be questioned. Unless you are actually building something for people like yourselves (e.g. a programming team writing an IDE) then stories should be able end users and customers. Very very occasionally it can make sense to write something for the team themselves (e.g. “As a Tester I want a log of all database action so I can validate changes”) but before you accept them question them.

9 – Stories should be testable: if you can’t see how the story can be tested think again. If you are asked to complete a story which you can’t test then simply mark it as done. If it can’t be tested then nobody can prove you haven’t done it. However, in most cases someone will soon report it as not working and you will know how to test it.

10 – Remember the old adage “Stories are a placeholder for a conversation” ? Well, if you have the conversation all sins are forgiven. No matter what the flaws are if you have the conversation you can address them.

Needless to say more about these topics in Little Book of Requirements and User Stories.

Now just because I go around saying radical things like “Nuke the backlog” does not mean I want to ditch the wonderful who-what-why structure of user stories. You might throw away a lot of user stories but when thinking about the work to be done in the post-nuclear supersprint then by all means: write user stories.