Get certified - Transform your world of work today

Close

Gathering Requirements Through User Stories and the Five W’s Technique

Writing user stories

14 April 2015

Eduardo Hernández Rangel
Secretary of Education


User stories are not merely an engineering requirement fashion. They are a simple but powerful and sophisticated way to gather requirements. They are also an Agile way to obtain the detail of the software through iterations that will, each time or during each review, gain more detail.

User stories use a business-oriented language to write down the needs of the product owner and the stakeholders, who are responsible for defining the features of the product. The concept of user stories originally comes from Extreme Programming, and they mainly focus on three concepts: Cards, Conversation, and Confirmation. Through conversation between the team and the stakeholders, user stories are fleshed out with more detail during each iteration. These details are jotted down on the cards. At the end, in the confirmation of the user stories, these are written into the acceptance criteria using the form, "As a [role], I want [goal] so that [benefit]."

An example user story

Here is an example of a user story: "As a system user, I want to log in to the system using my user name and password or my Facebook credentials so that I can use the system." This user story seems very plain, but it can be improved during a second iteration and the acceptance criteria can be written as follows: "As a system user, I want to log in using my user name and password or my Facebook credentials so that I can start using the software." An acceptance criteria message on the login screen should appear, to help the user write the password. The system should offer the user an option to register. The email or/and password can be saved in the Web browser so the user need not log in every time. The system should show a captcha option to avoid robots. The system must validate the user name as an email address, and there should be a "forgot username/password" option.

During this second iteration, the user story has become more detailed, but the initial statement did not change. This is because the user story must be short and it should maintain the value of the business; it is useful as a reminder of the business value.

User stories can be extended in the acceptance criteria, where the stakeholders state the detail of the business. Another way to include quality aspects in each user story is through the Definition of Done. This is useful for the team because it helps verify all needs that are noted in this section of the user stories. The Definition of Done can include aspects of quality about the user story itself, and details for the sprint or even for the potentially shippable products (PSPs).

In the example above, the Definition of Done defines quality aspects of the user story. The Definition of Done itself includes: After three failed attempts, the system should block the user for three minutes. Well-documented code includes the use case test data and the use case test approval.

The Five W's

The user story above is a standard user story, but sometimes it is difficult to obtain from the stakeholder (remember, in Agile the product owner is the responsible for deciding which items of the product backlog are authorized and sorted), because they have a vague idea about what they want. This, then, is a challenge for the team. In order to help obtain the product backlog, there are a lot of methods and techniques available. In this case, the "Five W's" can be useful for writing user stories with complete and coherent information.

The Five W's are used in journalism, criminal investigations, and other areas where completed and coherent information is crucial for interpretation. People who work regularly in these areas have experience in obtaining real user stories by means of direct interviews with the involved users. They apply this technique, which consists of getting all possible information about the case in terms of who, what, when, where, and why.

In the user story above, using the Five W's resolves the who (system user), what (log in using my user name and password or my Facebook credentials) and why (start using the software) questions, but where and when are not addressed.

Who
It is necessary to identify all possible stakeholders of the project in order to obtain the needs of each of them without forgetting the authorization of the product owner. The RACI matrix can help maintain and track all stakeholders of the project. In the above example, the “System user” is a stakeholder.

What
It is necessary to get, from each stakeholder, the functionality of the system in terms of user stories. Each stakeholder can express their needs with the product owner's authorization, but be sure that the user stories do not be epics. “I want to log in using my user name and password or my Facebook credentials” is the functionality that the stakeholder needs from the system.

Why
Define the reason for or purpose of the user story. In the example above, "so I can start using the software" is the reason this user story is important.

Where
Many questions can be answered with this "W," but in a simple way it can be discovered, for example, where the user story is going to be displayed -- in one server or multiple servers. Where is more oriented toward defining quality attributes, and this W must be considered in the Definition of Done characteristics or even, but less commonly, in the acceptance criteria.

When
Usually, when is used for quality attributes as well, and it can be defined as when it is necessary to execute the process, when the system must be available, or when it is necessary to do certain tasks in the system.

Refinement process

In refining the user story according to the Five W’s technique, the user story can be rewritten, because now it seems to be epic: "As a system user, I want to log in using my user name and password or my Facebook credentials so that I can start using the software."

Acceptance criteria
  1. Message on the login screen should appear, to help the user write the password.
  2. System should offer the user the option to register. (This is another user story).
  3. The email or/and password can be saved in the Web browser so that the user need not log in repeatedly.
  4. Include "forgot user name/password" option. (This is another user story).
  5. The system must validate the user name as an email address.
  6. System should show a captcha option to prevent robots.

Definition of Done
  1. After three failures, the system should block the user for three minutes.
  2. Code should be well documented.
  3. Include the use case test data.
  4. Include the use case test approval.
  5. The system should be displayed in a clustered server (where).
  6. The first user story must be implemented (when).


User story is reduced and two more user stories must be defined

Story #1: "As a user, I want to sign up so that I can use the software."

Acceptance criteria
  1. Validate the email.
  2. Verify the email is not a duplicate.
  3. Show a well-formed password tip.
  4. Show the privacy policy. (It looks as though this is another user story, if the privacy policy has CRUD functionality).
  5. Permission to capture a second email, private question, and answer.
Definition of Done
  1. Well-documented code.
  2. Include the use case test data.
  3. Include the use case test approval.

Story #2: "As a system user, I want to recover my user and password so that I can access to the software."

Acceptance criteria
  1. Permission to recover the user name and password through an alternate email.
  2. Permission to recover the user name and password through a private answer.
Definition of Done
  1. Well-documented code.
  2. Include the use case test data.
  3. Include the use case test approval.

In conclusion, epic stories must be avoided in order to be small enough to be considered specific, measurable, achievable, realistic, and timely.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.6 (12 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.

 
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


 

Newsletter Sign-Up

Subscribe