Writing user stories is a foundational element of XP. It has also been successfully used with other agile processes, most notably Scrum. User stories shift focus from written requirements documents to conversations between customers and developers. Because of this, it is important that we get as much as we can from these conversations, which means that the questions we ask—and how we ask them—are vitally important. It is never sufficient to ask the user “So, what do you need?” Most users are not very adept at understanding, and especially at expressing, their true needs. I learned this once from a user who walked into my office and acknowledged, “You built exactly what I asked for but it’s not what I want.”
Another time, I worked with a team that was developing software for delivering surveys. Each survey would be delivered over the phone, via email, and via interactive voice response. Different types of users would use different survey types. The surveys were very complicated: specific answers to one set of questions would determine which question would be asked next. For example, based on answers to body height and body weight questions, the system would calculate the respondent’s Body Mass Index (BMI) and then invoke a page based on whether the respondent was overweight.
“Having a problem does not qualify you to solve it.”
The users needed a way to create the surveys. When the users first told the developers about their need, they presented us with examples of a complicated mini-language. They proposed typing surveys in this new language. This entirely text-based approach seemed needlessly complicated to us. We asked the users a few questions about how they’d use the new system and it became clear that a drag-and-drop survey-building GUI would be better for them than their proposed new language.
Having a problem does not qualify you to solve it. In this case, the users who had the problem were proposing a solution that was needlessly difficult. It took the developers carefully questioning the users to pull out their true needs which led them to writing user stories that were more beneficial in creating the end product.
The best technique for getting to the essence of a user’s needs is through the questions you ask. I worked with a project team that was torn between putting their application in a browser or writing it as a more traditional platform-specific program. They struggled between the ease-of-deployment and lower training costs provided by the browser-based version and the more powerful platform-specific client. The intended users would certainly like the advantages of the browser, but they also valued the richer user experience provided by the platform-specific client.
It was suggested that the target users for the product be asked their preference. Since the product would be a new generation rewrite of a legacy product, the marketing group agreed to contact a representative sample of current users. Each user in the survey was asked “Would you like our new application in a browser?”
This question was like going to your favorite restaurant and having the waiter ask if you’d like to have your meal for free. Of course, you would! And of course the surveyed users responded that they would love to have the new version of the software in a browser.
The mistake the marketing group made was that they asked a closed-ended question and failed to provide sufficient detail for it to be answered. The question assumed that anyone being interviewed would know the tradeoffs between the browser and the unstated alternatives. A better version of the question would have been:
Would you like our new application in a browser rather than as a native Windows application even if it means reduced performance, a poorer overall user experience, and less interactivity?
This question still has a problem because it is closed-ended. The respondent is given no room for anything other than a simple yes or no. It is far better to ask open-ended questions that let respondents express more in-depth opinions. For example, “What would you be willing to give up in order to have our next generation product run within a browser?” A user answering that question can go in a variety of directions. Where she goes—and does not go—with her answer will provide you with a more meaningful answer to the question which helps when writing user stories.
It is equally important to ask context-free questions, which are ones that do not include an implied answer or preference. For example, you would not ask, “You wouldn’t be willing to trade performance and a rich user experience just for having the software in a browser, would you?” It’s pretty clear how most people are going to answer that question.
Similarly, instead of asking “How fast do searches need to be?” ask “What kind of performance is required?” or “Is performance more important in some parts of the application?” The first question is not context-free because it implies there is a performance requirement to searching. There may not have been but, having been asked, a user is unlikely to say so; she’s more likely to take a guess.
At some point you will need to move from context-free questions to very specific questions. However, by starting with context-free questions you leave open the possibility for a wider range of answers from users. That will lead you to writing user stories that may have remained undiscovered if you jumped right into very specific questions.
