Plan du site  
pixel
pixel

Articles - Étudiants SUPINFO

SCRUM method part 2: definition of the method

Par Christian DESTREMAU Publié le 12/11/2017 à 23:07:59 Noter cet article:
(0 votes)
Avis favorable du comité de lecture

Introduction

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

Overview of Scrum

Birth of Scrum

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

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.

Scrum in brief

We will now focus on the principles implemented by the Scrum method.

  1. 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 correctly applied.

    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 project manager.

  2. 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 productivity.

    The Scrum method sets up five events:

    • Sprint

    • Sprint Planning Meeting

    • Daily Scrum meeting

    • Sprint Review

    • Sprint Retrospective

    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 Sprint).

    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.

  3. Artifacts

    The method defines a number of written reference documents called artifacts.

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

    The Sprint Backlog is the list of User Stories that will be processed during a Sprint. They come from the Product Backlog.

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

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

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

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

Scrum life cycle

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:

  1. The Product Owner writes the User Stories and places them in the Product Backlog.

  2. The Product Owner prioritizes User Stories using their business value.

  3. At the Sprint Planning Meeting, the Scrum team determines which User Stories will be processed during the Sprint. These are then divided into tasks.

  4. The Sprint starts and will last 2, 3 or 4 weeks.

  5. The team meets daily for the Scrum Meeting.

  6. At the end of the Sprint, the team demonstrates the potentially deliverable product during the Sprint review.

  7. At the end of the cycle, the Sprint Retrospective takes place, which reports on the good or bad progress of the Sprint for the team.

The Scrum team

A Scrum team is composed of three essential actors whose roles we will describe:

  • 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

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

He does not have the following roles: lead the team, distribute tasks or report.

The responsibilities of the Scrum Master are in fact the following:

  1. 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 everyone.

    He works closely with the Product Owner in the writing of the Product Backlog.

    Thirdly, he has to make sure that there is a very good cooperation between the members of the project.

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

  3. 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 Retrospective.

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

  • 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 Product Owner

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:

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

  2. 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 of work.

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

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

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

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

The Product Owner has the power:

  • to choose the content of the Product Backlog and that of the different Sprints and Release

  • to change priorities and features for each sprint

On the second point, it should be pointed out that changing priorities and functionalities is no longer possible once Sprint is started.

The role of Product Owner requires the following skills:

  • Possess the functional knowledge of the product to be produced

  • Have a short, medium and long term vision of the functionalities to be developed as well as their prioritization

  • Being able to make decisions to decide between user desideratas

The development team

The main function of the development team is to realize the User Stories contained in Sprint Backlog.

She also has the following responsibilities:

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

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

  3. Realize the Burn down Chart and make the Sprint Backlog live:

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

    Having a team of heterogeneous skills and experiences is also important.

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

  • 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 work environment

The environment in which the team works must be conducive to communication and exchange. It must also be effective in everyday tasks.

  • Gather to win

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.

  • Case of a fragmented team

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.

  • Isolate the Product Owner

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

  • Remove the managers

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

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

The Sprint 0

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, Development Team)

  • 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

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.

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

  2. 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:

    • Identification of the overall process

    • Identification of actors

    The easiest way to do this is to map business processes and insert features.

  3. The vocabulary: User Story, Epic and Theme:

    The Scrum method defines 3 terms in relation to the expression of needs:

    • User Stories

    • Epics

    • Themes

    A User Story is the written translation of a specific user need. For a person from an accounting department, it would be for example:

    "I want VAT to be automatically calculated on invoices".

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

    "Accounting"

    These 3 notions must be well controlled by the Product Owner in order to perform a logical division of the requested functionalities.

How to write User Stories and Epics?

  1. 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 formalism:

    As…

    I can / I have to ...

    In order to ...

    Here are some examples of User Stories listing features of an online movie booking application:

    • As a user I can consult the list of films to know what's new

    • As an administrator I can add a film to the collection to offer a wide choice of films

    The wording of the User Stories is as you see it rather short and written so as to show the purpose of the action envisaged.

  2. Rule of 3 C

    This rule describes the formalism seen previously.

    Table 1. 

    Card The User Story is written on a map to facilitate identification, content writing, and manipulation during the planning phase.
    Conversation The User Story must trigger a discussion between users.
    Confirmation We add here a notion related to acceptance tests. Confirming a User Story means that it is verifiable by tests.

  3. 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, Testable):

    Table 2. 

    Independent You must avoid introducing dependencies between each User Story.
    Negotiable A User Story is not fixed in time, so it is not necessary to include all the details.
    Value Each User Story must have a business value that represents the interest of the feature for the users.
    Estimable The User Stories must be explicit, in order to be subsequently estimated at the level of their difficulty by the development team.
    succinct The expression of a User Story must be made with a limited number of words.
    Testable A User Story is only viable if it is testable.

    User Stories that respect these points can enter the Product Backlog.

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

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

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

    During the writing of User Stories, there is no concept of scheduling to respect, because it will be realized in a second phase.

Conclusion

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

Bibliographical references

Website: https://userresearch.blog.gov.uk/2016/06/22/doing-discovery-close-to-home/

Website: http://www.scrum-institute.org/Sprint_Burndown_Reports.php

Website: https://pm.stackexchange.com/questions/652mé9/how-does-one-build-a-burnup-chart

Website: http://gpp.oiq.qc.ca/le_cycle_de_vie_d_un_projet.htm

Website: http: //laurent-audibert.developpez.com/Courses-UML/? Page = case-use-diagram

Website: https://silkandspinach.net/2005/01/27/turning-requirements-into-user-stories/

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