More about writing user stories

In this project we've decided that I, as Interaction Designer, should write the user stories. I've worked in projects where we've used stories for planning our work before, but then we've mostly focused on the size and the independency of the stories. We've also prioritized functions before writing the stories, and writing them have been done by the whole team as a part of the planning activity.

This time we've been writing stories with the mindset to make them, Independent, Negotiable, Valuable, Estimatable, Small and Testable. We've learned these rules from Bill Wake.

An Interaction Designer should be aware of the user value in everything they do, and I find it useful to formulate the user stories so that they express how every part of our project is of value either to the end user or to the customer. In this way everyone in the team will be reminded of why a function should be developed and it will also be a good help to prioritize the stories later.

The writing of user stories in this project has been much about documenting a prototype that we've created in the pre-study. This work has been good because we've once again been forced to challenge everything we've decided to develop with the question "Why would the end user like to have/do this?"

To me the most difficult part of writing the user stories have been to make them independent. We have a step-by-step flow where the user first signs in, then fills in a form, and at last submits the information. Having a story including filling in a form while excluding the submitting part is not an independent story, but including the submitting part may make the story to big. Instead we’ve tried to split that story into several stories where some is about functions that make it possible to fill in the form (e.g. listing and manipulating information), and another one is about actually filling in the information and submitting it.

It has also been hard to make the stories both small and negotiable. Adding too much detail is easy, especially since we already know a lot about details from the pre-study.

Writing stories alone is hard. After a while you come to the point when you do not question your own writings, if you’ve once thought that a story seems to be, for example, negotiable it is difficult to reconsider it without a second persons view of it. Therefore I’ve had a great help from the developers and the Test Manager in my team. Discussing the stories has lead to new, deleted and rewritten stories.

The next step will be to take the user story draft to discuss with our customer!

To learn more about writing user stories I’ve been reading:

• The first three chapters in User stories applied by Mike Cohn. I think I learned the most from this reading, I appreciate that it has several describing examples.
• Advantages of the “As a user, I want” user story template from Mike Cohn’ s blog
• User stories at extremeprogramming.org
• User stories at Wikipedia
• A chapter about User stories in Extreme programming explained by Kent Beck. I found this reading quite brief (probably because I read it after all the other reading), but it may be good to get a first idea of what this is about.