Introduction to Scrum

History of Scrum

Since the publication of Winston Royce's "Managing the Development of Large Software Systems" report in 1970, many have tried to find a methodology that could eliminate the disadvantages of the Waterfall development model. An alternative to the “waterfall” was the Scrum method, which will be discussed now.

Scrum got its name in 1986 from Takeuchi and Nonaki's work The New Rules for New Product Development. This document argues that the most effective way to achieve the goal is to give developers a clear plan of action.

In 1995, another guide, "Software Development with Scrum," by Sutherland and Schweiber, appeared. This publication has since been updated several times. Now it is considered the main guide for the development of this method. The current version of the Scrum Guide contains information updated in 2020.

The main provisions of the Scrum Guide suggest that the project management template should be based on the fact that developers deliver the finished product within the agreed time frame - sprints. For the successful implementation of Scrum, it is recommended to use a structure consisting of several elements: roles, events, rules, and artifacts.

Roles in Scrum

There are three roles in Scrum, all of which form a Scrum team:

The customer of the software product is the most important person in the project, because only he fully understands its value to the business. The customer explains the needs of the users of the future product to the developers, but he is not responsible for the technical part of the development process. The customer also determines the priority when creating certain elements or functions in the product.

The developers are entrusted with the implementation of technical tasks, the cross-functionality of which depends on the scope of application. Developers are busy creating the sprint backlog, writing code, tailoring the project to the sprint goal, and other tasks.

The Scrum Master is the facilitator of the Scrum team. It provides assistance to the customer and developers. Simply put, the Scrum Master is busy communicating between those who are not involved in the project and the people writing the code. Sometimes different teams of coders in the same large company communicate and coordinate at general meetings of the scrum masters of these teams.

Events in Scrum

There are 5 types of scrum events:

Sprint is the most significant part of Scrum. It includes sprint planning, daily stand-ups (daily scrum), review and retrospective of the sprint.

Sprint planning. All members of the Scrum team take part in drawing up a plan for the future sprint. It is here that the product idea is presented and each team member can express his opinion, what he thinks about this. Then at the meeting, priorities are determined and deadlines are announced.

Daily Scrum is a daily short scrum event, lasting no more than 15 minutes. Usually it is done to plan the work of encoders for today or tomorrow. At the Daily Scrum, you can discuss current issues. All developers involved in the project are required to participate in such a workshop. The presence of a Scrum Master is allowed, but not required.

Sprint Review (Demo) - Show results created during the sprint. Usually this event takes place at the final stage. All interested persons take part in it.

Sprint Retrospective - discussion of the results of the sprint. Team members share their opinion on how they coped with the tasks assigned to them and how to improve the results of work in the future.

In addition, backlog refinement is sometimes carried out - Backlog Refinement. It discusses backlog items, preparing for the next sprint, and prioritizing current tasks.

Artifacts

Scrum artifacts are the work that happens at the end of a project or sprint. There are three artifacts - the product backlog, the sprint backlog, and the increment. Each of them is needed for the timely delivery of software to users. There are also auxiliary artifacts (burn down charts and more).

Components included in sprint artifacts:

Product backlog - interface and backend features.

A sprint backlog is a list of tasks that need to be done during an iteration. They are agreed before the start of the sprint.

Increment - The total number of software backlog items created during the sprint and the value of the increments that were made before it. The finished new increment must be shown before the end of the sprint. This means that you have a working version that meets the requirements of the scrum team.

Product backlog item - it must be completed during the sprint iteration. As a rule, the element is divided into several small tasks.

The sprint goal is the tasks that need to be completed (create a backlog item or other task).

A sprint burndown is the work left before the end of a sprint. The burn down chart is either ascending or descending. It all depends on the difficulties that team members face while working. It is not an indicator of progress, but only a way to solve problems and an incentive.

Product Release/Product Burn-Down Chart is a chart drawn by the Scrum Master before the end of the next sprint. The horizontal axis is sprints, the vertical axis is the amount of work left.

Scrum framework rules

Roles, events and artifacts are the basis of Scrum, but there are other rules besides this. All of them enhance the efficiency of the work process. Here is a list of those rules:

• The scrum team includes the software customer, scrum master, and developers.
• All sprints should be the same length.
• After completing one sprint, work on a new one immediately begins.
• A sprint always starts with a plan.
• Team members have a morning scrum at the start of their work day.
• Each sprint is reviewed during each sprint. This improves communication between the team and stakeholders.
• It is not recommended to change the sprint backlog during the sprint.

Limitations in Scrum

Along with the obvious advantages, Scrum also has disadvantages:

• Scrum often leads to a decrease in the amount of work performed due to the lack of a common deadline.
• With low involvement or unwillingness to cooperate among the project participants, there are considerable chances to fail the result.
• Scrum structure is difficult to use in large teams, but still it is possible. There are scaling frameworks for this: LeSS, SAFe, Nexus and others.
• The departure of one or more members from the team in the middle of the project does not affect the project very well.