I have earlier written a post about writing use cases for agile (Scrum) projects, this is a follow up about writing user stories. Do you find it strange that I first wrote about use cases and later are writing about user stories? Well… to be honest with you we started with writing use cases and then later found that this was insufficient and we needed to break the use cases down to short user stories (post-it format).
By doing so you are able to focus on exactly what the user need/want without going into details on how this should be done. We came up with the following template for user stories (I’m saying we because I did this together with a colleague of mine. You can read his blog at www.agilemobility.net).
Actor: The owner of the user story (often a user). It’s very easy to end up using the name user for the actor but I would recommend to be more specific. By using specific actors it’s easier to understand and set the user story in context with the system.
Action: What the actor want to do. You can also differ between mandatory actions and optional actions. This can be done by using the want or must keywords before the action.
Achievement: What the actor wants to achieve by performing the action. This is the result from executing the action seen from the actors point of view.
The simple example above shows a short user story on post-it note format, but still it’s quite effective and gives you all the info you need to specify and break this down into a more detailed use case. We found that sometimes it’s nice to be able to make sub user stories and order them in a hierarchical way. This can easily be do by using MS Word and headings.
The example above shows that you now have a unique ID and a name for each user story. You also have the top level user story and the following sub user stories. I think this is a great way to organize the user stories. Writing good and consise user stories can be hard and it takes some time, but by doing this in the start of your project you will identify all the needed functionality. In agile project changes are welcome, but if you are in a customer project this will help you documenting that the new changes are not a part of the original estimated user stories and must be re-estimated.
Good user stories can also be used for writing test documentation and user documentation. The next step now is to see how to use the user stories for both UI design/interaction design and system specification, but that’s a whole other story.
Update: I have revisted this subject and written a follow up post: Writing user stories for agile (Scrum) projects – revisited