Scrum Methodology Overview

Обзор методологии Scrum

In one of the previous articles, I already wrote about the Scrum methodology and how to make a super team out of your usual team just in 4 steps. Today, I want to return to the Scrum theme and talk about the reasons for its popularity and the structure of the method. There is nothing super complicated, and the whole methodology can be described in one small article.

Scrum Foundation


There are only three roles in the Scrum methodology:

  • Scrum Master
  • Product Owner
  • Team

Scrum Master is the most important role in the methodology. Scrum Master is responsible for the success of Scrum in the project. In essence, Scrum Master is the interface between management and the team. As a rule, this role in the project is played by the project manager or team lead. It is important to emphasize that Scrum Master does not distribute tasks to team members. At Agile, the team is self-organizing and self-governing.

The main responsibilities of Scrum Master:

  • Creates an atmosphere of trust
  • Participates in rallies as a facilitator
  • removes obstacles
  • Visualizes and raises to the surface all possible problems
  • Responsible for adhering to the practices and process in the team

Scrum Master leads the Daily Scrum Meeting and tracks team progress using the Sprint Backlog, noting the status of all tasks in the sprint. Scrum Master can also help Product Owner create a backlog for the team.

Product Owner is the person responsible for product development. Typically, it is a product manager for product development, a project manager for internal development, and a customer representative for custom development. Product Owner is a single point of final decision for a team in a project, which is why it is always one person, not a group or committee. Product Owner’s responsibilities are:

  • Responsible for the formation of product vision
  • Manages ROI
  • Manages the expectations of customers and all interested parties
  • Coordinates and prioritizes Product backlog
  • Provides clear and testable requirements to the team
  • Interacts with the team and the customer
  • Responsible for accepting code at the end of each iteration

Product Owner sets tasks for the team, but he does not have the right to set tasks for a specific member of the project team during the sprint.

Team In the Scrum methodology. A team is self-organizing and self-governing. The team is committed to doing the sprint work for Product Owner. Teamwork is assessed as the work of a single group. In Scrum, the contribution of individual members of the project team is not assessed, as this disintegrates the self-organization of the team. The responsibilities of the team are:

  • Responsible for evaluating the elements of the backlog
  • Decides on design and implementation
  • Develops software and provides it to the customer
  • Tracks their progress (along with Scrum Master)
  • Responsible for the result before Product Owner

The size of the team is limited by the size of the group of people who can effectively interact face to face. Typical team size is 7 + – 2.

The team at Scrum is cross-functional. It includes people with various skills – developers, analysts, testers. There are no predefined and shared roles in the team that limit the scope of the team members. The team consists of engineers who contribute to the overall success of the project under their abilities and design needs.

The team organizes itself to perform specific tasks in the project, which allows it to flexibly respond to any possible tasks. To facilitate communication, the team should be in one place (colocated). It is preferable to place the team, not in “blocks”, but in one common room to reduce obstacles to free communication. The team must be provided with everything necessary for comfortable work, boards, and flipcharts, all the necessary tools and the environment for work.


Product Backlog

Product Backlog is a prioritized list of currently available business requirements and system technical requirements. Product Backlog includes use cases, defects, enhancements, technologies, stories, features, issues, etc. Product Backlog also includes tasks important to the team.

Product Backlog is constantly reviewed and supplemented – new requirements are included in it, unnecessary ones are removed, priorities are reviewed. Product Owner is responsible for Product Backlog. He also works with the team to get an approximate estimate of the performance of the Product Backlog elements to more accurately prioritize according to the required lead-time.

Sprint Backlog

Sprint Backlog contains the functionality selected by Product Owner from Product Backlog. All functions are divided into tasks, each of which is evaluated by the team. Each day, the team evaluates the amount of work that needs to be done to complete the tasks.

The sum of the estimates of the remaining work can be constructed as a chart of the dependence on time. This chart is called the Sprint Burndown chart. It demonstrates the progress of the team during the sprint.


In Scrum, the iteration is called Sprint. Its duration is 1 month (30 days). The result of Sprint is a finished product (build), which can be delivered to the customer (at least the system should be ready to be shown to the customer). Short sprints provide quick feedback to the project team from the customer. The customer gets the opportunity to control the scope of the system, evaluating the result of the sprint, and offering improvements to the created functionality.

Such improvements fall into the Product Backlog, prioritize along with other requirements, and can be scheduled for the next (or one of the following) sprints. During the sprint, all work is done to collect requirements, design, coding, and testing the product. Sprint scope should be fixed. It allows the team to commit to the amount of work that needs to be done in the sprint. It means that the Sprint Backlog cannot be modified by anyone other than the team.

At the beginning of each sprint, sprint planning is carried out. Sprint planning involves customers, users, management, Product Owner, Scrum Master, and team. Sprint planning consists of two consecutive rallies.

Sprint planning, first rally. Participants: team, Product Owner, Sсrum Master, users, management. Goal: Define the Sprint Goal and Sprint Backlog — the functionality that will be developed during the next sprint to achieve the sprint goal. Artifact: Sprint Backlog.

Sprint planning, second rally. Participants: Scrum Master, team. Purpose: to determine how specific functionality will be developed to achieve the sprint goal. For each Sprint Backlog element, a list of tasks is defined and their duration is estimated. Artifact: tasks appear in the Sprint Backlog If during the sprint it turns out that the team cannot complete the sprint, the Scrum Master, Product Owner, and the team meet and find out how to reduce the scope of work and achieve the sprint goal.

Sprint Abnormal Termination

Sprint stops in exceptional situations. Sprint can be stopped before the allotted 30 days. Sprint can be stopped by a team if it understands that it cannot achieve the sprint goal in the allotted time. Sprint can be stopped by Product Owner if the need to achieve the sprint goal is gone. After stopping the sprint, a rally is held with the team, where the reasons for stopping the sprint are discussed. After this, a new sprint begins: it is planned and work begins.

Daily Scrum Meeting

This rally takes place every morning at the beginning of the day. It is designed to ensure that all team members know who and what is involved in the project. The duration of this meeting is strictly limited and should not exceed 15 minutes. The purpose of the rally is to share information. It is not intended to solve problems in a project. All issues requiring special discussion should be moved outside the rally. Scrum Master holds Scrum rally. He asks questions to each member of the team in a circle:

  • What was done yesterday?
  • What will be done today?
  • What problems did you encounter?

Scrum Master collects all questions open for discussion in the form of Action Items, for example, in the format of what/who/when.

Sprint demo and review

Recommended duration: 4 hours. The team demonstrates the product increment created during the last sprint. Product Owner, management, customers, users, in turn, evaluate it. The team talks about the tasks set, how they were solved, what obstacles they had in their way, what decisions were made, what problems remained unresolved.

Based on the review, the host can conclude how the system should further develop. The rally participants conclude how the process went in a team and offer solutions to improve it. Scrum Master is responsible for organizing and conducting this rally. The team helps him to make an agenda and plan out who and in what sequence represents anything. Preparation for the rally should not take a lot of time from the team (as a rule, no more than 2 hours).

The methodology, as you have noticed, is replete with terms and may seem incomprehensible after the first reading. However, Scrum becomes much more understandable after the distribution of roles and the practical application of its tools. After the first Scrum Meeting and at the end of the first sprint, you will be surprised to find that everything works “as it should”: the tasks are clear and clearly defined, the priorities are set and met, in fact, as well as timing.