Scrum explained: the easiest understandable guide to scrum

You can't go to a dev conference, read most companies' LinkedIn posts, or watch anything about project management on YouTube without hearing the word "scrum" thrown around. "Scrum" is without a doubt a buzzword, but it's more than just a future-oriented marketing phrase.

So what is scrum, and how can your team use it? Let's dive in! 👇

What is scrum?

Scrum is a development methodology that falls under the "agile" umbrella. Agile methodologies rely on the idea that developers can build products faster by moving in 2 week "sprints" that provide structure and opportunities for planning, feedback & iteration as part of the working cadence.

The goal of scrum is for a development team to move faster. Scrum accomplishes this by breaking larger chunks of work down into sprints that teams work through, typically two weeks at a time.

Scrum history

Most people associate scrum with the 2010’s tech boom, but it’s stood the test of time for longer than you may think.

Developers worldwide started to talk about the need for scrum after a 1986 Harvard Business Review article "The New Product Development Game" explored the innovative ways companies like Fuji-Xerox, Canon, and Honda managed large-scale projects quickly. The word "scrum" comes from rugby (which featured heavily in the article).

The concept we know as scrum today came from the Easel Corporation, Jeff Sutherland, and Ken Schwaber. In 1993, they designed scrum by drawing inspiration from the 1986 article and the principles of Object-Oriented Development (OOD). Sutherland and Schwaber later presented the concept for scrum at OOPSLA'95 and in the book "The Scrum Guide."

Although scrum was developed over twenty years ago now, it continues to be relevant today. Millions of developers and companies worldwide use scrum, and it’s not hard to see why.

Scrum benefits

People use scrum because it is:

• Scalable. Teams can scale their work without compromising on the core concepts of scrum. Scrum works for everyone, from freelancers to multinational corporations.
• Focused on user needs. Teams start with clear user goals and product requirements, and throughout the scrum process, these are revisited.
• Flexible to change. You can adjust to changing requirements as you go to meet deadlines or react to new situations.
• Ideal for designing high-quality software. Scrum places emphasis on getting software functional before expanding features. The result is a better-built product.
• Good at bringing software to market quickly. Scrum encourages developers to release limited versions of software that they later expand on. The result is that users can start using the software quickly.

How the scrum methodology works

At this point, you understand the basics of scrum — but what does it look like in practice?

Let's start with team roles.

Team roles

The typical scrum team contains a small group of developers and other qualified individuals with the expertise required to build the product. Among those members, two people have special roles.

First, you have the Scrum Master (SM). This person acts as the team's leader and oversees each sprint. They are responsible for helping members stick to the scrum framework, keeping the sprint on track, and ensuring the sprint prioritizes users' needs. Sutherland describes the Scrum Master as the person who asks, "how can we do what we do better?"

Second, you have the Product Owner (PO). The Product Owner represents the users and product stakeholders throughout each sprint. They are responsible for keeping the product's vision alive and ensuring a Return on Investment (ROI).

Scrum is built on the idea that everyone involved with a project will work to five core values (courage, focus, commitment, respect, and openness) and use the 12 principles of agile development.

Scrum artifacts

Like many development methodologies, scrum teams use specific terminology to describe key things used in a scrum. Five of these terms you need to understand are:

• Product Backlog (PB). This is a list of all of the requirements the team needs to fulfill to make the client or system users happy. This list includes features and requirements. All items on the list are separated into categories that divide the most and least important items.
• Sprint Backlog (SB). This is a sub-list that contains all items a team will address during the current sprint.
• Increment. An increment includes all the work that a client or end-user will see or experience from each sprint.
• Sprint plan. This is a breakdown of who will work on each feature, when, and any other notes the team will need during a sprint.
• Scrum task board. This is exactly what it sounds like — a large board that includes all the information the scrum team needs (the product backlog, sprint backlog, sprint plans, user stories, use cases, etc.)

Process

When developers build a system with scrum, they divide the workload into sprints. Each sprint usually lasts two to three weeks and includes a set of features that developers must complete by the end of the sprint.

Before a sprint begins, the Scrum Master consults the product backlog. Then, they select which features will go into the sprint backlog, and the sprint begins. At the end of some sprints, developers release a new version of the software.

In short, the scrum process looks like this:

Research on 1,200 scrum teams conducted by Christiaan Verwijs and Daniel Russo shows that many factors influence the success of scrum. The largest of these factors include continuous improvement, management support, stakeholder concern, responsiveness, and team autonomy.

Scrum events

Scrum is famous for the ceremony-like events (ahem, lots of meetings) that scrum teams undertake. Meetings include:

• Sprint planning. During this event, developers plan which features they will address in the upcoming sprint. In some companies, sprint planning is the job of the Scrum Master and Product Owner. In others, sprint planning is collaborative.
• Daily Scrum. This daily stand-up-style event allows everyone to evaluate their progress over the past 24 hours and plan for the next 24 hours. During these meetings, people often discuss problems together or seek advice from the Scrum Master.
• Sprint Review. This event gives the team an opportunity to gather all work, review it, and prepare it for the client or users.
• Sprint Retrospective. This event is an opportunity for team members to look at what went well, what didn't, and how they can approach similar challenges in the future.

Some Scrum Masters also have their own organization-specific events.

Good luck adopting scrum!

Scrum is an agile development methodology that breaks the large task of creating a product into small tasks that teams can smash out in short sprints that last two to three weeks.

Scrum is popular because it is flexible, scalable, and facilitates continuous developments and improvements to a system. It also helps developers reduce errors and fix bugs before they become infestations.

Psst - looking for other ways to build better products faster?

Jam helps unblock your engineering team by giving engineers all the context they need upfront for any bug fix. This prevents engineers from being blocked waiting for follow up information, and gives them back more time to fix more bugs. Get Jam here – for free!