What is Scrum and how can you use it in your work?

If you have started to explore the role of a Business Analyst or have already become a junior specialist, you have definitely heard about Scrum many times. Teams frequently claim to "work following Scrum" but, in reality, they use only some of its attributes.

Let's consider what Scrum actually is, and how it differs from Agile.

What is Scrum?

There is a common opinion that Scrum is a software development methodology. Is that accurate?

According to the definition from the Scrum Guide, Scrum is a "lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.” The Guide further explains that “each element of the framework serves a specific purpose that is essential to the overall value and results realized with Scrum."

The Guide describes the key components, roles, and principles of Scrum, and defines the connection between different elements: "Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions."

As the official definition indicates, Scrum is a framework, not a methodology. The difference between the two is that a framework provides a general structure and principles, while a methodology offers specific recommendations and instructions for performing tasks or processes.

What is the difference between Scrum and Agile?

Agile (Agile Software Development) is a philosophy, a way of thinking, and a set of principles described in the Agile Manifesto, which consists of four main values and twelve principles.

The main idea of Agile is to prioritize flexibility, collaboration, and responsiveness to change during the software development and project management processes. Special attention is given to iterative and incremental development, involving clients in the process, and adaptive planning to deliver value quickly and efficiently.

Scrum is a framework that helps implement Agile principles in project management. Thus, Agile is a broader philosophy or approach that covers various frameworks and methodologies, including Scrum, Kanban, Lean, Extreme Programming, and others.

The Scrum Guide states that "Scrum employs an iterative, incremental approach to optimize predictability and to control risk." What does this mean?

An iterative approach involves iterations or cycles. In the context of software development, an iterative approach divides the entire development process into a series of repeating cycles. In each cycle, all necessary stages of the Software Development Life Cycle (SDLC) take place within a short period of time. Within Scrum, a Sprint is a form of iteration. A Sprint is a fixed time period, typically between 1 and 4 weeks, during which the team develops and delivers a completed increment of the product. During the Sprint, all stages of development — from planning to testing — take place, and then a new Sprint begins.

An incremental approach is one in which the product is divided into fully functioning parts — increments. Instead of completing the entire product and releasing it in its final form, development occurs incrementally: each stage brings a new Increment that is added to the existing product. In one Sprint, for example, you may develop a product catalog, in the next one — a shopping cart, and in another — integration with a payment system. This continues until the entire product is ready.

As the Guide explains, the “entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.”

The structure of the Scrum framework

Now, let's take a closer look at the structure of the Scrum framework.

Scrum Events

The Scrum Guide defines five key events:

• Sprint: This event contains all the work and other events that occur within a time-limited development period. The duration of a Sprint is typically between 1 and 4 weeks.
• Sprint Planning: This starts the Sprint. The work to be done in the Sprint (Product Backlog items to be included in the Sprint) is identified and planned. The Sprint goal (often a business problem to be addressed) is determined, and a plan for its implementation is created. Together, this is called the Sprint Backlog, which is the outcome of this event.
• Daily Scrum: This is a daily event for the developers within the Scrum team. The point of the Daily Scrum is the inspection and tracking of progress towards the Sprint goal, and the adjustment of planned work as necessary.
• Sprint Review: This event involves reviewing the outcome of the Sprint — Increments — and assessing the impact of the work completed on the overall progress towards the Product Goal. This maximizes the value of the next Sprint.
• Sprint Retrospective: This finalizes the Sprint. Its purpose is to examine the Sprint and plan improvements to be implemented during future Sprints.

There is another event, not mentioned as mandatory in the Scrum Guide, but important for achieving the Product Goal. It is known as Product Backlog Refinement. An inexperienced eye may not identify it while reading the Scrum Guide, but it is actively used in projects. During this event, the team collaborates with the product owner to refine the Product Backlog items. Backlog Refinement is conducted to ensure that these items have sufficient detail, are properly decomposed if necessary, and are prioritized and ready for review during Sprint Planning.

Scrum Artifacts

The following concepts are considered Scrum Artifacts:

• Product Backlog consists of an ordered list of work/tasks that need to be completed to improve the product. In the context of any project, it represents a prioritized list of all possible necessary tasks (e.g., user stories, bugs, technical tasks, etc.).
• Sprint Backlog is a plan created by and for the developers. It includes:

- Sprint goal: why we need this Sprint.

- Set of selected Product Backlog items for the Sprint: what exactly we will be doing within the Sprint.

- Plan for delivering the Increment: how we will accomplish it.

• Increment is defined in the Scrum Guide as "a concrete stepping stone toward the Product Goal." An Increment refers to a small working piece of the Product that is ready at the end of each Sprint.

Scrum team

Another equally significant part of the framework is the Scrum team, a small group of people typically consisting of no more than 10 individuals. It includes:

• Product Owner: This is always the one person within the team who is responsible for maximizing the value of the Product developed by the team, and managing the Product Backlog.
• Scrum Master: The person who leads, guides, educates, and assists the team in properly understanding and implementing Scrum. A Scrum Master is also responsible for the team's effectiveness, helping improve the working methods within the framework. Only one person performs this role within the team.
• Developers: According to the Scrum Guide definition, these are the individuals in the Scrum team who are "committed to creating any aspect of a usable Increment each Sprint."

It's important to highlight that Scrum teams are cross-functional; members have all the skills necessary to deliver value in each Sprint.

The image shows how all of the Scrum elements interact with each other:

Conclusion

In the beginning of this article, I mentioned that many teams merely use certain attributes of Scrum — events, artifacts, and roles. But why doesn’t the usage of certain attributes mean that Scrum is truly being implemented in your team?

The Pillars of Scrum — Transparency, Inspection, and Adaptation — are integral to Scrum, as are its Values — Commitment, Openness, Focus, Respect, and Courage. These provide the foundation for a successful implementation of the framework and guide the behavior and mindset of the Scrum team.

When a team understands and implements the values, principles, and practices of Scrum, it moves from simply adopting particular attributes to proper usage.

The framework described in the Scrum Guide cannot be modified: “While implementing only parts of Scrum is possible, the result is not Scrum.”

You cannot claim that the team is implementing Scrum if:

• The team is unaware of or does not share the values of Scrum.
• There is no product goal, and Sprint goals are not established during Sprint Planning.
• There is no Scrum Master in the team who helps members understand how to properly apply the framework, and instead, there is only a project manager who is responsible for deadlines and budgets.
• Your team is not Agile and is not willing to adapt to change.

But who is to say that it's bad if such a modified approach helps you achieve your desired result?

Useful materials for study:

• Scrum Guide;
• Agile Manifesto; and
• Product Backlog Refinement: How to Succeed as a Scrum Team.