Articles - Étudiants SUPINFO
Write tests for User Stories
It is very important to test and validate any development carried
out as part of the Scrum method, to ensure optimum product quality and
to make users more confident.
On the other hand, let's not forget that the execution of tests
and their validation can be a way for the Product Owner to validate or
not the content of a Sprint.
The test pyramid of Mike Cohn
In his book "Succeeding with Agile", Mike Cohn introduced a
concept called "Pyramid of Tests" which aims to divide into three
distinct categories tests that can be applied to an application.
At the lowest level of the pyramid are unit tests, followed by
business tests, and finally we have the GUI tests at the top of the
Unit tests are at the base of the pyramid: this means that they
play a major role. And so, the more these tests will be many more the
pyramid will have a solid foundation. The application will be of better
quality because it will be stable. These tests are done in code form and
are therefore easy to automate. On the other hand, the cost of setting
up and performing these tests is relatively low.
Then we have the functional tests that make up the central part of
the pyramid. These tests make it possible to verify that the application
meets the needs and the functional requirements via the question: "Are
we in adequacy with the need? ". They are difficult to automate. It is
necessary to set up a test repository so that each test can be replayed
at each new iteration. The cost of these tests is high but they are
becoming more important because they make sure that the product is in
line with the needs of the customer.
Finally, we find at the top of the pyramid the tests of HMI
(human-machine interface). This is to verify that the graphical
interface corresponds to the needs, that it presents no bugs and that it
is efficient. These tests are still difficult to automate nowadays.
Their cost is therefore high and that is why their place in the pyramid
of tests is minimal.
These tests are intended to validate some of the code by
comparing its execution with the expected result.
For example, if we take the case of a currency conversion
function, we will write tests to deal with different
Entering non-numeric values
Check that the conversion rate used is the correct
Check that the conversion is effective.
The use of unit tests will make it possible to ensure
applicative stability from one Sprint to another and to avoid any
regression. For that, it will be enough to replay the tests using an
As in any agile method, we recommend development from Test
Driven Development. It consists of writing the tests first, then
writing the code that will satisfy them.
It is not easy for a developer to test the functional aspect of
an application. To carry out this type of test, we generally call for
the implementation of a functional recipe book written by a software
licensee trained to this task. This same person must roll out all the
tests to ensure that the application meets the needs.
For a project managed agile, this type of operation is not
suitable because it is heavy and rigid. Instead, we will use
acceptance tests which, applied to User Story, allow the application
to be functionally tested.
HMI tests (human-machine interface)
These tests make it possible to verify that the application
conforms to the ergonomics desired by the customer. This is a
necessary evil for the customer to be completely satisfied with the
quality of the software provided.
Often sidelined, these tests are actually very useful because
the visual and ergonomic aspects are the point of entry of the user
and it can reject your work even if the functional aspect is at the
It is necessary to evaluate in addition the visual aspect of the
interface, the aspect performance. Software tools exist to make your
job easier, such as Selenium (http://seleniumhq.org/).
Definition of acceptance tests
It is quite tedious to functionally test an application, but the
use of acceptance tests will simplify the task.
The Product Backlog, seen in the previous part, consists of User
Stories. Each User Story must follow the INVEST principle and therefore
be testable (T as testable). Acceptance tests will help us against this
An acceptance test is not a technical test. It must have the
To create an acceptance test, you must define acceptance
criteria that respect the following formalism:
Precondition (state of the system before executing the User
When (actor and behavior)
If we have the following User Story: "As a user, I can connect
to the Information System. "
The following acceptance criteria can be deduced:
"The user is disconnected. When he enters his credentials, he
then has access to the Information System. "
"The user is disconnected. When he makes an error while entering
his credentials, he is denied access to the Information System.
In the example above, our acceptance criteria describe test
cases but in a general way because we do not know which data to
To have a proper acceptance test, we must complete our
acceptance criteria with test data and scenarios.
For example, we define the following acceptance test:
"The user is disconnected. When he enters the AAA ID and the BBB
password, he has access to the Information System. "
Acceptance tests and User Stories
A good practice of acceptance tests is to assign to each User
Story at least 2 tests: a test corresponding to the ideal case and one
corresponding to the case of error.
Piloting by TDD (Test Driven Development) tests and Acceptance
Test Driven Development (ATDD) acceptance tests are perfectly applicable
to agile methods.
This development technique is based primarily on tests. Each
developer must write feature-specific tests before developing
The cycle followed by the TDD is as follows:
Write a first test
Make sure this test fails until the code is developed
Write the code that will allow to pass the test
Check that the test is successful
Improve the code by re-factoring by ensuring that the
functionality remains operational
TDD tests are unit tests. They are written in code form, which
allows to automate them.
The use of TDD allows the developer to improve his productivity.
Indeed, it only has to worry about writing the code to pass the test
and avoid the coding of unnecessary functions that would weigh down
the entire application.
This development technique is preferred because it allows the
team to deliver a quality increment, respecting the following
principle of the agile manifesto: "Simple design".
Acceptance Test Driven Development
This development technique consists of developing functional
tests with code.
In practice, we will write functions (or methods in
object-oriented programming) that will follow the formalism of
These tests are therefore not actions to be carried out at the
end of development, but must be considered as development tasks in
their own right.
The tests are important and integrate with the Scrum method
because they improve the quality of the application delivered. Let's see
how unit and acceptance tests are set up in a Scrum project.
The work of the Product Owner
We might consider asking the Product Owner to write acceptance
tests as these are functional tests.
In practice, asking him, in addition to his work writing the
User Stories, to write acceptance tests for each of them would be too
heavy a burden.
We would prefer that the Product Owner and the development team
come together to write these tests together. This will allow the team
to take ownership of the tests, and thereby improve the
The principle is the following in the Scrum method: each User
Story included in a development iteration must undergo at least one
acceptance test. From there, writing the acceptance tests must be done
before each start of a Sprint.
This work is not to be done when planning Sprint because it is a
time-honored ceremony. It will be necessary for the team to plan a
time to write these tests but will not forget to include it in the
Should we write the tests of all User Stories
The answer is no. We will only write the tests of the User
Stories eligible for the next Sprint.
If the User Stories are written on post-it notes, then you can
optionally write the acceptance tests on the back of the post-its.
This is not necessarily ideal because the space can sometimes be too
It is possible to use acceptance testing tools such as Robot
Framework or simply Excel files.
Product Backlog Prioritization
The purpose of this chapter is the prioritization of the
constituent elements of the Product Backlog, which are themes, Epics and
The advantage of such a prioritization is to organize the User
Stories to determine which ones bring the most business value and which
will be realized first and those that can be developed in future
Prioritization is a task for the Product Owner, assisted by the
users (who are also called Stakeholders). It must be carried out
methodically, otherwise it may easily turn into a nightmare.
What does it mean to prioritize?
Prioritizing a User Story consists in defining its priority over
others. This priority rank represents the Business Value assigned to the
User Story. It is the User Story with the highest business value that
will be developed in the next Sprint.
It is not easy to define this degree of priority. To achieve this,
each User Story must be positioned according to 4 criteria:
Risk measurement: if the User Story is developed now, we will
avoid heavy impacts later.
Quality improvement: if the User Story increases the quality
of the deliverable, it must be developed quickly.
Dependency: Even if dependencies are deprecated between User
Stories, it is sometimes unavoidable. A feature that is a
prerequisite for other features takes precedence.
Give users confidence: Users may have a desire without being
able to express it. A User Story defining this need in a minimalist
way will be prioritized, so that users can easily return.
In practice, there is no magic recipe for prioritizing the Product
Backlog. It is usually the result of human relations and discussions and
specific to each project.
Users are not able to set priorities for User Stories, but the
Product Owner has full authority to do so.
Define the business value
In general, each user story is assigned a business value as a
The principle is that the Product Owner selects a User Story and
sets its business value to a number in 0 and 100.
This number is used to position the User Stories together. A
User Story with a figure of 100 is a high value user story and will be
In practice, business value is defined by the Product Owner and
Stakeholders. For this, we use a technique using a card game called
Planning Poker that we will call here Priority Poker.
Priority Poker is a 10-card game whose value is given by the
The values are: 0 -1-2-3-5-8-13-20-40-100-?
The priority poker process is as follows:
The Product Owner reads the User Story.
Each user has a deck of cards and estimates the business
value by choosing the card that seems appropriate. If he is
undecided, he can choose the card "? ".
At the signal of the Product Owner, each user shows the
chosen map to everyone.
If there are differences in the values chosen, there is room
for discussion between the users. We repeat the previous steps
until a common value is found.
Once the business value is determined, it is then registered
on the relevant User Story. We can then classify it in a table
containing the values of Priority poker in column.
When all User Stories have been reviewed, we have their ranking
by business value. Those with higher value will be treated first in
Advantages and disadvantages
All Stakeholders can participate in the valuation of the
business value, they will strengthen their sense of involvement in the
project. This is the biggest advantage of this method. On the other
hand, the playful side is also an asset for this method.
As the User Stories are sorted by value, it is possible that in
the classification of these ex-aequo appear (2 user stories with 4
points, four with 8 points ...). The Product Owner must then make a
new prioritization to differentiate them.
This method is not recommended for prioritizing the entire
Product Backlog. It is better to use it when it is already organized
with another method such as the Kano model.
Prioritization by using the Kano model
The Kano model applied to Scrum will divide User Stories into 3
Basic User Stories
A User Story is considered basic when it expresses a fundamental
need that the application can not do without.
At the level of the prioritization, these Users Stories will
have a priority character since the application will not work without
Linear User Stories
Linear (or performance) User Stories are those expressing a need
for quality that will seduce the user. Here are some examples when
considering physical products:
In terms of priority, these User Stories are to be classified in
second place because they are linked to non-negligible business
User Stories of
A User Story of this type is often linked to the interjection
"that's great! During his presentation. They correspond to a need
which is not obligatory but which would be a real advantage:
"If I could see my client's picture before calling, I'll be able
to put a face to a name. "
These User Stories are not a priority, but including some of
them in the upcoming Sprints will give a renewed interest to the
Graphic representation of the
Kano's model also has a graphical representation that applies to
For basic User Stories, if the functionality is not developed it
will cause a lot of dissatisfaction. But this will not generate much
satisfaction when the feature is present: indeed, the User Story
expresses a fundamental need and therefore its presence is only
For linear User Stories, reading is easy. if the functionality
is present, it generates satisfaction, if it is not present it
Finally, if the User Stories of enthusiasm are not present it
does not cause any dissatisfaction because they express a need that is
not necessary to the final product. But if they are put in place, then
the satisfaction will be greater.
User Stories to take into
Kano's method does not allow you to assign a business value to
each User Story (that is, a number). On the other hand, it allows us
to sort out what should be considered in the next iterations.
We have the following rule:
Take into account all basic User Stories.
Take into account some of the linear User Stories.
Take into account some of the User Stories of
Once the Product Owner has written a satisfactory number of User
Stories, he then sets up prioritization workshops.
These workshops include the following steps:
Ask the Stakeholder to position
In order to categorize User Stories among the groups we have
seen previously, we are going to feel a user's functionality may
"I am neutral" (no opinion in particular)
"I like" (I like this idea)
"I do not like" (I do not stick with this idea)
In order to position the User Story in the Kano model, we will
ask the user to give their feelings from the following
What do you feel if this feature is developed in the first
What do you feel if this feature is not developed right
Here are some examples to make my point.
Consider the following User Story:
First User Story:
"As a customer, I need to enter a username and password to log
into the Information System. "
By asking the 2 questions to the future users of the system, we
obtain for example the following answers:
Question # 1: I am neutral because this feature is basic.
Question # 2: I would not like this feature not to be present as
this can create security issues.
Second User Story:
"As a sales representative, I need to be able to consult my
client portfolio to make it easier for me to follow it. "
Here are the answers we got:
Question 1: I like this feature because it will make me more
Question n ° 2: I will not like it not being present because it
concerns the heart of my job.
Categorize User Stories
Now that we have noticed the user experience, we can classify
the User Stories among the categories described in the Kano
The basic User Stories are those whose response is "I am
neutral" / "I do not like" because this implies that the User
Story is a basic need.
The linear User Stories are those whose answer is "I like" /
"I do not like" meaning again that the User Story is
And finally, the User Stories of enthusiasm are those having
the answer the couple "I like" / "I am neutral".
When User Stories have been categorized, we can use the Priority
Poker technique to set a priority within each category.
Prioritization from the themes
This method of prioritizing the Product Backlog was developed by
The prioritization of themes is interesting because it is at the
macroscopic level. It is therefore easier than at the level of the
User Story itself.
Theme Screening (Themes Survey)
This method is based on the definition of 5 to 9 selection
criteria that will answer the following question:
"What are the important elements for the company that need to be
put in place in the future iteration? "
Definition of criteria
To answer the previous question, we have, for example, the
Give yourself a real advantage over our competitors.
Allow to test the concept of Mr X.
The functionality is expected from customers.
Generate cash receipts as early as next quarter.
Choice of a reference
Then we choose a theme of the application that must be known to
all and is included in the list of themes to develop in the next
iteration. This theme will serve as a reference theme (TO).
Positioning themes with
We then position the topics in columns in a double-entry table
as in the image below. The evaluation criteria are the rows of the
All users are questioned by asking them how they feel about a
criterion in relation to a theme.
For example, suppose we chose criteria c1, c2, c3, c4 and the
themes TA, TB, TC and TD. The TD theme is the TO reference
Is criterion c1 more important for theme A than for the
reference theme? If yes, insert a + sign in the table. If no, insert a
sign - and if the importance is the same, insert the sign 0.
To know the priority of the themes, it suffices to add for each
theme the number of + and to subtract the number of -. We get an
ordered list of themes.
This prioritization method is similar to the Theme Screening
method except that a weight must be assigned to each criterion to
specify its relative importance. This approach may appeal more to some
of you, by its rational side.
Definition of weights
A weight is defined as a percentage and the total weight of all
criteria must be 100%.
For example, we have the following weights:
Criterion 1: 25%.
Criterion 2: 10%.
Criterion 3: 20%.
Criterion 4: 45%.
Comparison of themes against
Then we choose a reference theme and we compare the other themes
to the latter using the following comparison grid:
||much worse than the referent theme
||worse than the referent theme
||identical to the referent theme
||better than the referent theme
||much better than the referent theme
This grid establishes a relationship between a factor and a
It is used as follows:
Question: "How does criterion 1 of this theme relate to the
reference theme? "
Answer: "Better than the referent theme. "
A weighted result is obtained by multiplying the weight of the
criterion with the factor corresponding to the response. Then we
proceed in the same way by reviewing all the criteria for this theme
and we can then move on to the next topic.
We finally present all these results in a table as shown in the
We then see the prioritization of themes.
Prioritizing themes by using relative weights
The method of prioritizing themes by relative weight makes it
possible to prioritize them by measuring the effect of their presence
or absence on the future iteration or on the product to be
Evaluation of benefits and
First, you need to build a list of unordered topics.
For each theme, we will define a value of 1 (low importance /
low impact) to 9 [low importance / low impact] for the following
The results are then presented in a table like the one
Estimation of development cost of
The estimate of the cost of development effort will be explained
in my next article, in Sprint's estimation and planning chapter. In
fact, for each User Story, the development team defines an estimated
effort using a tool called Planning Poker, identical to the one called
Priority Poker. The presence of the development team is therefore
For each theme, we obtain the cost of effort by adding the
points of each User Story. We can therefore complete the previous
table, and we obtain:
||Cost of effort
Calculation of the
We can finally calculate the priority of each theme. :
Theme A = 0.73/0.39 = 1.87
Theme B = 0.27/0.61 = 0.44
It sometimes happens that the Product Backlog is built upstream
of the implementation of the Scrum method and therefore without the
It is not possible to fill in the estimate column. However, you
are allowed to insert in this column the values of your choice, for
example, the financial cost of the theme.
Prioritization through communication
Another method can be used when User Stories are already grouped
by categories or themes.
It consists of an animation directed by the Product Owner. This
gives each user a User Story and asks them to determine a business value
ranging from 1 to 5.
Couples of users must be trained to defend their own User Story
during a discussion.
The first user presents his User Story to his
The interlocutor presents his own User Story;
The first user must argue that his user Story has a higher
business value than his colleague's.
They then reverse the roles.
At the end of the discussion, the person who was the most
convincing added to the back of his User Story, the point that had
estimated his opponent for his User Story.
The users will then form another pair and start again from
After a few iterations of discussion (each discussion is limited
to one minute maximum), the Product Owner puts an end to them. He then
asks users to sum the points on the back of their User Story. This value
represents the Business Value of the User Story.
The prioritization of the Product Backlog is then obtained by
descending ordering the business values of the User Stories.
This method is interesting because it can bring dynamism to the
task of prioritization, sometimes perceived as austere.
In this third part, we first saw how we can develop tests for User
Stories. These tests will improve product quality and make users more
Then we were interested in a crucial problem of the Scrum method:
that of the prioritization of the Product Backlog. Various methods allow
us to obtain this prioritization and thus to know which User Stories are
to be realized first.
Book: Scrum, an agile method for your projects (ENI editions)