The document discusses using the "Five W's" technique to refine user stories and gather more complete requirements. It provides an example user story for logging into a system and refines it using Five W's, which involves defining the who, what, when, where, and why. This reduces the original user story into three smaller stories around logging in, registering, and password recovery. It demonstrates how Five W's can help capture additional details to avoid epic user stories and more clearly define acceptance criteria and the definition of done.

1. User stories through Five W’s technique
User stories are not an engineering requirement’s fashion. They are simple but very powerful and
a sophisticate way to gathering requirements. They are an agile way to obtain the detail of the
software through iterations that each time or during each review will gain more detail. Mainly,
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.
User stories come from Extreme Programming at the beginning and they mainly focus on three
concepts such as cards, conversation, and confirmation. Through conversation between the
team and the stakeholder’s user stories get more details during each iteration, these details are
jotted down on the cards and at the end in the confirmation of the user stories these are written
through the acceptance criteria. Using the form “As a <type of user>, I want <some goal> so that
<some reason>.”
Here is an example of a user story.
As a system user, I want to login the system using my user and password or my Facebook
credentials so that I can use the system.
This user story seems to be very plain and it can be improved during a second iteration and the
acceptance criteria can be written as follows.
As a system user, I want to login using my user and password or my Facebook credentials so
that I can start using the software.
Acceptance criteria
Message on the login screen should appear to help the users to write the password.
System should offer the option to register the users.
The email or/and password can be saved in the web browser in order to not login for a
period of time.
System should show a captcha option to avoid robots.
The system must validate the user name as an email address.
Include forget username/password option.
During this second iteration, user story is detailed but the initial statement does not change. This
is because the user story must be short and it should maintain the value of the business; it is
useful as reminder of the business value.

2. 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 on the definition of done. It is useful
for the team because it helps to verify all needs that are jotted down in this section of the user
stories. Definition of done can include aspects of quality about the user story itself, for the sprint
or, even for the potentially shippable products (PSP). In the example, definition of done define
quality aspects of the user story.
The user story with definition of done.
As a system user, I want to login using my user and password or my Facebook credentials so
that I can start using the software.
Acceptance criteria
Message on the login screen should appear to help the users to write the password.
System should offer the option to register the user.
The email or/and password can be saved in the web browser in order to not login for a
period of time.
System should show a captcha option to prevent robots
The system must validate the user name as an email address
Include forget username/password option.
Definition of done
After three fail times the system should block the user for 3 minutes.
Well documented code.
Include the uses case test data.
Include the uses case test approval.
The user story above is a standard user story but sometimes it is difficult to obtain this user story
for the stakeholder (remember, in agile manifest, the Product Owner is the responsible to decide
which items of the product backlog are authorized and sorted), because they have a vague idea
about what they want, so this is a challenge for the team. In order to try to help obtaining the

3. product backlog there are a lot of methods and techniques but in this case, “Five W’s” can be
useful to get the users stories with completed and coherent information.
“Five W’s” is used on journalism, criminal investigations and other areas where completed and
coherent information is crucial to be interpreted. These areas have more experience in obtaining
real user stories by means of interviews directly to the involved users. They apply this technique
which consists in getting all possible information about the case in terms of who, what, when,
where and why.
In the user story above it resolves the “Who” (system user), “What” (login using my user and
password or my Facebook credentials) and “Why” (start using the software) but “Where” and
“When” are not present.
“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
(obtaining form the PMI-Process) can help to maintain track all stakeholder of the project. In the
above example the “System user” is a stakeholder.
“What”
From each stakeholder is necessary to getthe functionality of the systemin terms of user stories.
Each stakeholder can express their needs with the Product Owner authorization but reviewing
that the user stories do not be an epic user story. “I want to login using my user and password or
my Facebook credentials” is the functionality that the stakeholder need in the system.
“Why”
“Why” define the reason or purpose the user story must be implemented. In the example above
“I can start using the software” is the reason why 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 to define quality attributes and this “W” must be considered in the Definition
of the done characteristics or even, but less common in the Acceptance Criteria.
“When”
Usually, it is used for quality attributes too and it can be defined when is necessary to execute
the process; when the system must to be available or when it is necessary to do certain tasks
on the system.

4. Refining the user story according to the Five W’s technique, the user story can be rewritten
because it seems to be epic.
As a system user, I want to login using my user 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 users to write the password.
2. System should offer the option to register the user. (This is another user story).
3. The email or/and password can be saved in the web browser in order to not login for
a period of time.
4. Include forget username/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 fail times the system should block the user for 3 minutes.
2. Well documented code.
3. Include the uses case test data.
4. Include the uses 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.
-----------------------------------------------------------------------------------------
2. 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 that this is another user story if privacy policy has
CRUD functionality).
5. Permission of capturing a second email, private question and answer.

5. Definition of done
1. Well documented code.
2. Include the uses case test data.
3. Include the uses case test approval.
-----------------------------------------------------------------------------------------
3. As a system user, I want to recover my user and password so that I can access to the
software.
Acceptance criteria
1. Permission of recovering the user and password through the alternate email.
2. Permission of recovering the user and password through the private answer.
Definition of done
1. Well documented code.
2. Include the uses case test data.
3. Include the uses case test approval.
Epic stories must be avoided in order to maintain a reachable user stories.
Mockup for login.

6. Mockup for sign up.
Eduardo Hernández Rangel, MCC, PMP, ITIL Cer, Scrum Master
lalohr@gmail.com