Scrum: the definitive guide

Just like successful athletes learn by doing, so do corporate teams. If you’re going to be a star on the field, court, or in the boardroom, you have to practice, and learn as you go.

Scrum is a project management framework that’s based on this same idea.

Those teams then organize (and reorganize) themselves on the fly.

It’s a framework that originated for use within development teams, but has since been applied with many teams across all types of companies.

This article covers all the basics: the Scrum methodology, the framework, events, artifacts, team members and tools to get started.

What is Scrum?

Scrum is a framework for organizing, planning and executing complex projects.

It supports people, teams and organizations in generating or completing projects by allowing them to adapt as they go.

We’ll dive into the entire framework later, but here’s a brief overview:

• The whole process often starts with a product roadmap outlining the big picture outcome(s) you hope to achieve
• This roadmap is broken down into a product backlog of all the features and requirements needed to reach that outcome.
• Teams run 1–4 week sprints where they tackle a portion of the product backlog and create a product increment (version of the final product).
• After each sprint, they review, refine, adjust, and then launch into the next sprint. This cycle continues until the final product is complete and the project ends.

Teams often use work operating software (OS) — like monday.com — to manage sprints within a Scrum project.

monday.com’s sprint planning template makes it easy to implement Scrum within your organization quickly and seamlessly. Here’s what that looks like:

Try monday dev

Why is it called Scrum?

The term Scrum originates in Rugby, where players from multiple teams join together in a very tight, organized formation to obtain a goal.

Players quite literally interlock themselves into a tight group in the play. It looks like this:

(Image Source)

The analogy was first referenced in 1986 in a paper by Takeuchi and Nonaka that was published in the Harvard Business Review.

They compared high-performing, cross-functional product dev teams to rugby teams using the Scrum formation.

What’s the difference between Agile and Scrum?

These 2 terms are often used interchangeably, but they’re not the same thing — Scrum is a framework and Agile is a mindset.

Scrum is centered around continuously improving as you go, a core principle of Agile methodology, which is why Scrum is often thought of as an agile project management framework.

Agile is quite widely used, and often implemented using the Scrum framework. In fact, 95% of organizations have some form of Agile process in place, and 18% have implemented Agile for all teams.

Why Scrum? (An intro to Scrum theory)

Teams choose to use the Scrum framework because its simplicity and flexibility allows them to move faster, while still staying organized.

When asked why it was originally adopted within their organization, 71% of teams replied that Scrum was adopted to accelerate software delivery, and 63% to manage changing priorities.

(Image Source)

The theory behind Scrum’s founding rests on 3 key pillars: transparency, inspection, and adaptation.

These pillars are built on the assumption that knowledge comes from experience, and that decisions should be made based on what is observed. As teams work on a project, they gain experience, and based on that experience, they should be able to re-adjust as they go.

The pillars encourage lean thinking, which means focusing on only what has been observed, and reducing wasted efforts so that teams remain focused on the essentials.

The following pillars act as guiding principles for the Scrum team:

• Transparency: both the team that’s performing the work and those receiving the work must be completely aware of the process and status at all times. Low transparency at any point in the process could lead to decisions that aren’t valuable and risk the project. The transparency pillar is also necessary for the next pillar, inspection, to be valuable.
• Inspection: the process and progress must be evaluated frequently as you go. This allows you and your team to spot potential risks or problems, and supports the final pillar — adapting when needed. The Scrum framework provides a cadence for inspection, which we’ll also discuss later.
• Adaptation: If you find your process isn’t going well or results aren’t as expected, you need to adjust. Most importantly, you have to adjust quickly so you don’t further deviate from your original goal.

It’s important to note that all 3 pillars break down if people aren’t empowered to self-manage. A Scrum team is expected to adapt the moment that anything new is learned through inspection, and you can’t do that if you don’t have the power to make self-guiding decisions.

What is the Scrum framework?

We keep mentioning that Scrum is a framework, but what exactly does that mean? The Scrum framework is made up of events — also referred to as ceremonies — that act as stages within a project, and artifacts that act as deliverables to be completed.

They’re all organized in a way that supports continuous learning and adjustment.

If you were to illustrate the whole thing from start to finish, it would look like a cycle that keeps on going.

Scrum events or ceremonies

There are 5 events or ceremonies within the Scrum framework:

• Sprint planning
• Sprint
• Daily Scrum
• Sprint review
• Sprint retrospective

Events are designed to enable transparency, and to allow for inspection and adaptation along the way. A sprint is an event itself, while also acting as an overall container for 3 of the remaining events.

Let’s walk through each of these events in detail.

Sprint planning

Sprint planning is where you plan your upcoming sprint. Sprint planning answers the following questions:

• Why is this sprint valuable? The answer to this question is typically pitched by the product or task owner, and then the Scrum team as a whole collaborates and eventually agrees on how the sprint’s value will be communicated to stakeholders. This is where the goal of the sprint is defined.
• What will we do in this sprint? Items from a product backlog — the overall list of work that needs to happen — are selected to include in the sprint. The list can be refined as they go. This is often the most challenging step of a sprint, but the more a team gets to know about its own capacity, the easier this becomes.
• How will we accomplish our goal? This is where the sprint backlog — what you’ll work on within this sprint — gets broken down into concrete tasks and activities that team members can take ownership of.

The answers to all 3 of these questions result in a sprint goal, items selected from the backlog and increments (or plans for delivery). Together, these 3 pillars become the sprint focus, which team members work to achieve throughout the sprint.

Generally, all of this happens within a total of 8 hours or less for a 1-month timeframe.

monday.com’s Scrum planning template is designed to support Scrum teams in the sprint planning state. It includes increments, timeframe projections, assignees, priorities and status updates — plus the ability to automate tasks and notifications as you progress.

The sprint

The sprint is a short iteration or phase of a project that happens within a fixed length of time of 1 month or less. It’s where your sprint plan becomes a reality and your project’s ideas and tasks are turned into value.

One month, specifically 30 days or less, is a very intentional timeframe. It ensures:

• Progress is evaluated at least once a month
• Inspection and adaptation take place frequently
• Goals don’t become too complex (longer lengths of time may lead to higher risk goals)

During a sprint, the Scrum team is required to stick to a few rules:

• No changes to the plan that deviate from the original goal of the sprint
• No decrease in quality of work
• The backlog is refined as needed
• Changes to the scope must include the product owner or task owner

Daily Scrum

The daily Scrum is a daily 15-minute meeting for developers or individual contributors on the Scrum team.

Each meeting is meant to accomplish:

• Seamless communication among team members so everyone always knows what’s going on
• Identification of any roadblocks so the team can work together to clear the way
• Quick decision-making (hence the 15-minute timeframe)
• An elimination of the need for additional meetings

Members of the Scrum team will meet outside of the daily Scrum for more detailed discussions about the sprint’s work, as needed.

Try monday dev

Sprint Review

The sprint review is when the sprint’s work is presented to stakeholders, and when adaptations to future sprints are identified.

During the sprint review:

• Stakeholders review what was accomplished and what has changed
• Attendees collaborate on what to do next
• Backlog is adjusted if needed

The sprint review is a working session that often takes place within 4 hours or less for a 1-month sprint.

Sprint Retrospective

The sprint retrospective is the final stage of a sprint where plans are put into place regarding the findings from the sprint review. It’s generally completed within 3 hours for a 1-month sprint.

The sprint retrospective accomplishes the following:

• Inspection of individuals, interactions, process, tools and completion of tasks within the sprint for opportunities to improve
• Identification of assumptions that turned out to be wrong
• Discussions about what went well, problems that were encountered and solutions
• Identification of helpful changes to implement in the next sprint

This event concludes the sprint and cycles you back up to sprint planning for the next sprint.

What are the Scrum artifacts?

Artifacts represent the work of the Scrum team or the value provided to the ultimate goal. They make transparency possible for the entire Scrum team.

There are 3 artifacts, each of which must be defined and measured in the following way:

• Product (or task) backlog: the complete list of work to accomplish, measured using the product goal
• Sprint backlog: the list of work to accomplish within 1 sprint, measured by the sprint goal
• Increment: the deliverable(s) provided for review at the end of a sprint, measured by the ‘Definition of Done,’ or rather, whether or not it was completed

Let’s explore each artifact in more detail.

Product (or task) backlog

A product backlog is a list of product backlog item variants needed to improve the product or complete a project. It acts as the source of work to be completed by the Scrum team.

The Scrum team selects items from the product backlog during the sprint planning event to be segmented into each sprint and increment.

A product or task backlog exists to maintain a single product goal, which is typically a description of how the company wants a product to look, eventually — so you never lose sight of the big picture.

Our feature backlog template is meant to serve Scrum teams as a product or task backlog, and includes elements like the item description, impact measurement, status and owner.

Sprint backlog

As we mentioned briefly when describing the sprint planning stage, the sprint backlog consists of the sprint goal, the backlog items selected for completion during the sprint, and the increment or increments that make up the plan for the sprint.

The sprint backlog is essentially the plan for the sprint, and should be fully transparent and trackable at all points within the sprint.

The sprint backlog exists to support the sprint goal, which is the single objective that the Scrum team is working towards in each 7-to-30-day block.

Below is an example of how 1 Scrum team used monday.com to build their sprint backlog.

Increments were categorized by new, filtered and closed tasks, and each increment was assigned an owner and measured based on it’s impact towards the ultimate sprint goal.

Increment

An increment is the version of the product that will be delivered at the end of the sprint.

For instance, your 1st sprint increment may be a prototype, your 2nd one may be an MVP (minimum viable product), and so on, until the final sprint delivers the full-functioning product you and your stakeholders hoped for.

Here are a couple of rules that Scrum teams stick to when it comes to increments:

• In order to be valuable, an increment must be usable
• The sum of all increments to-date is presented within the sprint review (I.e., each increment should build upon the last)
• Increments are never complete unless they meet the ‘Definition of Done’ for that increment

An increment exists to meet the ‘Definition of Done,’ or essentially, what the Scrum team defines as completion for that particular sprint. It’s considered the standard minimum that must be met in order to move forward.

What is a Scrum master and who makes up a Scrum team?

A Scrum team is a small team of 10 or fewer people. This number allows teams to stay nimble, but large enough to complete significant work within a sprint.

The Scrum team is ultimately responsible for stakeholder collaboration, verification, maintenance, operation, experimentation, research and product development (if applicable).

Here’s what each of the following team members are accountable for:

• Developers or individual contributors: they’re tasked with completing increments within each sprint and are accountable for creating the sprint plan, creating quality work, adapting their plan as they go, and holding each other accountable.
• Product owner or task owner: they’re tasked with maximizing the value of the product or project and are accountable for communicating and developing the product goal, clearly communicating the need for backlog items, ordering those items based on priority, and ensuring the backlog is transparent and understood.
• Scrum Master: they establish Scrum as defined with the Scrum guide and are accountable for coaching team members in self-management, helping team members meet the Definition of Done, removing impediments to progress, and ensuring that all Scrum events take place in a timely and effective manner.

You can track the responsibilities of your Scrum team with our project tracker, which clearly defines the tasks each team member is meant to fulfill, as well as assigns ownership, priority level and a delivery date.

Tools to implement Scrum

The Scrum framework is most often implemented using a Scrum board: a physical or digital board that manages processes and information for a Scrum team.

The Scrum board must list the sprint tasks, analyze the team’s progress, assign owners and track the team’s overall impact.

Using monday.com, you can track multiple Scrum teams or sprints at the same time with the dashboard like the one below. It’s built to provide a full list of Scrum team tasks, as well as a high level view of priority levels and completion rates.

Another project management tool, the Kanban board, is often merged with the Scrum board to provide multiple views of a single sprint.

A Kanban board uses cards and columns to move tasks forward and ultimately lead to project completion. monday.com’s Kanban view illustrates this nicely:

While they are often combined, each view of a project is ultimately different. Scrum focuses more narrowly on timelines and teams to support effectiveness, whereas Kanban boards are used often for more continuous work.

Here’s a full comparison of each tool:

In fact, 81% of companies use both Kanban boards and Scrum boards for project management, while 8% of Agile teams use a combo that’s often referred to as the Scrumban — a hybrid that aims to combine the advantages of both tools.

This hybrid model is sometimes also referred to as Kanban or Kanplan, which is essentially Kanban with a backlog.

Try monday dev

Why monday.com is the best tool in which to implement Scrum

We’re confident that monday.com provides the best tools for project managers to implement Scrum within their organizations. It provides the foundation for all sprint events and artifacts, and includes a few key features that make the Scrum framework run even more smoothly.

Communication regarding events, artifacts, and increments within monday.com happens all within the platform under each task that’s set by the product or task owner.

This means that data and information is collected automatically within your project management tool, and reduces back-and-forth amongst your Scrum team.

Within a sprint, some activities will be dependent on the completion of other activities before them, and we know that sprints can only begin when the former sprint has closed.

Our platform automates notifications between team members when it comes to task completion, document uploads, communication and much more.

Here’s an example of how you might set up an automation:

Whether you choose a Scrum board, Kanban board, or the Scrumban, you can view your project on monday.com, and even toggle between views if you change your mind as you go.

Plus, you’ll have other options at your fingertips. You can view your project tasks as a timeline to see if your deliverables will be completed on time, as a table if you need to drill down into specific tasks, as a Gantt chart, and much more.

Your team is probably already relying on various tools to get the job done. Our software integrates with every tool you’ll need to run your projects smoothly.

We even integrate with popular development tools like GitHub, JIRA, GitLab, and PagerDuty if you’re using the Scrum framework to manage a development team.

Last but not least, it’s easy to use, and your team will be excited to login everyday for status updates and communication amongst team members.

Completing tasks on our platform is satisfying, and changing views, moving tasks along the workflow and communicating with other team members is easy and intuitive.