Scrum 101

Scrum is a lightweight project management and team collaboration approach. It’s widely used but also misunderstood because of its terminology and inherent iteration – even on itself.

These characteristics lead to confusing variations of Scrum, different implementations, and fiery debates. But the basics of this agile framework are easy to understand once you remove historical baggage, opinions, and nuances that are not relevant for beginners.

When done right, Scrum enables teams to deliver value to customers quickly and frequently with their products. Such deliveries happen with minimal waste and maximum happiness because of Scrum’s aim to continuously improve the working process.

This guide is designed to get you started using Scrum and minimise any confusion about what it is or how it works. We’ll cover:

Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems, according to the official Scrum Guide.

In simple terms, Scrum is a set of practices that helps teams work better together. It is considered an “Agile” project management framework, because it prioritizes concepts such as short feedback cycles, empiricism, and continuous improvement.

The rules of Scrum are laid out in the Scrum Guide, which was written by Ken Schwaber and Jeff Sutherland. Scrum is currently the world’s most popular agile framework, according to data from the State of Agile report.

Scrum teams primarily work with information as the raw material of their efforts. Scrum refers to the places where teams store and manage information as “artifacts” and there are three of them – the backlog, Scrum board, and product increment.

The Product Backlog lists all the work a team could possibly do on the product or service they’re responsible for. Product backlog items are usually a mix of features, requirements, enhancements, and fixes.

The Sprint Backlog lists items the team has selected from the Product Backlog and aims to complete in their next cycle of work – the Sprint.

You usually write items in the backlog as user stories – feature descriptions described from the end-user’s perspective. Stories in the Product Backlog are constantly revisited and re-prioritized. Teams will move product backlog items to the sprint backlog in a process called sprint planning.

Most Scrum teams use a Scrum Board to track their work, even though it’s not mentioned in the official Scrum.org guide. The board holds cards that represent items in the sprint backlog.

These cards move across the board from left to right through a series of columns that reflect their status, usually “Backlog”, “Todo”, “Doing”, and “Done”.

Sometimes a Scrum Board is more commonly referred to as a Kanban board because this practice is inherited from the Kanban methodology.

The Scrum Board used to be a whiteboard filled with sticky notes standing in the middle of an office. These days, remote teams often use an app or online tool to visualise their progress.

Wherever your board is, it should be accessible by anyone in your Scrum team. This visibility reduces the need for status updates, as folks can just glance at the Scrum Board to understand what everyone is working on and what the status is.

The deliverable that results from completing all the items in the Sprint Backlog is called an increment in Scrum. Many teams also refer to this outcome as the “Sprint Goal.”

Usually, the increment is a small piece of working product a customer can use. The focus of Scrum is to create small increments of working software every single sprint. This is different to traditional project management approaches, where large product updates are often launched at once without customers seeing anything for months.

Unlike Scrum, this approach increases the psychological pressure on teams and increases the likelihood of something going wrong.

Scrum teams organize their members into three different roles – developers, Product Owner, and Scrum Master. The group is cross-functional, so they have all the skills to accomplish their work. Typically, a Scrum team consists of three to nine people without any sub-teams or hierarchies.

Scrum teams are also self-managed. So for each task, the team – not an outside manager – decides what gets worked on next, who works on it, when, and how.

The Scrum Guide refers to the people executing items in the Sprint Backlog as “developers”. While the name implies they are software developers, they can include designers, marketers, and other disciplines, depending on the nature of your team’s work.

The developers are responsible for working through items in the Sprint Backlog and, if necessary, adapting their plan to stay on track to deliver the Sprint Goal.

A Product Owner decides what the team will work on because he or she owns and prioritizes the Product Backlog. The Product Owner carries overall responsibility for the Backlog, but most of them share the responsibility for backlog refinement with the team.

The Product Owner effectively represents the customer and, as such, should spend a lot of time with them to understand their needs. A technical background is not required for this role. In fact, Jeff Sutherland, one of the creators of Scrum, explains in his book “Scrum: The Art of Doing Twice the Work in Half the Time” that the first product owner ever recruited came from Product Marketing.

A Scrum Master helps the team understand and practise Scrum. He or she guides the developers and Product Owner toward continuous improvement and removes any impediments or blockers along the way.

Scrum Masters also lead, train, and coach the broader organization in its Scrum adoption to ensure teams become truly self-managed. The hallmark of a great Scrum Master is that they’ve taught a team so well they’re hardly needed anymore to facilitate meetings or monitor the overall Scrum process.

Scrum teams organize their work in Sprints – two- to four-week cycles during which they complete items on the Sprint Backlog to create a product increment and get stakeholder feedback. Each Sprint contains several events – often called “ceremonies” – that eliminate the need for other meetings by adding rhythm and structure to the work process.

Sprint Planning happens at the start of each Sprint. The Scrum team commits to the tasks they will complete in the upcoming Sprint during Sprint Planning by moving items one at a time from the Product Backlog to the Sprint Backlog. It can last anywhere from one to two hours for a two-week Sprint.

Sprint Planning’s purpose is to keep your team focused during the Sprint by creating a clear and prioritized overview of the work to be done.

The Daily Scrum is a short, daily ceremony that helps team members unblock each other and sync up on important updates. Because it brings the whole team together every day, you can remove obstacles quickly and prevent distractions during the course of the day, so your team can continue in a state of flow toward the Sprint Goal.

The Daily Scrum takes place at the same time every working day of the Sprint. It should not last longer than 15 minutes. Otherwise, it turns into a loathed ritual. Previous Scrum Guides suggested asking developers these three questions at every Daily Scrum:

The Scrum team shows what they accomplished to stakeholders during the Sprint Review meeting. Sprint Reviews are held at the end of each Sprint, just before the Sprint Retrospective. The goal is to collect feedback, determine if the increment was achieved, and discuss how to improve the product in future Sprints.

Teams should demonstrate a working version of their product during the Sprint Review, which is why it’s sometimes also referred to as the Sprint Demo. Usually, this event lasts 30 to 60 minutes.

In a Sprint Retrospective, the Scrum team figures out how to improve their work by inspecting their last Sprint. Individuals, interactions, processes, tools—anything is up for review and discussion.

In his book “Scrum”, Sutherland recommends asking these questions to ensure continuous improvement:

As a general rule for the Retrospective’s length, take 30 to 45 minutes for each week of your Sprint. For example, the Retrospective for a two-week Sprint should last roughly one hour.

To get started with Scrum, begin with these practical steps:

The basics of Scrum are easy to understand. But to fulfil its promise of happy teams delivering value in frequent working cycles, your entire organization needs to embrace Scrum’s mindset and values.

Your team needs to let go of old work habits and continuously evolve its own practices. Managers should forget about command and control so teams can truly self-manage.

None of this is easy, and many who have tried failed, but it’s the only way to enjoy the full potential of Scrum. If you’re struggling to get started, consider reaching out to an agile coach or agile transformation agency that can help you overcome the first hurdles.

People that are just starting out with Scrum often wonder about these questions. We’ve got some of the answers!

Even seasoned practitioners often use “Scrum” and “Agile” interchangeably, but they’re not the same thing. Agile is a philosophy – a set of values and principles – about improving software development. Scrum is a practical, agile framework that’s aligned with those values and principles. Agile doesn’t tell you how to manage your project or team, whereas Scrum does.

Kanban and Scrum both rely heavily on what we’ve referred to in this article as the Scrum Board. In Scrum, the team decides what items to add to the Sprint Backlog – the “Todo” column on the board – and should only do this during Sprint Planning.

Kanban doesn’t have a planning session but enforces a limit on the number of items in the “In Progress” column. These limits are often referred to as WIP limits.

When the “In Progress” column is full, but a stakeholder wants an item handled right away, they’ll have to negotiate with other stakeholders to move an item out of that column in favor of their own.

This characteristic of Kanban makes it more suitable than Scrum for service-oriented teams that need to be highly responsive, for example, IT help desks within an organization.

You can practice the Scrum methodology with just a whiteboard. Still, plenty of virtual tools are now available to help facilitate the process: