This is not a Wikipedia article: It is an individual user's work-in-progress page, and may be incomplete and/or unreliable. For guidance on developing this draft, see Wikipedia:So you made a userspace draft.

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL
Easy tools: Citation bot (help) | Advanced: Fix bare URLs
This page was last edited by Ricky81682 (talk | contribs) 8 years ago. (Update timer)

Finished writing a draft article? Are you ready to request an experienced editor review it for possible inclusion in Wikipedia? Submit your draft for review!

User Story Information Gathering Techniques[edit]

Introduction[edit]

User stories play a vital role in order to have the successful product. To the stakeholders, it lets them know how the product will turn out from the early stage of the development; to the development team, it gives an overview of the overall system functionality.

Gathering user stories, however, requires techniques. Without techniques, the audiences will find it difficult to describe what they want in a full detail. In order to analyze the users’ expectation towards the product, several user story gathering techniques have been developed. The most effective techniques are: user interviews, questionnaires, observation, and story-writing workshop.

User Interviews[edit]

User Interview Overview[edit]

This is one of the most common methods when gathering user stories. User interviews have advantage of the fact that instant follow-ups can be done when a line of questioning provokes unexpected and interesting answers. By contrast, surveys and questionnaires require analysis before follow-ups can be done.

Interviewee Selection[edit]

It is essential to select a representative set of users to interview. The interviewees should be real users with different roles if possible, but proxies such as managers of end users, customers who are not end users but purchasers of the product, and former users, can be used with caution and awareness of their limitations.

Interview Design[edit]

Interviewees cannot simply be asked what they or need, since they generally do not know exactly what they want or cannot articulate their needs precisely. In fact, users may have a desired solution which is not practical. Careful interview questioning is necessary to elicit user needs without over solving the problem or solving the wrong problem.

Open Ended vs. Closed Ended Questions[edit]

Closed ended questions have simple multiple choice, often binary, answers. They tightly constrain answers by incorporating, often implicitly, assumptions about the problem's solution. To a great degree, a closed ended question requests ratification of the solution embedded in the question, i.e. accept or reject. By over engineering the problem at the requirements gathering stage of a project, closed ended questions can lock a project into an inferior solution from the beginning.

By contrast, open ended questions do not constrain solutions because they are open to many, non-predetermined answers. Open ended questions generally ask "how" or "what", not "will". Open ended questions are more likely to elicit unexpected and spontaneous responses, which can be useful in the early stages of user story writing.

Context Free vs. Context Specific Questions[edit]

Context free questions do not make any assumptions about the problem to be solved or the solution technique. They are useful for providing a high level understanding of the problem and finding user needs that have not been anticipated.

Context specific questions are useful for exploring solutions as user stories are refined.

The combination of context-specific and closed ended questions is risky and should be used carefully. One example used by Mike Cohn is a simple question contained in an interview for one of his projects, “Would you like it in a browser?”. He later wrote, “This question sucked two years out of my life”^[1]. The question assumed that users understood all the performance and functionality trade-offs in implementing the solution in a browser instead of as a native Windows application, but that was not the case^[2].

Question Examples[edit]

Open ended and context free: Where is performance important in this application?
Closed ended and context specific: Is editing performance important in this application?

Questionnaire[edit]

Overview[edit]

A questionnaire has a list of questions with a corresponding list of possible choices for each question. It is rather friendly and easier for the stakeholders to respond since they are given possible choices. On the other hand, a questionnaire is not an ideal method to gather a new user story. A questionnaire is a one-way communication. If a new idea was suggested by an audience, it will be difficult to perform further research or follow up questions to clarify the idea in a questionnaire format. Still, it is exceptionally efficient when it comes to gathering the details and prioritization of user stories.

Audience[edit]

The audience of the questionnaire considers all the stakeholders. However, it is recommended to divide up the questions that are related to different stakeholders. For example, for a user story about an ATM regarding the interface between the customer and the machine, the audiences should be the bank's customers rather than the bank's audit department. For the other way around, regarding a user story related to the communication between an ATM and the bank's main server, the audiences should be the bank's administrators rather than the customers.

Usage[edit]

The questionnaire’s questions and the list of choices should be based on the data related to the user stories gathered from the interview and/or other methods such as observation and story-writing workshops. Once the user stories are gathered, a questionnaire can be used detailing out the user story and/or prioritizing the user story.

Prioritization of User Stories[edit]

A questionnaire can be used to prioritize user stories based on a survey of the stakeholders. During the interview, audiences might suggest an implementation of a new feature. There are several methods for the new feature, but only one of the methods can be implemented due to budget limitations. For example, from the interview, it was found that the customer would prefer adding another security feature for an ATM. Audiences mentioned several ways such as finger print, retinal scan, and voice vibration. Since the interview was done by only a few people, the team would like to know which method is preferred by the majority of the audiences. In such a case, a questionnaire will be an ideal way to find out which method the audience would like to see for their new feature.

Gathering the details[edit]

A questionnaire can also be used to help gather the details of the user story. If there is a new user story for a new feature that needs to have detailed specifications, a questionnaire will be an excellent method to survey the stakeholders regarding what and how they would like to see the feature. For example, let's say the audience chose a finger print method for another security method for an ATM. Then how many finger prints would they feel comfortable being checked? How many times would they want to try in case of failure? Such details can be gathered rather easily from a great number of audiences by using a questionnaire.

Other Considerations[edit]

A questionnaire sometimes contains an open-context question with a free space for the response. Although there are no rules forbidding it, it is not considered an ideal usage for a questionnaire. However, if there is an audience giving you a feedback that is worth looking into, it will be ideal to put it as a part of an interview for the next iteration.

Summary[edit]

Different techniques have different characteristics. An interview is the ideal technique to use when it comes to trawling for new user stories. It has several ways to ask questions, and depending in the type of question, different responses from the audience can be expected. A questionnaire is ideal to use after the basic idea and data have been gathered for user stories. It is exceptionally efficient to gather specific details and to prioritize user stories. There are other techniques that are not covered in this article such as observation and story-writing workshops. All techniques have their pros and cons. In order to gather user stories, it is important to know when to use the different techniques.