10 terms you must know to understand Scrum

If you’re in the tech industry, then you’ve surely heard of Scrum but, what exactly is it? In short, Scrum is an agile framework for project management designed around 5 core values: commitment, focus, openness, respect, and courage.

It is, without a doubt, the most popular framework of this kind used in software development. Almost everyone in the industry claims to use it, even if not everyone understands what it’s really about.

If you’re new to the industry, you might be overwhelmed by all the new scrum-related words being thrown around. However, one of the goals of Scrum is to be simple, so you shouldn’t feel intimidated by all the new jargon. Still, to help you stay in the loop, here are 10 essential terms you’ll need to know to understand Scrum.

1. Product Owner

Scrum is designed to work for small teams of no more than 10 people. Those teams are divided into three essential roles–a Product Owner, a Scrum Master, and a team of Developers–all of which hold the same importance and are equal in hierarchy. An essential part of Scrum is that, regardless of individual responsibilities, the whole Scrum team is, at the end of the day, accountable for a project’s success.

As per the latest Scrum Guide, the Product Owner (also called a PO) is the member of a Scrum Team that is “accountable for effective Product Backlog management” (don’t worry, we’ll get to what a Product Backlog is towards the end of the article).

What this means is that the Product Owner will have a big say in which tasks make it to the team’s to-do list, and they will do so while keeping in mind the views of many of the stakeholders that aren’t elsewhere represented in the Scrum Team.

2. Scrum Master

As we’ve just seen, the Scrum Master (often abbreviated SM) is one of the three roles that make up the Scrum Team. In short, the Scrum Master is responsible for helping the rest of the team–and the whole organization–understand and adopt Scrum practices, thereby improving its effectiveness.

The definition of the Scrum Master role has undergone a few changes since the Scrum Guide was first released. In fact, the Guide’s latest version[1], released in 2020, made quite a drastic change in this regard. While Scrum Masters used to be defined as “servant-leaders”, the new Guide describes them as “true leaders who serve the Scrum Team and the larger organization.“ It could be said that this change, in a way, elevated the role of the Scrum Master, taking it from a facilitating assistant-like role to one of an active leader.

3. Sprint

Sprints are one of the core concepts in Scrum, and one you’ll definitely hear all the time if you work in the software industry in any capacity.

To put it simply, a sprint is a period of time–usually around two weeks to a month–around which a project’s work is divided and organized. The key idea behind a Sprint is that, once a goal for the Sprint is decided on, no changes should be made that would affect it (unless it becomes obsolete, in which case the Sprint may be cancelled).

For that reason, once a team has decided which tasks they will work on during a given Sprint, they are unlikely to add new ones.

4. Sprint Planning

While we defined a Sprint, we briefly mentioned that, before starting one, the Scrum Team decides which tasks they will work on until the Sprint ends. This process happens during a meeting called a Sprint Planning.

The Sprint Planning, in fact, marks the beginning of a Sprint and its goal is to answer three questions: “Why is this Sprint valuable?”, “What can be done this Sprint?”, and “How will the chosen work get done?” With those three questions answered, the Sprint Goal and tasks should be clear enough to get things started.

5. Daily

A Daily Scrum, often referred to simply as a “Daily” is, as the name suggests, a meeting that is held every day, preferably at the same time and place. In it, the Scrum Team looks at how the Sprint Goal is progressing, and whether any adjustments need to be made in order to stay on track.

That said, daily meetings aren’t supposed to be long and time consuming. On the contrary, the Scrum Guide specifically states they’re supposed to only take 15 minutes. As for the structure of the meeting, the latest Guide offers complete freedom, as long as the meeting’s purpose is met.

6. Sprint Review

Sprint Reviews are held at the end of a Sprint, and they are also quite aptly named, as they serve to review the outcome of the sprint and plan for the future.

Unlike the previous meetings we’ve discussed where only the Scrum Team takes part, Sprint Reviews also include stakeholders. During these meetings, the team presents the work done during the sprint and where they are in regards to the Sprint Goal to stakeholders so they can then, together, decide on the next steps.

7. Retrospective

Sprint Retrospectives mark the end of a Sprint and are meant to act as a self-reflection tool for the team when it comes to the Sprint. As the Scrum Guide puts it, during a Sprint Retrospective, the team “discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved”.

From there, the team discusses what changes could be made to improve and prioritizes them, so they can be incorporated as soon as possible. Just as a product is supposed to be improved after each iteration of its development, the Scrum process also looks to improve itself after each Sprint.

8. Product Backlog

When we talked about Sprint Plannings, we mentioned that, during these meetings, the Scrum Team picks the tasks that will be addressed during the subsequent Sprint. However, we haven’t discussed where they pick those tasks from. The answer is the Product Backlog.

A Product Backlog is a list of tasks that are needed to reach the Product Goal. This list is ordered and can change and become more detailed over time. As a matter of fact, the Scrum Guide describes its refinement as an “ongoing activity”.

9. Sprint Backlog

Once a team has chosen the items from the Product Backlog that they wish to address during a Sprint, they are moved to the Sprint Backlog.

Other than the tasks that will be covered during a Sprint, the Sprint Backlog also includes the Sprint Goal and a plan to fulfil it. In essence, the Sprint Backlog serves as a guide for developers for the duration of this interval.

10. Increment

Finally, we come to the concept of an Increment, which is defined by the Scrum Guide as “a concrete stepping stone toward the Product Goal.” For a piece of work to become part of an Increment, it must fulfil something called a “Definition of Done”. This is a formal description of what an Increment must have to comply with a product’s requirements.

The ten terms above make up the core of Scrum terminology. Once you’ve got the hang of them (and we hope this article has helped you do just that), you should be able to sail through most Scrum-related conversations, whatever your role in the software industry is right now.