Scrum method was designed in software development projects. It can also be used by maintenance teams. In the case of very large projects, teams multiply and it is called Scrum of Scrums. Scrum method can theoretically be applied to any context where a group of people works together to achieve a common goal like planning a wedding, managing scientific research projects, schools and even churches as specified in the website of its main promoter Jeff Sutherland.
The basic principle of Scrum is to focus the team on a limited and controllable features to achieve. These increments are carried out successively during periods of fixed duration of one to four weeks called sprints. Each sprint has, prior to its execution, a goal from which we select the features to perform in this iteration. A sprint always leads to the delivery of a partial working product.
Person responsible for completing and keep up to date the product backlog. It sets priorities and makes decisions in project direction. As such, it is the representative of the final customer / end user and is responsible for collecting needs. He is also responsible for validating the operation of the product.
Member of the team whose main objective is to protect it from external disturbances. He is completely transparent to the communication between the team and the customers and has no authority over the team. However this is a facilitator for the non-technical problems of the team. Thus, it will ensure that the method is well understood and applied by the rest of the team.
The team has no predefined roles, it is self-organized and multidisciplinary. Each team member chooses the tasks he performs according to the sprint backlog. The team must have all needed skills to achieve the realization in order to make internal decisions together. His responsibility is to provide a working product at each iteration.
Earliz helps you to create quickly a team by a simple user « drag’n’drop », to manager the weekly planning of all members, and to delegate the management of the team directly to the designated Manager or Scrum master.
In Scrum method, the project is divided into features also known as User Stories. The backlog is the list of successive features to make in order to create or complete the product.
Feature or User Story
Each feature consists of a description, an estimation (see below) and a priority. The product owner may change this information and its prioritization at any time.
The term User Story comes from the method Extreme Programming (XP) and is often associated with the Planning Poker (see Planning poker).
At every sprint, we choose a subset of the product backlog features to achieve. The realization of these features is made to reach the goal defined at the beginning of this sprint.
Each feature is then divided into tasks that can be performed by different members of the team.
Scrum does not define special units for backlog items. However, some techniques have been popularized. The most common is the estimation in relative points retrieved from the User Stories in XP. The team selects a User Story as standard to which he assigns arbitrarily a number of points. The following features will be estimated relative to this standard: a User Story worth 2 points needs twice more work than one worth 1 point.
We often use the initial values of the Fibonacci sequence (1,2,3,5,8,13,21) to avoid close values and keep features of acceptable size. Indeed, a feature estimated to 40 points will be more realizable if it is divided to obtain estimations of maximum 21.
By choosing a Scrum mode while starting project online, Earliz helps you to manage easily the priorities of each story, and all sprint iterations.
A sprint is an iteration of one week to one month maximum. A working product must be available and presented at the end of each sprint. A new sprint starts as soon as the previous one is finished.
At the beginning of each sprint, we define a goal and we associate a list of features that constitute the sprint backlog. During a sprint, the goal and the composition of the team can not be changed. In the opposite, the content of the sprint backlog may be reviewed by the product owner and the team.
Each sprint has several milestones:
This meeting is used to construct the sprint backlog. Based on the prioritized product backlog provided by the product owner, the team will decide a sprint goal. The features are then estimated, if they have not been at the Planning Poker. The sprint backlog is then filled with the features allowing to achieve this goal while ensuring that the velocity of the team (see Velocity) in the previous sprints is respected.
Depending on the choice of the team, features are divided into tasks during the sprint planning or during the various daily scrum.
Performed at the beginning or end of the day, this daily meeting is an update on the progress of current tasks. The meeting lasts up to 15 minutes.
Each team member must list the tasks he completed the previous day, those he intends to do the day to come and if he encounters difficulties. In the case of Scrumban, the kanban is used as a support for this meeting.
Demonstration or sprint review
At the end of a sprint, the team must demonstrate that their product is working and that they have reached the goal. The product owner is attending this meeting to validate that the working product matches with the expected result.
Depending on the outcome of this meeting, the product backlog is updated and features are adapted or re-estimated.
Only the team participates (not the product owner). The retrospective aims to raise the problems faced by the team during the sprint and to suggest ways for improvement. This meeting is part of the continuous improvement process of Agility and aims to increase productivity and product quality.
This method allows you to add rhythm to Kanban by associating the sprints. In Scrumban, the entire Kanban is updated at the beginning of the sprint with all tasks placed in the "to do" column. At the end of sprint, all tasks must be in the "done" column.
Scrumban provides a tabular representation of the sprint backlog. Each task of the sprint evolves on the board depending on its status: to do, in progress, ..., done. The Kanban then participated in improving the vision of the project team.
Earliz helps you to manage and visualize all your tasks within a Kanban board that can be modified in real time by all team members.
The planning poker is a fun and effective way to produce estimations of the complexity of features. The main advantage of planning poker is to allow everyone to express themselves freely. The estimation will be better because several people have validated it: participants with different levels of experience and expertise. In addition, this technique encourages exchanges between the product manager and the team. The assessment is made in relative points by using a card game representing the initial values of the Fibonacci sequence (see Estimations).
- Participants sit around a table, placed so that everyone can see each other.
- The product owner explains to the team a feature or User Story.
- Participants ask questions to the product owner, discuss the scope of the feature, refer to the criteria that allow to considered it as "done".
- Each participant evaluates the complexity of the feature, chooses the card that corresponds to the estimation and puts it, face down, on the table in front of him.
- At the signal of the Scrum master, cards are returned at the same time.
- If there is no unanimity, discussion starts again.
- The process is repeated until an estimation gets the unanimity.
This graph shows you the decreasing trend of ideal points to realize each day of the sprint. On the right side is added the actual values of the achieved points. It is updated frequently during the daily scrum.
The burndown chart allows you to quickly visualize if the team is ahead or behind the schedule it has set. Thanks to him, the team may decide at any time to review the sprint backlog to add or remove features.
At the end of each sprint, the team velocity is calculated. This value corresponds to the sum of the estimations of the features completed during the sprint. The average velocity of a team is particularly interesting to know during the sprint planning. It is then easier to know the number of User Stories that can be performed during next sprints.
Earliz helps you to go through this continuous improvement process using follow-up metrics, automatically calculated online based on team activities, in order to follow your project progress in real-time and to identify quickly main issues.