Articles - Étudiants SUPINFO
After having presented in a first part, the context in which the
Scrum method fits, we will now engage in its description.
We will first define the main elements of Scrum as a global
overview. Then we will talk about the different actors of the Scrum team.
Finally, we will study the Product Backlog, a document that lists the
needs of the client and must be put in place at the beginning of the
In 1986, the Japanese Hiritoka Takeuchi and Ikujiro Nonanka
imagine a way to increase the speed of development of an application,
while having a strong notion of flexibility. For this, they imagine a
team with multiple skills capable of handling all the tasks required to
produce a product via a process overlay. Their approach is based on the
concept defined by the game of rugby fifteen: a united team with the
common goal of advancing the ball in the opposite camp.
In 1991, two developers took over this concept and associated it
with a name: that of Scrum. Scrum refers to the scrum in the game of
rugby and supports the idea of a team united and striving towards its
The year 1995 marks the official birth of the method, as it is the
year that Ken Schwaber describes the principles. He will publish them
jointly with Mike Beedle in 2001 in their book: "Agile Software
Development with Scrum".
In recent years, the Scrum method has continued to be implemented
in companies, making it the most popular agile method.
We will now focus on the principles implemented by the Scrum
The project team
It is not easy to imagine the realization of a project without
being human. Scrum therefore requires the presence of a team of at
least three roles:
The Product Owner
The Scrum Master
The development team
The Product Owner is the one who has the vision of the
product. Its essential role is to retranscribe it through the
writing of "stories" which will be called User Stories thereafter.
The set of these User Stories then constitutes the list of needs and
will be called later the Product Backlog.
The function of Scrum Master comes down to that of
"facilitator". It is he who has the mission to clear the obstacles
that team members may encounter, ensuring that the Scrum method is
Finally, the development team, consisting of skills and
variable experiences (designer, designer, developer ...) has the
role of developing the User Stories contained in the Product Backlog
to provide a quality deliverable. Scrum does not differentiate
between team members even if their profiles are different. The team
is self-organized, that is, no one has authority over what to do and
how to do the job.
A major point of this method is therefore the removal of the
subordination link. Indeed, this method does not refer to the notion
of "leader" and therefore it removes a well-known role, that of
Events or ceremonies
The concept of meeting in traditional project management is
reflected in the Scrum method by events called ceremonial.
For each event, a duration is defined. Unlike the traditional
project management method, each event has a maximum duration. It
must be respected for good time management and increased
The Scrum method sets up five events:
Sprint Planning Meeting
Daily Scrum meeting
The Sprint is not a meeting in the usual sense of the word. It
lasts a maximum of one month. This is a period of time during which
an increment of the finished product, usable and deliverable in
production is realized. It is a "big meeting" constituting the daily
life of the team over a defined period.
Sprint's planning meeting brings together the entire Scrum
team and defines the purpose of the sprint and the tasks to be
performed during it. This lasts for a maximum of 8 hours for a
Sprint of one month (4 hours for a Sprint of 2 weeks).
The Daily Meeting, which translates into daily scrum, is a
15-minute meeting that is held daily. Its purpose is to make a
synchronization point on the current development tasks and to plan
the next 24 hours. They call me Daily Scrum.
The Sprint Review brings together the entire Scrum team around
a demonstration of the deliverable provided at the end of Sprint. It
lasts up to 4 hours for a one-month Sprint (2 hours for a 2-week
The demonstration of the work of the development team allows
to make the point of progress of the project and to foresee the
possible adjustments of contents or trajectory to be carried out in
the following Sprints.
The purpose of the Sprint Retrospective is to analyze how the
work of the Scrum team has gone, with a view to possibly considering
improvements. With a maximum duration of 3 hours for a Sprint of one
month, it gives the team members the opportunity to express their
feelings about the good or bad progress of the Sprint.
The method defines a number of written reference documents
The Product Backlog, or simply Backlog, contains all the needs
of the Product Owner translated as User Stories. These User Stories
are independent features to be performed by the development team and
have business value. The Backlog is ordered by decreasing business
value. User Stories with the largest business value are processed
first. So we quickly get an application with high business
The Sprint Backlog is the list of User Stories that will be
processed during a Sprint. They come from the Product
Each User Story is divided into tasks that must be performed
by the development team. This fairly fine division will make it
possible to follow the progress of the team during the Daily
The Sprint Backlog is often represented on a board called the
Scrum Board, on which are added post-it cards corresponding to the
User Stories and related tasks.
In order to better communicate the information to the members
of the Scrum project, we can complete the Sprint Backlog table by
creating a graph: the Burn Down Chart.
The duration of the Sprint is plotted on the abscissa and on
the ordinate the sum of the complexities of User Story is reported.
We also add a linear curve representing the ideal complexity to
solve per day from the beginning to the end of the Sprint.
The development team can after each Scrum Meeting, postpone
what remains to be done on the chart and compare its position with
the rest to perform ideally.
The Burn Up Chart is another graph that allows you to
visualize the business value developed as the project
For this graph, we have in the abscissa the expected duration
of execution and in ordinate the sum of the traded values during the
Sprint. There is also a curve showing the business value to be
The chart is updated at the end of each Sprint. Once you have
reached 80% of the overall business value of the project, it is
interesting to ask the question whether to continue the project for
the remaining 20%.
The diagram above represents in a visual way, the different
elements of the method in order to show its life cycle.
In order, we have the following steps:
The Product Owner writes the User Stories and places them in
the Product Backlog.
The Product Owner prioritizes User Stories using their
At the Sprint Planning Meeting, the Scrum team determines
which User Stories will be processed during the Sprint. These are
then divided into tasks.
The Sprint starts and will last 2, 3 or 4 weeks.
The team meets daily for the Scrum Meeting.
At the end of the Sprint, the team demonstrates the
potentially deliverable product during the Sprint review.
At the end of the cycle, the Sprint Retrospective takes place,
which reports on the good or bad progress of the Sprint for the
A Scrum team is composed of three essential actors whose roles we
The Scrum Master who makes sure that the team is functional and
that the Scrum method is well applied.
The Product Owner who is responsible for the product vision and
prioritizes the needs.
The development team, self-organized and responsible,
responsible for developing the application.
The Scrum Master is the host of the Daily Scrum but it is
essential to remember that he is not a project manager.
In fact, he is a facilitator who verifies that the method is well
applied, that the obstacles are lifted and that the team is able to
He does not have the following roles: lead the team, distribute
tasks or report.
The responsibilities of the Scrum Master are in fact the
In relation to processes:
The Scrum Master is the guarantor of the application of the
Scrum method. He must make sure that the rules are adopted by
He works closely with the Product Owner in the writing of the
Thirdly, he has to make sure that there is a very good
cooperation between the members of the project.
Driving the change:
The Scrum Master must facilitate the transition from the
traditional and hierarchical project management model to the Scrum
method where there is no longer a project manager. This passage is
difficult and requires to shake the habits of the company.
Serve the Product Owner and the team:
The Scrum Master, given his knowledge of the method and the
tasks of the Product Owner, is able to propose people for this role.
However he does not have the right to impose on someone because this
is not the philosophy of Scrum.
Scrum aims to make the team autonomous and responsible. The
Scrum Master must ensure that she works in a quality environment and
remove any obstacles that diminish its effectiveness.
He is also the protector of the team. He must protect the team
of a Product Owner too demanding, wanting to have features as
quickly as possible. He must therefore "crop" the Product Owner by
reminding him that the team is working hard and that it can not go
faster on pain of botching his work.
The Scrum Master has the responsibility, in addition to those
already mentioned, to animate Scrum ceremonial meetings. These are
Sprint Planning, Daily Meeting, Sprint Magazine and
The skills required for the role of Scrum Master are:
In-depth knowledge of the Scrum method
Have leadership skills to be able to guide the team and
To be a good communicator, so that ceremonial takes place in
the expected time
Have mediation skills to resolve conflicts between members of
the team itself or between the Product Owner and the team.
Play transparency, ie know how to recognize before the
management teams if a project is early or late
Have humility in the event of a successful project, do not
accuse the team in case of failure and be involved in the project,
despite the efforts that it requires
The term Product Owner is difficult to translate. The Product
Owner is the representative of the product vision towards the Scrum
Master and the team. It centralizes all the needs of the users. The
translation of "product owner" is therefore not good. We prefer to
translate it by Product Manager, which will ultimately be better.
The Product Owner's responsibilities are as follows:
Create the product vision:
By using different workshops, the Product Owner has to define
the product vision that addresses one or more problems and it must
be driven by objectives.
This vision must be shared and carried by users, and allow
them to project themselves into the future. The Product Owner will
then be the spokesperson of the latter towards the Scrum Master and
the development team.
Manage the Product Backlog:
The Product Owner is responsible for writing User Stories and
their prioritization. This task is very tedious and requires a lot
The Scrum Master can help with this task by facilitating
workshops or advice. However, the Product Owner remains solely
responsible for prioritizing any feature within the entire Product
Define the release plan:
A Release is a goal to achieve through multiple Sprints. The
Scrum Master and the development team can not commit to the delivery
date and scope of a release. It is the role of the Product Owner to
define the scope of a release and its delivery date.
Get involved in the Scrum method:
The Product Owner needs to be involved in the Scrum process by
participating in all the ceremonies, but also by collaborating with
the development team.
For some Scrum projects, it must be available at 3 / 5ths or 4
/ 5ths of its time.
Whether to accept the result of a Sprint:
At the Sprint review, the Product Owner has the right to
accept or reject the delivery made by the development team. For
this, he uses his own criteria but he shared with members of the
The Product Owner has the power:
On the second point, it should be pointed out that changing
priorities and functionalities is no longer possible once Sprint is
The role of Product Owner requires the following skills:
Possess the functional knowledge of the product to be
Have a short, medium and long term vision of the
functionalities to be developed as well as their
Being able to make decisions to decide between user
The main function of the development team is to realize the User
Stories contained in Sprint Backlog.
She also has the following responsibilities:
Achieving the Sprint goal:
The team must achieve the intended goal when planning Sprint.
This means that all the User Stories contained in the Sprint Backlog
have been completed.
Live the Daily Meeting fully:
The Daily Meeting allows team members to discuss what they
have done the day before, what problems they have encountered and
what they plan to achieve this day. They should not miss this daily
appointment under any circumstances.
Realize the Burn down Chart and make the Sprint Backlog
The Burn Down Chart allows the development team to visualize
what remains to be done for the current Sprint. Normally, she is
responsible for creating this graph.
On the other hand, the team can make the Sprint Backlog live
by writing, on the Scrum Board that represents it, the progress of
each task (to be done, in progress, completed).
The number of people on a development team is of real
importance for the application of the Scrum method. A team of 5 or 6
people is able to self-organize, but beyond this figure, it's rather
Having a team of heterogeneous skills and experiences is also
The purpose of self-organization is to enhance the team's
degree of responsibility during Sprint. It's about letting the team
decide. Each member of the team is therefore able to choose the task
they will perform and the technical aspect of it.
This self-organization has 2 advantages:
A better estimate: being responsible for a task makes it
possible to estimate it better and to anticipate possible
Better efficiency: being responsible for a task gives a
feeling of autonomy and brings more motivation.
However, the team's decision is limited to How to do it? and not
what to do? which is the responsibility of the Product Owner.
To make good decisions the team must have the necessary means in
machines and at the level of the working environment. This
implementation is the responsibility of the Scrum Master.
The environment in which the team works must be conducive to
communication and exchange. It must also be effective in everyday
To function properly, a team must be at one point and the Scrum
Board must be visible to the entire team.
Discussions on a technical point or concept can occur at any time.
The team must be relatively isolated to allow exchanges and also not to
be distracted by external elements.
It sometimes happens that team members are not in the same
geographical location. If this is not preventable, you can use video
conferencing systems but it is harmful for the application of the Scrum
method. Indeed, the distance will still be present and the discussions
will be less spontaneous.
That the Product Owner is in the same office as the team is not a
good thing. Indeed, it would interfere in conversations to give its
opinion on developments already made. After a while, this would prevent
the team from becoming self-organized.
Do not isolate the Product Owner because he must be constantly
searchable by the team in case of misunderstanding on their part and he
must be able to view the table of tasks to check the progress.
However, the Product Owner must respect the team and can not scold
her during Sprint if he realizes that the advancement is not at the
As with the Product Owner, it's not good for managers to be too
close to the Scrum development team.
For the team to self-organize, managers must be kept apart because
someone in the hierarchy has a great influence on people's
However, do not exclude them completely from the Scrum process.
They can be invited to the Sprint retrospective when everyone takes
stock of what has or has not worked in their team. Their opinion can
then be heard.
Writing the Product Backlog
What is Sprint 0? This is not a set of tasks to achieve. This is
actually a period of preparation before starting the first Sprint. Hence
its name, Sprint 0.
We must perform the following tasks in Sprint 0:
Constitution the Scrum Team (Product Owner, Scrum Master,
Writing the Product Backlog
Product Backlog Prioritization
Sprint Estimation and Planning
Implementation of any necessary element at the beginning of
Sprint 0 (installation of development environments, purchase of
licenses, implementation of versionning repositories ...)
The Product Backlog, produced by the Product Owner, contains all
the features requested by users. These are translated as little stories,
these are the User Stories.
A different method:
As a "customer", we used to write detailed functional
specifications that allowed us to express needs more or less well.
We must learn a new method.
Have a global vision of the product:
It is necessary to acquire the global vision of the product to
engage in the writing of the Product Backlog. This is achieved by
the following steps:
The easiest way to do this is to map business processes and
The vocabulary: User Story, Epic and Theme:
The Scrum method defines 3 terms in relation to the expression
A User Story is the written translation of a specific user
need. For a person from an accounting department, it would be for
"I want VAT to be automatically calculated on
An epic is a "macro" user story. That is, it groups a subset
of User Stories. In relation to the previous User Story, we could
have the following Epic:
"I want my bills to be established automatically."
And finally, themes can be defined as a collection of User
Stories and Epics.
Still with the same example, we would have the following
These 3 notions must be well controlled by the Product Owner
in order to perform a logical division of the requested
How to write User Stories and Epics?
Use Case versus User Stories
We sometimes mix the notions of Use Case (UML use case) with
the User Stories of the Scrum method.
First, remember what a Use Case is. When designing an
application, a usage case diagram is often derived from reading
detailed functional specifications.
The diagram describes the interactions between users and the
system itself. It is rich in information (preconditions ...) and its
visual nature leaves little room for discussion.
On the other hand, its reading away from natural language and
requires training in UML.
This diagram requires a long study of the functional
specifications, study which lengthens the time of realization of the
project. Updating this diagram requires a specific tool.
The Scrum method proceeds in a different way.
In fact, Scrum is based on the human relationship and so we
sought to express the need in a precise way but in a language
understandable by all.
Scrum favors for each feature to transcribe on a map (8 cm x
13cm size), in natural language and with the following
I can / I have to ...
In order to ...
Here are some examples of User Stories listing features of an
online movie booking application:
The wording of the User Stories is as you see it rather short
and written so as to show the purpose of the action
Rule of 3 C
This rule describes the formalism seen previously.
||The User Story is written on a map to facilitate
identification, content writing, and manipulation during the
||The User Story must trigger a discussion between
||We add here a notion related to acceptance tests.
Confirming a User Story means that it is verifiable by
Quality goes through INVEST
To be sure that a User Story is satisfactory on form and on
the bottom, Scrum uses in addition to the previous rule, the method
INVEST (Independent, Negotiable, Valuable, Estimable, Small,
||You must avoid introducing dependencies between each
||A User Story is not fixed in time, so it is not
necessary to include all the details.
||Each User Story must have a business value that
represents the interest of the feature for the
||The User Stories must be explicit, in order to be
subsequently estimated at the level of their difficulty by
the development team.
||The expression of a User Story must be made with a
limited number of words.
||A User Story is only viable if it is
User Stories that respect these points can enter the Product
How to collect User Stories?
The writing and prioritization of the User Stories is the
responsibility of the Product Owner, but all users must be involved
in the process of defining User Stories.
For this, the Product Owner must lead participatory workshops
where everyone can express themselves.
In general, we rely on the process mapping done in the
prerequisites and we propose to everyone to express themselves on
Question: "What features do you want to see implemented for
the accounting area"?
Answer: "As an accountant, I would like to have a 3-year
account history so I can be quick in a check. "
The Product Owner can set up different types of meetings
(interview of several users, brainstorming, ...) to obtain User
Stories. However, each must respect a schedule defined in
The Product Owner is often alone when carrying out this task,
which we believe is the most important of the Scrum method because
it defines the content of the product to be produced. The Scrum
Master can help him, especially to validate the finesse of the User
Stories but also by giving him tips for conducting participatory
During the writing of User Stories, there is no concept of
scheduling to respect, because it will be realized in a second
In this article, we first introduced the Scrum method globally. We
saw the composition of the team, the events that punctuate a Scrum
project, and the artifacts, which are reference documents.
Since Scrum is human-based, we then described in detail the
different roles of a project team.
Finally, we were interested in a crucial document Scrum method, the
Product Backlog, document that contains all the features requested by
Website: http: //laurent-audibert.developpez.com/Courses-UML/? Page
Book: Scrum, an agile method for your projects (ENI editions)