Introduction

Agile methodology and eXtreme Programming have picked up the pace today. It is being preferred over the traditional waterfall model. The artifacts are smaller, development more quick and with quality. There are no differences in the phases these two methodologies have.

• Requirement Specification
• Design
• Development
• Testing

But the key deference is how each of these phases function. In Agile, these phases become part of an iteration. I am not going to explain Agile programming here, since it is a separate beast. This article expects a basic awareness of agile methodology / eXtreme Programming. So for all those freshers who have just came out of college, I would suggest you have a look at Agile practices before taking a leap into this article.

What are User Stories?

User Stories are the primary development artifact in XP / Agile programming methodology. It replaces the traditional, long, confusing Software Requirements Specification (SRS). All those who have been in the development field for some time now know how difficult it is to derive some context by reading an SRS. Most people might use it instead of sleeping pills.

User Stories are short and precise to a limited context. It focuses on Who, What and Why of a feature. A User Story comprises of three parts called the 3 Cs of of a User Story (coined by Ron Jeffries):

Card: A brief description of the feature
Conversation: Detailed information regarding the feature. It might be a chat history, some feature description, or an image that are marked. Anything that provides more information regarding the feature.
Confirmation: A set of test that confirms the completeness of the feature. This is primarily the acceptance test criteria.

Sample User Story – front

Sample User Story – back

A User Story could describe either a feature, a non-functional feature (like performance related features), or a bug.

INVEST Model

A well written User Story should follow the INVEST model (coined by Bill Wake). INVEST is an acronym for:

• Independent: User Stories should be independent of each other. It would make the planning and estimation much easier. We can also start working on the user stories in any random order. Any dependency could be resolved by either combining or splitting User Stories.
• Negotiable: It simply means, the User Story should be brief covering only the gist of the feature. A User Story is considered to be a reminder for conversations regarding the details of the feature. All the details will be jotted in the conversation area.
• Valuable: The User Story should have a discernible value to the end-users, customers or the product owners. It’s better if the user writes the User Stories. Other options would be training a developer/analyst on that particular domain, having an intermediate person who knows the domain very well, etc…
• Estimable: It should be able to estimate the effort needed for a User Story. Usually the problems that makes it difficult to estimate might be: lack of domain knowledge, Epics, New Technologies etc. These are solvable by training the developer/analyst about the domain, spitting huge stories, just in time development, etc.
• Small: The User stories should be small, but not too tiny. It’s fuzzy to identify the apt size of an User Story. Usually, it would be small enough so that two-three developers could implement the feature in a single iteration, but this might vary according to the complexity of the feature. Splitting the complex user stories and combining tiny user stories are ways we could achieve them.
• Testable: We confirm the completeness of the User Stories through tests. The User Stories should be in such a way that it could be tested.

Further information on the INVEST model is here.

The Story of Writing User Stories

The Story of User Stories

User Role Modeling

User Role Modeling is the process of identifying, consolidating and organising various types of users and their role in the application. A user role explains a character of a population that intend to use the system.

This process would help in viewing the system in different perspectives, that way there is little chance that we might miss some important stories. Each role varies in what he needs from the system, the frequency and depth the system is used, proficiency of the user etc.

The steps taken to identify the User Roles would be:

Brain Storming: A group of people will schedule a meeting to identify the initial, rough set of User Roles. The group might consist of the developers, testers, customers, end-users, and stake holders. Each User role is written down on a piece of card.

Organizing: The relation ship between each User Role is identified. Overlapping roles are placed so that their cards overlap. The more the roles overlap, the more the cards will overlap.

Consolidating: During Consolidation, all overlapping cards are considered to eliminate any ambiguous cards. Even few unnecessary cards might also get ripped off during this process. Sometimes even a new role might emerge by merging two roles. At the end of the process we get a consolidated set of user roles.

Refining: This is the phase where we define several attributes of each role. Any useful information that distinguishes one role from the other may be used as an attribute. Some important attributes might be: frequency of usage, proficiency, domain expertise, goal of using the software etc…

Creating “Personas” is a way to make the process more interesting. A persona is an imaginary person that represents a role in the system. A persona should be described in such a way that everyone in the team feels like they know the persona. A persona has a name, a role, a behavior and, yes, even an optional photograph. Stories become much expressive when personas come into picture.

Extreme Characters is another additional task that could be performed to identify exceptional characters. Interestingly, you may discover new horizons for the software which might have skipped the mind otherwise. Creating Extreme Characters requires a very high level of imagination, patience and lot of extra time. The irony is that these characters might become useless or least important while developing the system. It might be helpful to identify new horizons of an already developed and mature system.

Gathering User Stories

The gathering process is also known as ‘Trawling’. Every project has a very diverse set of customers and user requirements. Gathering user stories techniques would be different for these diverse scenarios and in different phases of the project. Some of the most popular techniques would be:

• User Interviews
• Questionnaires
• Observations
• Story-Writing workshops

User Interviews

A fixed set of definitive questions are asked to a selected set of users in person by the business analyst / developers. The key to the success of these interviews would be the selection of the right interviewees and asking the right kind of question. Select the key users or user representatives as interviewees. The domain knowledge and a little bit of technical knowledge would help in gathering the right user stories.

The kind of questions asked will also impact the value of the user stories gathered. Asking open-ended and context free questions is the best way to get the actual needs from your interviewees. Let’s take an example question and refine it to get the best out of the interviewees. Let us consider the question: “Would you like the dashboard interface to be Web 2.0?” or “Would you like the quick add input in the top-right corner of the dashboard?”

The mistakes with this question is:

• It is close-ended.
• Insufficient details
• Technical jargon (‘Web 2.0’)
• Lots of context

A better refined question would be: “How do you want the dashboard to look like?” or “What features do you expect in the dashboard?”. Now you will see how different interviewees go in different direction and lot more user stories are discovered. During the discussions probably the questions you intended to ask previously might get answered.

Questionnaires

Questionnaires are highly effective to gather more information and prioritizing the user stories that are already in-hand and have a large user population. Questionnaires are effective when you need answers from a large population to a specific set of questions. An example of a questionnaire would be a survey that asks the current the existing user base about their suggestions and rating.Voting is another type of questionnaire.

Observations

Observing how the users use the application might provide some interesting and valuable user stories. For example, if you notice majority of people has to navigate through X steps to get to a particular place in the application and you think you could reduce the steps to X-Y, hence improving the usability of the software. Another example is profiling the application and fine tuning the application by eliminating performance bottlenecks.

Story-Writing Workshops

This is a technique similar to the Brain Storming meetings we discusses in the “User Role Modeling” section. A group of people will schedule a meeting to identify user stories. The group might consist of the developers, testers, customers, end-users, and stake holders. During the workshop, all participants writes as many user stories as they can. There are no priorities associated with any user stories at that point of time. Prioritization could be done on a later phase or at the end of the workshop.

This technique is very effective during the conception of the project / release.

Closure

This is just an introduction to User Stories. There are many more interesting topics like managing epics and tiny user stories, themes, confirmation and acceptance testing etc. Hopefully I might try to write more articles on few more topics like these. Kindly send your suggestions and feedback to: feedback@janeve.me

Reference

• User Stories Applied: For Agile Software Development by Mike Cohn
• http://www.agile-software-development.com/search/label/Agile%20Requirements%20-%20User%20Stories
• http://agilesoftwaredevelopment.com/blog/vaibhav/good-user-story-invest