Skip to main content

If you’ve spent any time in digital project management, you’ve likely heard of the Scrum methodology.

Scrum is a popular project management methodology that has been widely adopted in a variety of industries. 

91% of organizations state that it is a strategic priority to adopt agile. (Source: KPMG

When companies say they are following an agile methodology, 87% of the time, they are talking about Scrum (Source: Digital.AI). This means, in order to be an effective and adaptive digital project manager in today’s age, you’re going to need to know about Scrum. 

At its core, Scrum is based on the idea of empowering teams to self-organize and make decisions on how best to achieve their goals. This approach can help teams deliver high-quality products and services in a fast and efficient manner.

Scrum has seen widespread adoption in a variety of industries, including software development, manufacturing, and marketing. This is due in part to its flexibility and adaptability, as well as its focus on collaboration and empowerment.

In this article, I will introduce the basic principles of Scrum, artifacts, roles, and events to help get you started or serve as a refresher (we all need refreshers from time to time).

Whether you are a project manager, a team leader, or a member of a development team, there is something in this post for you. So, let's dive in and explore the world of Scrum!

What is Scrum Methodology?

You can define the Scrum methodology as a product delivery approach proposing principles and processes to improve outcomes.

Agile Scrum project management fixes the time and cost requirements of projects. Scrum achieves this by using time boxes (a specific, limited amount of time) for iterations of work, as well as product backlogs and specific team events. It’s a highly adaptive framework that helps deliver value in projects quicker. 

In Scrum management, projects make progress through sprints which represent one iteration of work towards the team’s goals. Each sprint or iteration produces a deliverable increment.

The Scrum methodology is one of many agile methodologies, all of which turn the historically predictive or waterfall project and product development triangle on its head.

As traditional project management methodologies limit scope and flex schedule and resources, agile methodologies (including Scrum) fix resources and schedule but flex scope, depending on what’s most important to accomplish in the fixed time with fixed resources. 

plan driven vs quality driven methodology triangles infographic
Here’s how to differentiate between agile methodologies and predictive methodologies (source).

At its core, Scrum empowers teams to create a healthy tension between delivering the right thing, the right way, as fast as possible.

The goal of Scrum is to improve communication, teamwork, and speed of development. Concepts such as sprints, Scrums, backlogs, and burndown charts are all derived from Scrum.

Why Scrum?

One of the key reasons for Scrum's popularity is its ability to help teams deliver high-quality products and services in a fast and efficient manner. By breaking projects down into small, manageable chunks and regularly reviewing progress, teams can quickly identify and address any issues that arise. This allows them to stay on track and meet their goals in a timely manner.

Another reason for Scrum's adoption is its emphasis on collaboration and communication. In a Scrum environment, team members are encouraged to work together and share ideas, rather than following a rigid hierarchy. This can foster a sense of ownership and accountability, which can help teams stay motivated and engaged.

Overall, the adoption of Scrum has been driven by its ability to help organizations and teams achieve their goals in a fast and efficient manner. By empowering teams to self-organize and make decisions, Scrum can help organizations stay competitive and deliver high-quality products and services.

The Core Mindset of Scrum: The Agile Manifesto

The Agile Manifesto is core to the Scrum methodology and can be considered the underlying mindset behind all agile methodologies. The Scrum methodology overlays on the Agile Manifesto to put how-tos to the whats. 

In other words, Scrum is one of the many how-to guides for developing outcomes in an agile mindset. Here’s a breakdown of the Agile Manifesto coupled with a few core Scrum principles.

1. Individuals and interactions over processes and tools

Firstly it focuses on individuals and interactions over processes and tools. Communication is key, not the processes that run your project. Within Scrum this means the self-organizing, cross-functional team.

2. Working software over comprehensive documentation

There is a strong focus on producing shippable products quickly, rather than spending a lot of time writing down requirements. In Scrum software development, time-boxed sprints of work are run with a shippable product increment produced at the end of each sprint.

3. Customer collaboration over contract negotiation

Agile values specify client or customer collaboration, working with the client at all points with them being heavily involved throughout the process. Scrum has consistent, and regular, client involvement.

4. Responding to change over following a plan

Rather than seeing changes as the enemy, being in a position to see change as a good thing and being responsive to it is core to the agile framework. Scrum has constantly evolving requirements, and change is embraced.

In addition to the Agile Manifesto, Scrum itself carries five values that are essential for people and teams becoming proficient in operating effectively: commitment, focus, openness, respect, and courage. 

These values give direction to an agile team or Scrum team as to how to behave in their work. The decisions that are made and steps taken should reinforce these values, not diminish or undermine them. When practiced effectively, the empirical Scrum pillars of transparency, inspection, and adaptation come to life, building trust. Learn more in the official Scrum Guide

Sign up for our emails and be the first to see helpful how-tos, insider tips and tricks, and a collection of templates and tools.

  • Hidden
  • No spam, just quality content. Your inbox is safe with us. For more details, review our Privacy Policy. We're protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
  • This field is for validation purposes and should be left unchanged.

What Are The 3 Artifacts Of Scrum?

Scrum artifacts communicate key information that the Scrum team needs to be aware of during product development.

1. Product Backlog

The product backlog lists all the features, functions, and requirements that must be included in the product, in order of importance. It’s common for a product’s requirements to change over the course of development, either to reflect business needs or market trends. The product backlog will constantly update to reflect such changes.

2. Product Backlog Item

These are the items that make up a product backlog. They detail the changes that need to be made and the desired outcome. One way to express the desired outcome in a way the development team will understand is through ‘user stories’ a simple sentence that explains what a certain business or user is looking for in the product.

User stories are structured like this: “As a [blank] I want to [blank] so that I can [blank].”

3. Sprint Backlog

The sprint backlog is made up of the product backlog items that have been selected for a sprint. This will also include a plan for producing an increment at the end of the sprint. 

The sprint backlog defines the work that the development team will perform during the next sprint and the items required to produce an increment that meets the definition of done.

scrum methodology artifacts infographic
An overview of the Scrum artifacts.

The Scrum Framework

The Scrum framework is an agile methodology focused on delivering value incrementally and iteratively over time. The process begins with a product owner creating a product backlog based on inputs from executives, teams, stakeholders, customers, and users, and ends with a showcase of finished work at a sprint review, followed by a sprint retrospective. This process repeats at regular intervals, typically 1-4 weeks. 

agile scrum framework infographic
An overview of the agile Scrum framework or methodology.

Scrum, in itself and similarly to the scrum events, is intentionally lightweight and simple. Scrum is easy to learn, but it can be difficult to master. It is intended to provide a framework for cross-functional teams to solve complex problems.

Simply put: Scrum is a methodology or process through which to exercise the agile mindset. 

Scrum Roles

Within the Scrum methodology are clearly defined roles.

  1. Scrum development team
  2. Scrum master
  3. Product owner

These roles help set the Scrum model apart from similar agile methods like extreme programming, lean, or test-driven development.

The Scrum environment promotes using small, flexible teams of no more than 9 people who work through the product backlog. A litmus test for team size is if you can feed them with two pizzas (yes, I’m serious).

This equates typically to 5-9 people on a team. People should only be allocated to one scrum team at a time. This rule is often justified due to how teams communicate, how incentives are aligned, and how many people an individual can maintain relationships with concurrently. 

illustration of 2 pizzas to represent the size of the scrum team
If your Scrum team requires more than 2 pizzas, it's too big.

1. Scrum Development Team

A Scrum development team is a group of professionals responsible for delivering a releasable increment of “done” at the end of each Sprint.

Development teams are unique in the following ways:

  • Development teams are self-organizing. Nobody within the Scrum team (not even the Scrum master) is allowed to tell them how to turn the product backlog into increments.
  • They’re cross-functional. All members must have the skills required to create an increment; some can be differently skilled, but all should be able to pitch in. 
  • They are responsible for successes and failures as a team. It doesn’t matter if one member made a mistake that caused the team to not have an increment at the end of a sprint, the development team accepts responsibility as a whole.

2. Scrum Master

The Scrum master is responsible for facilitating the Scrum process. They make sure everyone has a solid understanding of Scrum principles and offer guidance and teaching when it’s necessary.

The Scrum master leads the Scrum team through the daily Scrum. They’ll often ask three questions:

  1. What did you do yesterday?
  2. What will you do tomorrow?
  3. What obstacles are in your way?

The Scrum master is not the leader or people manager of a Scrum team. They are not directly responsible for outcomes. The whole team as a whole must accept responsibility for the end product.

The Scrum master will also work with the product owner to make sure the project is on track. 

They’ll do tasks such as:

  • Guaranteeing that the Scrum goals are understood by everyone.
  • Optimizing product backlog management.
  • Organizing Scrum events
  • Helping to remove impediments when they arise

The Scrum master’s job is to keep everyone focused and pushing towards the same goal. They are chartered to remove obstacles, prevent unnecessary distractions, and help the team make progress day after day. Even though the result of the Scrum ultimately rests on the entire team, Scrum masters often feel a lot of pressure to succeed in the position.

3. Product Owner

The product owner represents the business or customer base. They are there to ensure the other members of the Scrum team don’t forget the purpose of the sprint. Because of the wide variety of potential business users and customers, the product owner must have a strong understanding of the users needs.

Each sprint begins with the product owner documenting and prioritizing the requirements and desired features of the product to the development team. In a planning session, the product owner’s job is to answer any questions the development team may have regarding specifications and requirements. 

The product owner is not involved with development, but may be asked to answer clarifying questions along the way, during each sprint.

Day-to-day responsibilities of a product owner may include: 

  • Documenting product requirements
  • Writing initiatives, epics and user stories
  • Syncing with product management to ensure product requirements are aligned with the overall product roadmap
  • Researching the needs of real-life customers and users of the product
  • Answering clarifying questions from the development team
  • Collaborating with leaders across the organization to ensure their product is able to be sold, implemented, supported, etc. 

Product owners are essential to a successful product development cycle in the Scrum methodology. Without clear and prioritized requirements, development teams might not know what to develop in what order. Product owners ensure development teams know what is most important to work on now, and what’s coming next. 

scrum methodology scrum roles
The three main Scrum roles.

Scrum Events (a.k.a. Scrum Ceremonies)

There are 5 main kinds of Scrum events or Scrum ceremonies:

  1. The sprint
  2. Sprint planning
  3. Daily Scrum (also called the daily stand-up meeting)
  4. Sprint review
  5. Sprint retrospective

Certain types of Scrum events will take place during specific times in the development process. These are also known as the Scrum ceremonies.

1. The Sprint

A sprint in Scrum is a fixed length of time, one month or less where ideas are turned into value. The sprint is the heartbeat of Scrum. A sprint is a set length of time that repeats throughout time. Often, teams measure their future in sprints. 

The purpose of the sprint is to time-box work time and get teams to deliver against commitments. Sprints allow goals to be set that are shorter-term, but incredibly solid. During a sprint, nothing should change that would endanger the sprint goal. 

The sprint keeps the team on-task, but allows for course correction or changes sprint-to-sprint. Sprints enable predictability by ensuring that what the development team commits to will either be done or reviewed in a short period of time. 

With sprints, the “we’ll see when it happens” goes away. We know when things will happen because they are either committed or not committed in the sprint. 

A sprint is anywhere from 1-4 weeks, not longer. This limitation allows teams to get moving and deliver incremental progress rapidly, but without driving people crazy. Sprints cannot be made longer or shortened. A sprint could only be canceled if the sprint goal becomes obsolete. Only the product owner has the authority to cancel the sprint. 

2. Sprint Planning

infographic covering the steps in running an agile sprint planning meeting
An overview of how you might go about running your sprint planning meetings.

During a sprint planning event, the team agrees upon the series of product backlog items they will complete in the upcoming sprint.

For every one week of a sprint, an hour is set aside for sprint planning. The sprint planning meeting takes place before a sprint begins so if the upcoming sprint is for 4 weeks, the team will set aside four hours for the meeting.

The most important part of a sprint planning meeting is the preparation that must be done before the meeting starts. The product owner will arrive at the session with a prioritized backlog of user stories and features they wish for the development team to create. 

In the sprint planning session, the development team and product owner will align on exactly what is desired and how much time it is expected to take to meet those requirements. 

Which and how many items from the product backlog will be completed depends on the team’s commitment and velocity (the speed at which the development team can create increments). If you're planning with a new team, it’s best not to calculate based on expected velocity until you’ve done a few sprints with the team.

Read our full guide on how to run a sprint planning meeting.

3. Daily Scrum

Each day, a daily Scrum meeting will take place where team members discuss progress they’ve made and problems they’re facing with the intent to celebrate progress, align current work and remove impediments swiftly to keep everyone moving forward.

Scrum meetings take place every day during a sprint. They should be no longer than fifteen minutes and should be laser focused on keeping the team moving forward. 

Daily Scrum sessions are held every day to prevent problems piling up in the background. Any questions or concerns should be raised at the daily Scrum meeting.

Want to make sure you’re running the best daily Scrum possible? Read our guide on how-to run a more effective daily scrum.

4. Sprint Review

The sprint review meeting takes place at the end of a sprint with the expressed purpose of looking over the progress made. During a sprint review the product owner will assess if the results match the expectations set at the sprint planning meeting. Here, the product owner will verify that the increment of work meets the definition of done.

5. Sprint Retrospective

A sprint retrospective meeting allows your team to look back on past events and situations. According to the Scrum Guide, the sprint retrospective is an “opportunity for the Scrum team to inspect itself and create a plan for improvements to be enacted during the next sprint.” Makes sense, especially since the focus of agile development is continuous improvement. In order to get better, you have to know which sword to sharpen.

The retrospective should create a safe space for people to share their honest feedback on what’s going well, what could be improved, and generate a discussion around things that should change next time around—with actionable items documented.

Read our full guide on how to run a great sprint retrospective.

Planning Projects Using The Scrum Methodology

The Scrum methodology can be used for projects of many different sizes, and it’s based on the principle of agile development, which emphasizes the need for flexibility and responsiveness to change.

The first step in using the Scrum methodology is to create a prioritized product backlog. The product backlog is a to-do list of all the tasks that need to be completed in order to achieve the goal of the project. Tasks can be added to the product backlog at any time, and can be prioritized based on importance.

Once the product backlog is created, the next step is to create a sprint backlog. The sprint backlog contains a list of tasks that will be completed during a specific sprint, or period of time. The tasks in the sprint backlog should be based on the tasks in the product backlog that are most important and urgent.

In order to ensure that tasks are completed efficiently and effectively, the Scrum methodology uses a set of specific guidelines to help keep things manageable. Guidelines include:

  • Tasks should be broken down into small, manageable pieces
  • Tasks should be assigned to specific team members
  • Team members should meet regularly to update one another on their progress
  • The team should always be focused on completing the most important tasks first

Once a team is off and running developing and delivering value in the Scrum methodology, the sprint cycle will be repeated. It is the responsibility of the product owner to ensure user stories and feature requests are ready to go for the development team, so they always have something to work on. The Scrum master helps keep the team moving forward in an aligned, orderly fashion

By following the guidelines of the Scrum methodology, teams can be more productive and efficient as they work to complete their project. The flexibility of the approach allows for quick adjustments when needed, helping keep projects on track and on time. Scrum also encourages teamwork, collaboration, and communication among team members, which helps ensure successful outcomes.

Benefits Of The Scrum Methodology

The Scrum methodology is an agile project or product delivery technique that helps teams work more efficiently and effectively. It's a simple, yet powerful approach that can be used for software development, product design, marketing projects, and more.

Some of the benefits of using the Scrum methodology include:

  1. Increased productivity: When teams are able to work in short bursts of time called "sprints," they can typically achieve more than if they were working on the project over a longer period of time.
  2. Increased collaboration: The Scrum methodology encourages team members to work together closely to achieve common goals. This can help reduce misunderstandings and improve communication.
  3. Increased flexibility: The scrum methodology is flexible and can be adapted to meet the specific needs of the project team. This can help ensure that the project prioritizes completion of the most important items while keeping commitments of cost and schedule.
  4. Improved quality: By using short sprints, teams are able to focus on completing specific tasks and ensuring that they are of the highest quality possible. This can help avoid costly mistakes and improve the overall quality of the final product or service.

A Brief History of Scrum

  • 1986: Hirotaka Takeuchi and Ikujiro Nonaka published “New New Product Development Game” in the Harvard Business Review and coined the word “Scrum” for use outside of the game of rugby.
  • 1995: Jeff Sutherland and Ken Schwaber presented Scrum at OOPSLA.
  • 2001: Sutherland, Schwaber and 15 other developers created the “Manifesto for Agile Development,” commonly referred to as the “Agile Manifesto.” The Agile Alliance was founded, and noted Scrum as one of the agile methods. 
  • 2002: Schwaber published “Agile Software Development with Scrum” with Mike Beedle, founded the Scrum Alliance, and began offering Scrum certifications.
  • 2004: Schwaber published “Agile Project Management with Scrum,” which has been followed by other books and guides on Scrum application across contexts. 
  • 2007: The Scaled Agile Framework is developed, known as SAFe. 
  • 2014: Dr. Dave Cornelius, a recognized Lean and Agile catalyst, presented his doctoral research based on the Scrum methodology, focusing on “The Value of Scrum to Organizations.”
  • From 2014 and beyond, Scrum has been applied across new contexts, including at huge scales all over the world. 

Scrum: In Comparison

Scrum vs Agile

Put simply, agile is the mindset, and Scrum is one of many methodologies that leverage the agile mindset. Scrum sits within the umbrella of agile as a mindset, and is joined by many other agile-focused methodologies including extreme programming, lean, kanban, SAFe, test-driven development, crystal, and more. 

scrum methodology agile umbrella infographic
There’s a wide variety of methodologies that sit under the agile umbrella.

The difference between Scrum and agile is that Scrum is a plan or a how-to for implementing processes aligned with the agile mindset. Agile software development with Scrum is one of the most popular approaches to development.

Read more about the differences between waterfall and agile more broadly here.

Scrum vs Kanban

There are other ways to implement agile, too. For instance, another popular approach is Kanban, which differs from Scrum in that it doesn’t require clearly defined roles, does not execute sprints with a fixed duration time, and is open to workflow changes at all points in development. 

The key to Kanban is to limit how many work items can be in progress at any given time. The limit on work in progress (WIP) forces teams to swarm to solve and finish what they have started, because new items are not allowed to begin progress if old items have not yet been finished. You can identify a Scrum team by its “sprints” and you can identify a Kanban team by seeing limits on work in progress. 

You may see a Scrum team using a Kanban board (literally just means sign-board) to show their work items visually across statuses–that’s fine! Use of a Kanban board does not undermine Scrum, assuming the roles, events and time-boxes are still in-use. 

Read more about the differences between Scrum and Kanban here.

scrum vs kanban infographic
A quick comparison of Scrum and Kanban.

Scrum Software

Scrum and Scrum tools aren’t just for software development teams, even though that’s where Scrum originated. The Scrum framework can be used in many production settings—from marketing agencies to construction firms.

Here are some of the best project management software with items like backlogs and sprint planning features that help you follow the Scrum methodology.

Get in-depth reviews of these tools—along with screenshots, scores, and pricing info—in the Scrum software review and Scrum tools review.

Best Scrum Resources

  1. Scrum Guides: The official (and FREE) Scrum Body of Knowledge. Written by the co-creators of Scrum, Ken Schwaber and Jeff Sutherland.
  2. Scrum.org: A professionally recognized organization that offers training and official agile certifications like Professional Scrum Masters, Professional Scrum Product Owners, and Professional Scrum Developers. 
  3. Scrum Alliance: An organization that teaches individuals of all experience levels about Scrum. They also offer training and certifications in the form of: Certified Scrum Masters, Certified Product Owners, and Certified Scrum Developers. 
  4. Scrum Inc: Founded by Jeff Sutherland, the co-creator of Scrum, who regularly updates the blog. They offer training and certification.
  5. Atlassian: Australian enterprise software company that provides detailed and fact-checked guides about agile methodologies, including Scrum. 
  6. Visual Paradigm Scrum Guides: A large database of articles on all things Scrum, from basic definitions to problem solving specific problems.

Scrum Glossary

To the uninitiated, Scrum may sound intimidating. Here’s an overview of some common used terms. 

Here’s a list of Scrum terms you can refer back to at any point:

  • Agile: The mindset and umbrella under which the Scrum methodology was developed. Promotes adaptation and flexibility over rigid structure.
  • Burndown chart: A chart showing the amount of work that remains in the product backlog.
  • Burn-up chart: A chart showing the amount of work that has been completed from the product backlog.
  • Daily Scrum: A meeting held everyday, where fifteen minutes is set aside to structure the upcoming day of work.
  • Definition of done: The expectation that an increment must meet to be considered releasable.
  • Development team: Team within the Scrum team that manages, organizes, and does the development work required to create in increment.
  • Empiricism: Process control which states that only the past is certain. Allows for maximum flexibility within the agile framework. Values transparency, inspection, and adaptation. 
  • Engineering standards: Set of standards shared across teams to ensure increments.
  • Forecast of functionality: The set of increments taken from the product backlog that the development team views as possible to complete in a sprint.
  • Increment: A piece of software that can be added to other increments. Put together, enough increments make a product.
  • Product backlog: A list (typically ordered) of the work that must be done to create a product.
  • Product owner: Team member in Scrum tasked with maximizing a product’s value.
  • Scrum board: An easy way to visualize the information shared between the Scrum team.
  • Scrum Guide: The original definition of Scrum. The guide details Scrum’s roles, events, artifacts, and rules.
  • Scrum master: Responsible for leading the Scrum team. Makes sure everyone has a firm understanding of Scrum principles. Offers guidance and teaching when necessary.
  • Scrum values: The core values that drive the Scrum framework. These are: commitment, focus, openness, respect, and courage.
  • Self-organization: A core principle of Scrum which states that teams must internally organize their work without interference from outside teams.
  • Sprint: A time-frame of one month or less where Scrum events are carried out. Sprints are carried out back to back. There are no breaks between them.
  • Sprint goal: The purpose of the current sprint.
  • Sprint retrospective: A meeting, three hours or less, where the sprint team comes together and discusses any improvements that should be implemented for the next sprint.
  • Sprint review: A meeting, four hours or less, that represents the end of a sprint. Work is reviewed and the stakeholders inspect the increment to ensure it meets the definition of done.
  • Stakeholder: Person outside of the Scrum team. Provides an outside perspective and is actively involved in sprint reviews.

What Do You Think?

Although Scrum has been around for a long time, it’s always evolving. Have you implemented Scrum effectively with software development teams? How about outside of software development? I want to hear your tips! 

I’ll share one of my favorites with you to get the conversation started: when I implement Scrum with a team that is new to it, I often won’t use the fancy words like sprint, backlog refinement, sprint planning, or iteration. Instead, I’ll say, “ok, it is time for us to plan our week based on our backlog.” This way, people are not put-off by the terminology and can instead focus on delivering great work. 

This method, which I call “Sneaky Scrum,” has proven effective for me and is now standard practice when I lead a cross-functional product development team or individual initiative. If you have been on one of my Sneaky Scrum teams, I hope this article has filled in some of the gaps—we’re going to start using the Scrum terms now! 

Now back to you, what are some things you learned about Scrum? What would you add to improve the methodology? Let me know in the comments and if you have terms to add to the Scrum glossary list, drop those in the comments with the definition as well! We’d love to learn from you! 

Make sure to subscribe to The Digital Project Manager newsletter for more on Scrum and agile methodologies.

By Liz Lockhart Lance

Liz is an agilist and digital project manager with a passion for people, process, and technology and more than 15 years of experience leading people and teams across education, consulting, and technology firms. In her day-to-day, Liz works as the Chief of Staff at Performica, an HR software company revolutionizing how people give and receive feedback at work. Liz also teaches an Operations Leadership course in the MBA program at the University of Portland, and is working towards completing a Doctorate at the University of Southern California in Organizational Change and Leadership. Liz holds numerous project management-related certifications including: PMP, PMI-ACP, CSP-SM, and a SPHR from HRCI to round out the people-focused side of her work.