Plan du site  
pixel
pixel

Articles - Étudiants SUPINFO

Scrum Method Part 3: User Stories Testing and Product Backlog Prioritization

Par Christian DESTREMAU Publié le 13/11/2017 à 17:44:11 Noter cet article:
(0 votes)
En attente de relecture par le comité de lecture

Write tests for User Stories

Should we test?

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 pyramid.

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.

Unit tests

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 situations:

  • Entering non-numeric values

  • Check that the conversion rate used is the correct one

  • 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 automation tool.

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.

Functional tests

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 rendezvous.

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 criterion.

An acceptance test is not a technical test. It must have the following characteristics:

  • Be visible to the user

  • Do not propose a solution

  • Do not be internal to the function tested

Acceptance criteria

To create an acceptance test, you must define acceptance criteria that respect the following formalism:

Precondition (state of the system before executing the User Story)

When (actor and behavior)

So (result)

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. "

Test data and scenarios

In the example above, our acceptance criteria describe test cases but in a general way because we do not know which data to use.

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.

TDD and ATDD

Piloting by TDD (Test Driven Development) tests and Acceptance Test Driven Development (ATDD) acceptance tests are perfectly applicable to agile methods.

Test Driven Development

This development technique is based primarily on tests. Each developer must write feature-specific tests before developing it.

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 acceptance tests.

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 in practice

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 developments.

Find time for writing

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 planning.

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.

How to write the tests?

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 small.

It is possible to use acceptance testing tools such as Robot Framework or simply Excel files.

Product Backlog Prioritization

Why prioritize?

The purpose of this chapter is the prioritization of the constituent elements of the Product Backlog, which are themes, Epics and User Stories.

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 iterations.

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 number.

How to proceed ?

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 processed quickly.

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

Priority Poker is a 10-card game whose value is given by the Fibonacci suite.

The values are: 0 -1-2-3-5-8-13-20-40-100-?

The priority poker process is as follows:

  1. The Product Owner reads the User Story.

  2. 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 "? ".

  3. At the signal of the Product Owner, each user shows the chosen map to everyone.

  4. 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.

  5. 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 future Sprints.

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 theory of the model

The Kano model applied to Scrum will divide User Stories into 3 categories:

  • Basic User Stories.

  • Performance User Stories.

  • User Stories of enthusiasm.

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 them.

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:

  • A car is useful but a station wagon is more useful for a large family.

  • A television can watch movies but the picture quality is better on a flat screen.

In terms of priority, these User Stories are to be classified in second place because they are linked to non-negligible business values.

User Stories of enthusiasm

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 product.

Graphic representation of the model

Kano's model also has a graphical representation that applies to User Stories:

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 normal.

For linear User Stories, reading is easy. if the functionality is present, it generates satisfaction, if it is not present it generates dissatisfaction.

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 account

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 enthusiasm.

The practice

Once the Product Owner has written a satisfactory number of User Stories, he then sets up prioritization workshops.

These workshops include the following steps:

  • Presentation of User Stories.

  • Categorization according to the Kano model.

Ask the Stakeholder to position themselves

In order to categorize User Stories among the groups we have seen previously, we are going to feel a user's functionality may be:

  • "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 questions:

What do you feel if this feature is developed in the first place?

What do you feel if this feature is not developed right away?

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 efficient.

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 model:

  • 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 necessary.

  • 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 Mike Cohn.

Why prioritize themes?

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 following criteria:

  • 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 theme

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 reference

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 table.

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 theme.

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.

Theme Scoring

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 criteria

Then we choose a reference theme and we compare the other themes to the latter using the following comparison grid:

Table 1. 

Factor Value
1 much worse than the referent theme
2 worse than the referent theme
3 identical to the referent theme
4 better than the referent theme
5 much better than the referent theme

This grid establishes a relationship between a factor and a value.

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 figure below.

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 produced.

Evaluation of benefits and penalties

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 criteria:

  • Relative Benefit: What is the impact of the theme on the product? Is it positive?

  • Relative penalty: What will be the impact if the theme is not developed?

The results are then presented in a table like the one below:

Table 2. 

  Relative profit Relative penalty Total Value in%
Theme A 5 3 8 73%
Theme B 2 1 3 27%
Total     11  

Estimation of development cost of effort

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 necessary.

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:

Table 3. 

  Relative profit Relative penalty Total Value in% Cost of effort Value in% Priority
Theme A 5 3 8 73 % 40 39 % 1.87
Theme B 2 1 3 27 % 62 61 % 0.44
Total     11        

Calculation of the prioritization

We can finally calculate the priority of each theme. :

Thème A = 0.73/0.39 = 1.87

Thème 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 development team.

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.

  1. The first user presents his User Story to his interlocutor.

  2. The interlocutor presents his own User Story;

  3. The first user must argue that his user Story has a higher business value than his colleague's.

  4. They then reverse the roles.

  5. 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.

  6. The users will then form another pair and start again from step 1.

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.

Conclusion

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 confident.

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.

Bibliographical References

Website: https: //www.slideshare.net/mikecohn/prioritizing-your-product-backlog-22870228

Book: Scrum, an agile method for your projects (ENI editions)

A propos de SUPINFO | Contacts & adresses | Enseigner à SUPINFO | Presse | Conditions d'utilisation & Copyright | Respect de la vie privée | Investir
Logo de la société Cisco, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société IBM, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sun-Oracle, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Apple, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sybase, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Novell, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Intel, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Accenture, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société SAP, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Prometric, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Toeic, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo du IT Academy Program par Microsoft, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management

SUPINFO International University
Ecole d'Informatique - IT School
École Supérieure d'Informatique de Paris, leader en France
La Grande Ecole de l'informatique, du numérique et du management
Fondée en 1965, reconnue par l'État. Titre Bac+5 certifié au niveau I.
SUPINFO International University is globally operated by EDUCINVEST Belgium - Avenue Louise, 534 - 1050 Brussels