The topic of writing user stories has come up so frequently that I felt a burning need to write something on the subject.
I’ve seen posts on newsgroups and I’ve received questions from clients about the “correct” writing of user stories. Do we use “Shall” or “Will” or “Must?” Do we start with “As a <type of user>?” or should we start with “In order to <achieve some value>?”
In short, these people want to know how to write user stories effectively, which is a valid question. However, usually with some probing what I uncover is that they’re expecting to use the written user story to communicate the need, which is not a recommended practice. The written user story exists mainly for prioritization, agile estimation, and for tracking and communicating progress. It should not be the primary vehicle used to communicate what is needed. As long as the people involved know more or less what it represents, the user story can be recorded any way you want. You could simply write “That whatchamacallit thingy that Jane asked for at the customer conference” as long as everyone on the team knows that it’s referencing.
It’s important to remember the famous 3 Cs of a user story: Card, Conversation and Confirmation.
- The card is the thing you use to track the status of the user story. Using a card, rather than a spreadsheet or word processing tool, is also useful because its size limits the amount you can write.
- Conversation, which should be plural in my mind, because you’re going to have many conversations about the user story. You’re going to have an initial conversation when it’s created, more conversations when you estimate it, prioritize it and break it into smaller stories or tasks, and then even more conversations in the sprint planning meeting, the sprint review meeting, and throughout the sprint as you’re satisfying it. However, the detail of these conversations are not recorded on the card.
- Confirmation is the acceptance of user story as complete, based on the acceptance criteria and on the feedback you’ve received throughout the process.
In traditional development, the requirement statement, (combined with use cases, diagrams, screen flows and other artefacts) was often used to communicate to the development team what needs to be created. In this case, the form of the statement needed to be consistent, unambiguous, clear and concise, because it was a specification. It was assumed that developers would be working from the document and only the document.
If you’re using an Agile development approach, the most important part of the user story is the second C – the conversations that will happen to understand the need. The card doesn’t describe the need. The user story is an item on the meeting agenda. It’s not a specification. That’s not to say that it can’t be supplemented with use cases, diagrams, mock ups and so on. I do recommend that you postpone that detail as long as possible, but I’ll talk about that in a future post.
That said, Michael Cohn and other Agile experts have recommended certain forms for user stories. These forms are not important in order to better communicate to development what they need to build. The form or structure is intended to get the requestor to think about and discuss the value to be delivered to the customer, by placing either the value or the customer in the first part of the user story. Too many development groups write requirements or user stories like “Rebuild database indices” or “Upgrade web server” or “reduce bandwidth of the transactions to improve speed by 20%” when they should be writing “As a User on a mobile device I want to be able to process my transaction in less than 5 seconds” or “In order to better target our products, as a financial manager I want to be able to view all of my clients transactions over the last 6 months.”
Your organization’s adoption of Agile is going to influence how you use user stories and therefore how you write them. I’ll discuss some of these challenges in a future post. The main message here is that writing the user story is not what you should be focused on.