What is Scrum project management?
According to the 16th State of Agile Report, approximately 87% of Agile teams implement Scrum.
This makes Scrum the most popular Agile framework in project management.
To understand what makes Scrum so desirable, we’ll need to dive deeper into the specifics.
So, in this guide, you’ll learn everything you need to know about Scrum, including:
- What Scrum is and where its name originates from,
- What the benefits of Scrum are,
- When to implement Scrum,
- What the pillars and values of Scrum are,
- What the Roles, Artifacts, and Events are in Scrum, and
- How to implement Scrum in 6 steps.
In addition, we’ll compare Scrum with 3 other widely used project management methodologies and frameworks:
- Kanban, and
The guide also includes a list of Scrum certifications and a short glossary of Scrum terms.
Now, let’s get started.
Table of Contents
What is Scrum?
Ken Schwaber and Jeff Sutherland developed Scrum in the early 1990s, and since then, its popularity hasn’t faded. Quite the contrary — it continues to grow to this day.
The 16th State of Agile Report by Digital.ai from 2022 found that the use of Scrum within organizations increased from 58% in 2020 to 87% in 2022.
Such popularity may be due to Scrum’s simple nature. Namely, Scrum isn’t concerned with lengthy progress reports and unnecessary meetings. It aims to achieve concrete results by:
- Delivering value, and
- Increasing efficiency.
As Schwaber and Sutherland explain in The Scrum Guide, Scrum is “a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.”
In essence, Scrum is a circular process best defined by Sprints. A Sprint is a fixed time period during which the team works on completing a set of tasks. After one Sprint is completed, the next one begins.
Scrum follows a 3-3-5 structure:
- It depends on 3 necessary Roles — which provide clarity of responsibilities,
- It can’t do without 3 Artifacts — which provide the visibility of crucial information, and
- It progresses through 5 Events — which provide opportunities for inspection and adaptation.
We’ll discuss all these terms later in the guide, but for now, here’s a short overview of basic Scrum terms organized by categories:
|Scrum Categories||Scrum Elements|
|Scrum Pillars||– Transparency– Inspection– Adaptation|
|Scrum Values||– Courage– Focus– Commitment– Respect– Openness|
|Scrum Roles||– Product Owner– Scrum Master– Developers|
|Scrum Artifacts||– Product Backlog– Sprint Backlog– Increment|
|Scrum Events||– The Sprint– Sprint Planning– Daily Scrum– Sprint Review– Sprint Retrospective|
Now that we’re more familiar with Scrum, let’s see where its name originates from.
What does Scrum stand for?
According to Scrum Alliance, the term Scrum comes from a 1986 Harvard Business Review article by Hirotaka Takeuchi and Ikujiro Nonaka, in which the authors compared high-performing, cross-functional teams to the rugby team.
In rugby, a scrum is formed when 8 players from both teams arrange themselves in 3 rows and lock heads with the front row of the opposing team, resulting in one large pile of bodies. The ball is then flung at their feet, and the teams wrestle for control of it.
The team that gains control of the ball then passes it up the field while moving together, as a large unit, towards a common goal.
Just like the players working together to take control of the ball and get it into their opponent’s try zone (in-goal area), the Scrum Team works together toward their common goal — the Sprint Goal.
This is what makes the project management style in Scrum different from traditional project management where the work is passed down from team member to team member in a sequential manner like a baton in a relay race.
What are the 3 pillars of Scrum?
Scrum is an empirical approach, which means that the team learns from experience and decides their next steps based on evidence, that way ensuring the creation of truly valuable products.
According to The Scrum Guide, the 3 empirical pillars of Scrum are:
- Inspection, and
Let’s see what each of the pillars stands for.
Pillar #1: Transparency
Transparency in Scrum implies that all work is visible to everyone — both those doing the work and those receiving it.
As Jeff Sutherland explains in Scrum: The Art of Doing Twice the Work in Half the Time: “The idea is that there should be no secret cabal, no hidden agendas, nothing behind the curtain.”
So, by focusing on how each team member’s daily project activities contribute to common organizational goals, Scrum helps teams build trust and improve their performance.
Pillar #2: Inspection
This question posed by Jeff Sutherland reflects the essence of the Scrum Inspection pillar:
“Whenever you start a project, why not regularly check in, see if what you’re doing is heading in the right direction, and if it’s actually what people want?”
- Highlight unwanted variances or problems, and
- Drive positive change.
Pillar #3: Adaptation
Inspection and adaptation are tightly related. Together, they focus on the idea of continuous improvement.
If anything differs from the acceptable limits or the resulting product is not acceptable, you must adjust the process or materials as soon as possible.
In other words, Scrum teaches you to constantly question what you’re doing and how you might do it better to improve overall performance.
What are the 5 values of Scrum?
According to The Scrum Guide, success in the use of Scrum depends on the following 5 values:
- Respect, and
Let’s discuss these values in more detail.
Value #1: Commitment
Scrum Team members should be committed to accomplishing common goals and supporting each other on the road to success.
Our source, Abhay Talreja, a Senior Consultant at Deloitte, an Agile guru, and a Certified Scrum Master, shares an example of a situation where the commitment value comes to the forefront:
“A Scrum team is usually self-sufficient in completing tasks in the Sprint. There are times when some of the tasks require new skills that need to be learned. A team shows commitment when they put in the necessary time and effort to complete their task, even if it requires learning new skills or adjusting their approach to implementing something.”
Value #2: Focus
Each Scrum Team member should remain focused on Sprint’s work to make optimal progress toward the Sprint Goal.
Abhay shares an example of a situation where the focus value is vital:
“When working with the functional team or the Product Owners, sometimes a task may get additional details or a change in approach during the Sprint. Any extra work identified needs to get into the Backlog and not be part of the Sprint, as this will sidetrack the team’s focus.”
Value #3: Openness
The Scrum Team and all the stakeholders involved in the project should stay open about their work and the challenges they face along the way.
The openness value is in line with one of the Scrum Pillars — transparency — which calls for visibility and honesty in everything that happens throughout a project.
This visibility further allows for inspection and adaptation, which ultimately leads to a successful project.
Abhay explains that the amount of transparency may impact both the current and future assignments in a Sprint, as well as other team members:
“The biggest problem I have seen with being transparent and Developers holding back information is that they usually feel they can figure it out. This usually ends up being a pilled-on activity towards the end of the Sprint and causing last-minute struggles.”
In Abhay’s opinion, openness is a crucial value as it encourages speaking honestly about potential issues:
“While all these values are fundamental, openness is crucial because it encourages team members to bring up issues and risks promptly and honestly. Usually, these end up being the blind spots for the team. Having an open perspective on tasks, issues, and risks can lead to better collaboration, problem-solving, and, ultimately, a more successful project.”
Value #4: Respect
Scrum team members should respect each other as the presence and absence of respect among them impact how well they’ll communicate as a team.
Abhay highlights that respect usually showcases when certain disagreements occur, like in the following example:
“There are always a couple of implementation approaches for any task. There is sometimes disagreement between team members on the approach. The best way is to express their viewpoint in a way that respects the other person’s perspective and expertise. The view need not challenge the approach but help to shape the approach.”
Value #5: Courage
Scrum team members should have the courage to do the right thing when faced with certain project management challenges.
Also, courage implies the readiness to make changes and sometimes even break the rules and routines if that’s what the project calls for.
According to Abhay, displaying courage may in some cases even feel a bit uncomfortable, but is necessary for the betterment of a project, as in the following example:
“This [situations in which being courageous feels a bit uncomfortable] is a common thing we have seen on projects where the client or the stakeholders usually request features that might not be part of the design. A product owner can demonstrate courage to push back against the stakeholder’s request, which would negatively impact the project’s timeline.”
💡 Plaky Pro Tip
Have you ever been asked by stakeholders to do more work than you agreed on? Read about scope creep in the following guide:
What are the roles in a Scrum Team?
Scrum roles are somewhat different from the usual project roles, and they exist to provide clarity of responsibilities within a Scrum Team.
There are 3 main roles in Scrum:
- Product Owner,
- Scrum Master, and
Let’s describe each role further.
Role #1: Product Owner
A Product Owner manages the Product Backlog and maximizes the product’s value.
Here are some of the usual responsibilities of a Product Owner:
- Represents customers and other stakeholders,
- Sets and expresses the Product Goal,
- Creates and communicates Product Backlog items, and
- Makes sure that the Product Backlog is visible, transparent, and understood.
💡 Plaky Pro Tip
A Product Owner’s role is often confused with the role of a project manager. Check out the following guide to learn how these 2 roles differ:
Role #2: Scrum Master
Instead of focusing on the project itself, a Scrum Master focuses on the Scrum Team by:
- Guiding the team, and
- Facilitating Scrum implementation.
As the Scrum Master’s role often coincides with that of a project manager, we’ve asked experts to explain the difference.
Here’s how Abhay Talreja describes the Scrum Master’s role:
“A Scrum Master helps remove obstacles that could hinder the team’s progress by coaching the team on Scrum practices. The Scrum Master also ensures that the team is self-organizing, facilitates Scrum events, and helps protect the team from outside interference and pressures.”
On the other hand, a project manager has a more direct role in a team’s day-to-day work:
“The project manager is responsible for the planning, execution, and completion of the project. They are responsible for managing the resources, tracking progress, and making adjustments and are generally a single point of accountability for the success or failure of a project. As opposed to Scrum, where it [success or failure] is the responsibility of the Development team.”
According to Christina Lukynyuk, a Certified Scrum Master and Project Manager at Softjourn, inc., there’s one thing in particular that differentiates a Scrum Master from a project manager:
“One of the most contrasting differences [between a project manager and a Scrum Master] is the Scrum Master’s role in team development and allowing for the self-sufficiency of the team. What I mean by this is that, when a team has been taught to become self-sufficient on a project and manage the Scrum principles by themselves, that’s when the Scrum Master can leave. When a team takes responsibility for a project, that is the true testament to a job well done by a Scrum Master. This is different from a project manager, as they will usually stay on a team for the duration of the project.”
Role #3: Developers
Developers are Scrum Team members that create the product in increments through Sprints.
In addition, Developers are accountable for the following matters:
- Creating the Sprint Backlog,
- Adjusting the daily plan to meet the Sprint Goal,
- Instilling quality by sticking to the Definition of Done (more on it later), and
- Keeping each other accountable as professionals.
What are the 3 Scrum Artifacts?
As defined in The Scrum Guide, “Scrum Artifacts express work or value, and they are intended to maximize the transparency of critical information”.
When someone mentions the word “artifact”, you probably recall the good old Indiana Jones movies in which the main character tries to recover various archeological artifacts, such as the Holy Grail.
Even though Scrum Artifacts are completely different from those valuable to Indiana Jones — they are just as priceless as the Holy Grail to a Scrum team.
In simple terms, Scrum Artifacts are lists of work to be done or work products that have been done.
There are 3 main Scrum Artifacts that help organize work:
- Product Backlog,
- Sprint Backlog, and
- Product Increment.
Now, let’s analyze Scrum Artifacts in more detail.
Artifact #1: Product Backlog
The Product Backlog is owned and maintained by the Product Owner.
It is an ordered list of work needed to:
- Maintain, and
- Sustain a product.
As The Scrum Guide highlights, a Product Backlog is “the single source of work undertaken by the Scrum Team.”
Each Product Backlog has its Product Goal — a target to plan against and a long-term objective for the Scrum Team.
The Product Backlog is constantly evolving and is never complete since it is updated on demand and in accordance with the latest information.
💡 Plaky Pro Tip
To learn how to keep the Product Backlog relevant and in good order, read the following guide:
Artifact #2: Sprint Backlog
A Sprint Backlog is an ordered list of work necessary to accomplish to achieve the Sprint Goal.
As explained in The Scrum Guide, the Sprint Backlog is planned by the Developers and represents “a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal.”
💡 Plaky Pro Tip
To learn more about the differences between Product and Sprint Backlogs, take a look at the following blog post:
Artifact #3: Product Increment
A Product Increment is the completed work the Developers produced during a Sprint.
As The Scrum Guide explains, an Increment is “a concrete stepping stone toward the Product Goal”.
Developers may create multiple Increments within one Sprint, but they must be usable to provide value.
We cannot consider work as a part of an Increment unless it meets the Definition of Done — the agreed-on quality measures required for the product.
So, before the beginning of a project, the Scrum Team needs to define what it means that the requirement is done and then comply with that definition.
If an item fails to meet the Definition of Done, it cannot be released. Instead, it must be returned to the Product Backlog for future consideration.
What are the 5 Scrum events?
As explained in The Scrum Guide, each event in Scrum is a formal opportunity to inspect and adapt Scrum Artifacts.
Scrum events serve several purposes, including:
- Increasing transparency,
- Creating regularity, and
- Minimizing the need for meetings that are not defined in Scrum.
Optimally, each event is held at the same specified time and place to reduce complexity.
There are 5 Scrum events that occur during a Sprint, 4 of which are contained in the main event, i.e. the Sprint, including:
- The Sprint,
- Sprint Planning,
- Daily Scrum,
- Sprint Review, and
- Sprint Retrospective.
Event #1: The Sprint
The Sprint is the main event in Scrum.
As The Scrum Guide explains, the Sprint is a fixed-length event of 1 month or less during which all other Scrum events that lead to the Product Goal happen.
Sprints can last e.g. a week, or a month, depending on the timeframe agreed upon by the team.
A new Sprint starts immediately after the previous one ends, so each Sprint may be seen as a short project.
If the Sprint Goal becomes obsolete, it’s the Product Owner who has the authority to cancel the Sprint.
Event #2: Sprint Planning
In a nutshell, Sprint Planning describes what can be delivered within a Sprint and how to accomplish this.
During this event, the Product Owner and Developers discuss which Product Backlog items will be included in the Sprint, and they initiate the Sprint after defining the following matters:
- A Sprint Backlog and
- A Sprint Goal.
Developers then plan the work necessary to create an Increment that meets the Definition of Done. They usually do so by breaking down Product Backlog items into smaller work items of 1 day or less.
Here are some of the topics that can be discussed during Sprint Planning:
- Why the Sprint is valuable,
- What is considered Done in the Sprint, and
- How the chosen work will get done.
Event #3: Daily Scrum
During the Sprint, Developers meet once a day in a 15-minute event called the Daily Scrum meeting.
The purpose of the Daily Scrum is to review and adjust the progress toward the Sprint Goal.
Daily Scrums have several benefits, including:
- Improving communication,
- Identifying obstacles,
- Promoting quick decision-making, and
- Reducing the need for other meetings.
According to Jared Hill, PMP, Senior Technical Project Manager and a PMO Consultant, daily stand-up meetings, or Daily Scrums, greatly contribute to accountability in Scrum:
“Daily stand-ups provide an opportunity for the Development team, Product Owners, and the Scrum Master to create awareness of where each work item is on the journey to “done”. The frequent check-ins reduce the risk of work items “falling through the cracks” and raise awareness of any and all blockers. There’s a lot of impact coming out of that 15-minute meeting when done correctly.”
Event #4: Sprint Review
When a Sprint ends, the Sprint Review takes place.
In a Sprint Review, the Scrum team presents the results of the Sprint to key stakeholders, and together, they inspect those results and determine what needs to be adapted in the future.
The Sprint Review shouldn’t be just a presentation, but a working session where the attendees discuss their next steps and possible adjustments to the Product Backlog.
Event #5: Sprint Retrospective
The final Sprint event is called a Sprint Retrospective.
During this event, the Scrum Team reviews the following:
- What went well during the Sprint,
- What problems were faced, and
- How those problems were resolved — or why they weren’t.
Some of the specifics that the Scrum Team inspects include how the entire process went concerning:
- Tools, and
- The Definition of Done.
After the Scrum Team has identified the changes that should be made to increase effectiveness, the improvements may be added to the Sprint Backlog for the next Sprint.
What are the benefits of Scrum?
To further examine the reasons behind Scrum’s popularity, we consulted an expert.
Our contributor, Ivan Gekht, PSM III, ICP-ACC, CSSC BB, DA-SM, is the CEO of Gehtsoft USA LLC, a company that specializes in custom software development and technology consulting services.
Ivan possesses some of the most recognized project management certifications, including Professional Scrum Master III, ICAgile Certified Professional — Agile Coaching, Six Sigma Black Belt Certification, and Disciplined Agile Scrum Master.
Ivan explained why the Scrum framework works well in complex project environments such as software development:
“Scrum was born to respond to the increased complexity of the software tasks teams were trying to solve. If you look at the Cynefin framework, the Scrum application will be in the Complex part of it: Probe — Sense — Respond approach.
Scrum allows using a similar or higher complexity system (an autonomous, creative, diverse, and cross-functional Scrum team) to solve a presenting complex problem. Scrum gave us the framework — a structured approach — to switch from predictive development methods, like Waterfall, and apply a different strategy to achieve the project goals.”
“In a project with many uncertainties. . . we lock the “When” and “How much” and work relentlessly to provide the highest value in a steady stream of releasable increments. So when you run out of money or time for the project, you have a working solution that might not give you everything you wanted but definitely solves your most important problems.”
When to implement Scrum?
Ivan Gekht highlights that Scrum isn’t intended solely for software projects but for other-industry projects as well:
“Scrum in no way is a software-specific framework. Moreover, in the roots of the Scrum lie Lean, Kaizen, and Toyota Production System — all manufacturing approaches that started in extensive production facilities.
You can use Scrum in any complex real-world problem-solving area of your business or industry. Sales, Marketing, HR, innovative manufacturing — any area can benefit from using Scrum or a similar approach. Because each of them works with complex people-oriented, or innovative problems.”
However, Ivan also stresses that not all projects will necessarily benefit from Scrum:
“We select the most appropriate methodology to do the work depending on the project’s particulars. On a start-up project with a lot of unknowns, even Scrum might be too heavy-formalized, and pure Kanban or ChatOps-style development with daily increments would be a better fitting. While on a long-term, clearly defined system, a PMBOK would be a better fit.”
Ivan shared a specific example of a project they worked on at Gehtsoft USA where Scrum did apply well:
“We use Scrum or similar methodologies on a lot of complex projects. One of the good examples of such a project was an ERP system for a coffee manufacturing company in Hawaii. We needed to establish a good cadence of stable deliveries because we started a project for them in late April, and the first time it had to be used in the field was in early June to input the records of one of the process steps. Throughout the summer, we delivered multiple releases, each time hitting the deadlines to ensure that the project was up and running by the time the following steps came into play.”
How to implement Scrum in project management
At this point, you’re probably wondering how exactly to implement Scrum in your organization.
Luckily, we’ve outlined 6 steps to Scrum project management implementation:
- Step #1: Assemble a Scrum Team,
- Step #2: Create a product roadmap,
- Step #3: Track day-to-day progress,
- Step #4: Run Sprint Review meetings,
- Step #5: Run Sprint Retrospective meetings, and
- Step #6: Use project management software.
Now, let’s explain what each step entails.
Step #1: Assemble a Scrum Team
The first step toward implementing Scrum is assembling your Scrum Team.
As having a good team increases the chances of implementing Scrum successfully, we suggest paying extra attention to this step.
To make a good Scrum Team, you should find the right people, those who have the necessary project management skills and understand Scrum well.
For example, you may look for people who already possess relevant project management certifications or invest in training your current staff.
But besides being skilled, your team should be motivated as well. As Ivan Gekht explains, Scrum is beneficial only if applied in the right way:
“When misused, Scrum may lead to a significant downfall. For example, an unmotivated team that does not measure its effectiveness and does not evolve to step up to the challenge will never be able to efficiently use the provided resources. In that case, using a “best practices” approach might be less risky and more rewarding while not being able to solve the most complex problems that require creativity.”
Step #2: Create the product roadmap
The product roadmap serves as a general overview of your plans and strategic goals concerning your product in the upcoming months or years.
You can think of a product roadmap as an initial version of your Product Backlog.
Only after you’ve outlined your roadmap, you can move on to creating a detailed to-do list of specific tasks — the Product Backlog.
Here’s an example of a product roadmap created in the Plaky project management tool:
Step #3: Track day-to-day progress (with Burn-Down Chart and the Scrum Board)
To track a Sprint’s progress, you can use the Burn-Down Chart and the Scrum Board, all while conducting Daily Scrum meetings.
Burn-Down Charts display the work left to be done on the vertical axis and time on the horizontal axis. The line showing the remaining work should trend to zero by the last day of the Sprint.
The Scrum Board, on the other hand, serves for tracking progress and consists of a minimum of 3 columns that indicate task status:
- To Do,
- Doing, and
Here’s what the Scrum board template looks like in the Plaky project management tool:
Step #4: Run Sprint Review meetings
As we’ve mentioned earlier, a Sprint Review is a working session in which the Scrum Team presents what was accomplished during the Sprint to key stakeholders and discusses the progress toward the Product Goal.
Team members and stakeholders together take the following actions as part of the Review:
- Inspect the Product Increment,
- Evaluate how the completed work impacts progress toward the Product Goal, and
- Update the Product Backlog to maximize the value of upcoming Sprints.
Reviewing and adapting are vital processes in Scrum implementation as they enable the Scrum Team to grow and mature with each Sprint.
Step #5: Run Sprint Retrospective meetings
During a Sprint Retrospective, the Scrum Team reviews the past Sprint and plans improvements for future ones.
During each Sprint Retrospective, the Scrum Team makes plans on how to improve product quality in one of 2 ways:
- By improving work processes, or
- By adapting the Definition of Done (by checking if it is suitable and not in conflict with product or organizational standards).
Abhay Talreja shares an example of how a Sprint retrospective meeting may serve as an opportunity for the Scrum team to improve certain matters that didn’t work well in the past Sprint:
“For example, a team might realize that their daily stand-ups run too long. They might decide to implement a stricter time limit or adjust the format to make them more efficient. The key here is creating a safe, open space for the team to learn and improve.”
Step #6: Use project management software
Using an agile project management tool in Scrum promotes transparency, which is one of Scrum’s core values.
For example, the Plaky project management tool promotes visibility as it allows everyone to see what other team members are working on and track the progress of their tasks.
Plaky is a suitable project management tool for Scrum as it allows you to perform the following tasks:
- Create separate Plaky boards for every Sprint,
- Assign ownership of tasks,
- Attach important files,
- Add comments and mentions, and
- Stay updated with all changes via Plaky notifications.
Scrum vs. Agile
First of all, let’s clarify the most common misconception regarding Scrum and Agile — Scrum is not equivalent to Agile.
However, Scrum is an Agile framework, just like Kanban or eXtreme Programming (XP).
Scrum is most commonly confused with Agile due to being the most popular framework used for the implementation of Agile project management principles and values.
Namely, Agile is a specific mindset and a way of handling the work needed to complete a project through iterations based on customer feedback.
💡 Plaky Pro Tip
If you want to learn more about Agile in project management, check our guide:
Scrum vs. Kanban
Kanban is another popular Agile framework.
Kanban is the process of visualizing your workflow that can be applied to many different industries.
Teams who use the Kanban framework use its Kanban boards for task monitoring.
Similar to the simplest version of a Scrum Board, Kanban boards include at least 3 columns, including:
- To do,
- In progress, and
Here’s what the Kanban board looks like in the Plaky project management tool:
As you can see in the picture, the project phases are divided into 3 columns we’ve mentioned before, while each column has cards with specific tasks within it.
The Kanban board allows you to move the cards freely from one column to another until the task is completed.
Kanban helps teams boost efficiency and transparency as each team member has a clear insight into how long it takes each task to move across the board until realization.
While Scrum utilizes Sprints, prescribed roles, and ceremonies (i.e. events) for better organization, Kanban focuses on visually organizing your work.
💡 Plaky Pro Tip
To learn about the combination of Scrum and Kanban, read the following guide:
Scrum vs. Waterfall
While Scrum is an Agile project management framework, Waterfall is a traditional project management methodology.
Unlike Agile, Waterfall isn’t as flexible.
As it’s linear in nature, Waterfall maps out projects into separate, sequential phases, and tasks are performed in a certain order.
So, in Waterfall, each phase starts when the previous one ends.
While Waterfall is a sequential approach, Scrum is a cyclic approach that is flexible and continually evolving.
💡 Plaky Pro Tip
Find out more about Waterfall in project management in our guide:
If you’re looking to get training and certification in Scrum, you should probably look into some of the most well-known organizations providing relevant training and courses, including:
- Scrum Alliance,
- The Project Management Institute (PMI), and
- Scrum Inc.
Here are some of the certifications Scrum.org provides:
- Professional Scrum Master (PSM I, II, III),
- Professional Scrum Product Owner (PSPO I, II), and
- Professional Scrum Developer (PSD).
Some of the certifications the Scrum Alliance offers include the following:
- Certified ScrumMaster (CSM),
- Advanced Certified ScrumMaster (A-CSM),
- Certified Scrum Product Owner (CSPO),
- Advanced Certified Scrum Product Owner (A-CSPO),
- Certified Scrum Developer (CSD),
- Advanced Certified Scrum Developer (A-CSD), and
- Certified Scrum Professional (CSP).
Some of the certifications the PMI offers include the following:
- Disciplined Agile Scrum Master (DASM), and
- Disciplined Agile Senior Scrum Master (DASSM).
Some of the Scrum Inc. certifications include the following:
- Registered Scrum Master (RSM),
- Registered Product Owner (RPO),
- Registered Scrum@Scale Practitioner (RS@SP),
- Registered Scrum Master@Scale (RSM@S), and
- Registered Product Owner@Scale (RPO@S).
Wrapping up: Scrum provides adaptive solutions for complex problems
There’s no doubt that Scrum is the most popular Agile framework, trusted and used by teams worldwide.
With its emphasis on continuous releases, Scrum aims to simplify what’s complex and achieve value through change.
The popularity of Scrum likely stems from its ability to fulfill its primary goal successfully — solving complex problems with adaptive solutions.
Scrum glossary of terms
Scrum Team — a self-managing team comprised of the Product Owner, Scrum Master, and Developers.
Sprint — a Scrum event, typically lasting no longer than 1 month, during which all work required to achieve the product goal happens.
Sprint Review — a Scrum event that serves to review finished work and decide whether additional changes are required.
Sprint Retrospective — a Scrum event with the goal of inspecting the past Sprint and planning improvements for the next one.
Daily Scrum — a daily, 15-minute meeting where Developers say what they plan to work on for the next 24 hours.
Definition of Done — a shared understanding within the Scrum Team of what it takes to make a Product Increment releasable.
Scrum Board — a physical board that serves for visualizing information for and by the Scrum Team. It can be in the form of a whiteboard, wall post-it notes, or project management software.
Scrum Artifacts — artifacts that express work or value intended to maximize the transparency of critical information.
Burn-Up Chart — a chart that displays work that has been completed, with time presented on the horizontal axis and finished work on the vertical axis. As time passes and tasks are completed, the line showing the work done is expected to rise.
Burn-Down Chart — a chart that displays the rate at which the project workload is completed versus the remaining workload. As time progresses and tasks are completed, the line showing the remaining work is expected to fall.
📖 Scrum might be the most popular Agile framework, but it’s not the only one. Check out our Project Management Glossary of Terms to learn more about different Agile frameworks and other advanced project management terminology.
- 16th State of Agile Report: Resource Center. Digital.ai. (2023, April 18), from https://digital.ai/resource-center/analyst-reports/state-of-agile-report/
- Crail, C. (2021, November 3). What Is A Scrum Board? Should You Make One? Forbes Advisor. Retrieved March 10, 2022, from https://www.forbes.com/advisor/business/what-is-a-scrum-board/
- Layton, M., & Morrow, D. (2018). Scrum For Dummies, a Wiley brand.
- Madan, S. (n.d.). DONE Understanding Of The Definition Of “Done”. Scrum.Org. Retrieved March 21, 2022, from https://www.scrum.org/resources/blog/done-understanding-definition-done
- Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf#zoom=100
- Scrum.org. (n.d.). Scrum Glossary. Retrieved March 9, 2022, from https://www.scrum.org/resources/scrum-glossary
- Scrum Alliance. (n.d.). What Are Agile and Scrum and How Are They Different? Retrieved March 10, 2022, from https://resources.scrumalliance.org/Article/what-are-agile-and-scrum-and-how-are-they-different
- Scrum Alliance. (n.d.). These are the Differences Between Agile and Scrum, and How They Differ From Waterfall. Retrieved March 16, 2022, from https://resources.scrumalliance.org/Article/differences-agile-scrum-differ-waterfall