TLDR: I’m using these rules of thumb when writing stories for Agile projects
- Rule 1 - Ask why first
- Rule 2 - Embed context into your stories
- Rule 3 - Who-What-Why not Who-What-What
- Rule 4 - Many Users of many types
- Rule 5 - Your Security Accreditor is not (ever (never ever)) a User
- Rule 6 - It’s a problem, not a solution
How many times have you read the following:
As a User
I want to do the thing
so that I have done the thing.
As the Accreditor
I want to ensure you have done the thing
so hackers can’t do this other thing.
As the team
I want some other team to do this thing
so that our Users can use our thing.
If you work in an Agile team I guarantee you’ve seen those stories. You may even have a set of them on the wall right now.
Over the last few months I’ve spent a lot of time helping run an Agile team. It was my first real, in depth, experience in trying to build a backlog of User Stories for a team. I gained some bad habits, made a lot of mistakes, and learned a lot about writing stories.
So I’ve started using a set of Rules of Thumb in Story Writing workshops to help improve the quality and clarity of the stories we produce. I’m not hard and fast on these rules but they do seem to improve the quality of stories I write.
This stuff is hard. Really hard. So I’m not going to pretend I know what I’m talking about, not even that I did the right thing, but having had some time to think I’ve formed some rules of thumb that I’m starting to use to make my User Stories better. Perhaps they’ll help.
There’s a lot of content here, too much for one post, so I’ll release them in separate posts over the next few weeks.
I might be quite wrong on these. Please call me out on twitter or in the comments if you see something you disagree with, it’s the only way I will get better at this.