Your own experience with scrum will be impacted by your company, your team, and what you are working on. Whether you are interested in learning more about scrum, are considering implementing scrum in your organization, or want to gut-check the processes on your current team, this guide offers a broad overview of scrum essentials. With that in mind, you can always jump ahead to the section that most applies to you:
The history and evolution of scrum
While concepts of self-organizing teams and iterative development were bandied about as early as the 1950s, the principles at the heart of scrum really took off in the 1980s. In January 1986, Professors Hirotaka Takeuchi and Ikujiro Nonaka published an in-depth think piece in Harvard Business Review titled “The New New Product Development Game.” Takeuchi and Nonaka explained their “rugby method” using case studies from companies such as Epson, Canon, Fuji-Xerox, and Honda.
Takeuchi and Nonaka compared the old way of product development to a relay race. As a product moved through cycles of development, each phase was passed to a functional specialist. With functional specialists typically applied across various projects, this virtual baton passing could impact the speed of delivery. Each function was also segmented, with limited knowledge sharing across groups.
Compare that to the rugby approach. Instead of passing a baton from one player to the next, the team would pass the ball back and forth as they moved up the field together. In development, this meant a smaller cross-functional team would tackle new product development holistically — from concept to delivery.
The professors wrote about the concept of multilearning. Individuals would share knowledge (aka pass the ball) at critical phases of development. Any gaps would be filled through acquiring new skills along the way or bringing in new teammates while others dropped off. Takeuchi and Nonaka posited that the rugby method had the potential to revolutionize how organizations brought new products to market. They also included some cautions, including managerial implications and the potential for overworked teams.
Momentum around the rugby approach increased with broader implementation at many forward-thinking companies in the late 1980s. Software engineers Ken Schwaber and Jeff Sutherland, and original signers of the Agile Manifesto, proposed an initial framework for what would become scrum in 1995. (Although they stylized the word in all capital letters, lowercase is common today.) In 2010 they co-authored and published the Scrum Guide, an online resource documenting the basics and evolution of scrum. Both Schwaber and Sutherland have gone on to found nonprofits that offer scrum training and certification.
Related: The Beginning Of Scrum by Scrum.org
Today, scrum is inarguably the most popular agile framework in business and IT organizations. The 16th annual "State of Agile" report for 2022 showed that scrum far outpaced any other framework or method — 87 percent said they leverage scrum, compared to 50 percent who leverage kanban. The report surveys more than 3,000 IT and business professionals about trends, milestones, and challenges.
Related: Best practices for configuring Aha! Develop to support scrum
Scrum has been a process improvement buzzword since the 1990s, but the scrum framework has since expanded well beyond developer communities into other disciplines. Marketing teams, sales teams, and even healthcare teams find value in incorporating scrum into their workflow management. A survey of more than 1,300 IT and business leaders published by Harvard Business Review revealed that four-fifths of respondents were using agile practices in core functional groups outside of engineering or development:
Research and development: 83 percent
Production and operations: 82 percent
Customer service and support: 79 percent
Marketing and communications: 79 percent
Sales: 78 percent
HR, finance, and administration: 78 percent
That is a lot of scrum. As we all know, however, popularity can be polarizing. Unlike other agile methods that do not have fixed processes, scrum is a defined framework. There are rules to follow and certifications to obtain. People can be pedantic about both. Simply following a specific framework does not guarantee immunity from the challenges that lead many organizations to adopt a particular methodology in the first place — from dysfunctional company culture to fast changing business markets. There is also always the risk that you spend more time focusing on the method than on the work itself.
Top
Difference between scrum and agile
The differences between scrum and agile are not always obvious. Add to that the fact that many companies will adopt scrum and refer to it as “going agile” — well, you can see where the field gets muddy. Questions and confusion abound.
Is scrum a methodology? What is agile without scrum? Can you be agile without a scrum master?
The key to answering these questions is to remember that agile is a philosophy, not a methodology. Scrum is a process framework. You can embody agile values without following a specific framework.
Related: Reasons to agile with a little "a"
Top
What are the theories, values, and practices of scrum?
Scrum was founded on empiricism. In philosophy, empiricism refers to the idea that rational beliefs are only proven through experience. The prevailing theory behind scrum is that knowledge is gained through experience and decisions are made based on what is known. In practice it is informed by lean principles — less waste, with a focus on the most essential work.
Three pillars of scrum
Scrum teams build their processes on three core pillars:
Transparency: Facts are presented with clarity and everyone collaborates openly.
Inspection: Work, processes, and practices are examined often to understand progress and uncover flaws.
Adaptation: Adjustments happen as a result of what is discovered during inspection.
The first pillar is common in agile methods — the team responsible for completing work must have a shared understanding of the process for doing so (e.g. “definition of done”).
The second two pillars are unique to scrum. There are four formal events for inspection and adaptation throughout a sprint (we will cover these in more detail later in this guide):
Sprint planning
Daily scrum
Sprint review
Sprint retrospective
Five values of scrum
In order to successfully follow and benefit from the empirical pillars of scrum, the originators of the framework suggested a shared set of values that every scrum team should embody:
Commitment: Teammates are committed to progress within a sprint, as a team, and as individuals.
Courage: Teammates have the inner fortitude to solve hard problems and improve over time.
Focus: Teammates focus on the sprint and the goals of the team.
Openness: Teammates are open to working with each other, giving and receiving feedback, and sharing issues.
Respect: Teammates respect each other's experiences, knowledge, decisions, and insight.
Top
What are scrum roles?
The benefit of a process framework is that you have a defined structure. Scrum does not disappoint in this regard. There are distinct roles, events, and artifacts that teams must organize and follow.
Note the word “must.” According to scrum practitioners, scrum is an excellent container for other methodologies or practices. But scrum is not possible unless implemented in its entirety. You cannot pick and choose elements buffet-style.
The sections below outline the general elements of scrum — the team roles, events, and artifacts. For detailed definitions, check out the scrum glossary.
Scrum team
The scrum team is a cross-functional group — everyone on the team contributes to developing the product at every phase. Scrum teams have a few other attributes in addition to embodying the values outlined earlier. Each team consists of a product owner, scrum master, and developers.
Product owner | A scrum team product owner serves as a representative of internal and external stakeholders. Product owners are responsible for maximizing the value that a product delivers by communicating product goals, translating business and functional needs into product backlog items, and organizing the product backlog. There are certifications and advanced training paths that can help product owners grasp all facets of the scrum framework. However, there are broader skills needed to be a successful product owner such as technical knowledge, customer awareness, and business acumen. |
Scrum master | A scrum master serves as a scrum team's coach and guide, facilitating full adherence to the scrum framework. Typically this person has obtained certification or advanced training in scrum and possesses a complete understanding of scrum values and practices. Depending on the maturity of the scrum team, the scrum master may be deeply involved in all aspects of development (from leading daily standups to holding 1:1 meetings with individual teammates) or have a more lightweight hand in steering a seasoned scrum team. |
Developers | Developers are members of a scrum team who contribute to any aspect (regardless of the person’s technical specialty) of delivering usable increments in a sprint. |
Scrum teams are small. They typically have no more than 10 people, with no sub-groups or hierarchies. Scrum teams may grow larger depending on the scope of what they are working on. In these situations it is recommended to split the group into multiple scrum teams that share the same product owner and product backlog with a different scrum master for each team.
Product manager vs. product owner
You may have noticed one critical role in product development that is missing from the table above. Where is the product manager? Product managers do have a role in agile organizations and, yes, even in scrum. So it is important to understand role definitions here.
Product managers are outwardly focused — experts in the market, customers, positioning, and pricing. These folks are responsible for setting the vision, goals, and major initiatives for the product. They own the Complete Product Experience, from forecasting to realizing business value to end of life. Product managers do high-level product planning and own the product roadmap.
Product owners are inwardly focused. They may influence certain areas of the product manager’s responsibilities, such as release planning and feature definition. But their main focus is to serve as a representative of the customer and advocate for the business case on the scrum team. They are the only people who can change the order of features in the product backlog and who decide whether to release a sprint.
Related: What is the role of a product manager in scrum?
In some organizations, the product manager assumes the responsibilities of the product owner. This is not ideal. These are discrete roles that require different skill sets and full attention. When you try to get two for the price of one, you can easily end up with a person who has an unrealistic workload and compromised priorities.
Related: Product manager vs. scrum master
Top
What are scrum events and artifacts?
Sprints are critical to successful scrum implementation. A sprint is a fixed duration of work. The time range will vary, but to truly follow scrum you should aim for less than a month for each sprint. Many scrum teams work in two- or three-week sprints. Once a sprint is finished, the next one begins.
If the problem that the team is trying to solve is too complex and requires more time than one month to deliver real value, that problem should be broken down into smaller increments for faster learning. Things can get unwieldy otherwise since, according to scrum principles, major changes should not occur during the sprint. Scope can be reviewed and revised by the product owner during a sprint as new learnings occur. However, quality should not decrease and the goal of the sprint should not be adjusted during the sprint.
Here is a summary of the four scrum ceremonies that take place during each sprint:
Sprint planning — The product owner and development team meet to agree on the goals of the sprint and prioritize upcoming work.
Daily scrum — The scrum team gathers for a quick meeting (also called a daily standup) to share what they worked on yesterday, what they plan to work on today, and any obstacles they face.
Sprint review — The development team demos their work and gathers feedback from the product owner and other cross-functional teammates.
Sprint retrospective — The scrum team evaluates what went well and what did not go according to plan. Then they collectively decide how to improve future sprints.
These scrum events help the team stay aligned on goals, track progress, and adjust processes — so everyone is productive and upcoming sprints go more smoothly.
Related: What is an agile retrospective?
Scrum artifacts
There are a few basic artifacts in scrum — the product backlog, sprint backlog, and increments. Each one reflects work to be done or value to be delivered. We will start with the first two since they are related.
The product backlog is an organized list of work that can be prioritized into a sprint as part of sprint planning. These items have been identified as necessary enhancements or new functionalities that bring value to the product. Refinement (sometimes called “grooming”) of the backlog can occur, where the work items are further broken down into smaller units. Product owners may influence estimates, but developers are ultimately responsible for sizing items in the product backlog since they are the ones who will do the work.
The sprint backlog is more than just a list of work — it is a plan. It includes the goal for the sprint, the collection of items selected from the product backlog, and an actionable outline for how the team will complete the work. The sprint backlog is created and managed by developers on the scrum team.
Now onto the increments. These are the usable features that support your overarching product goal. Or said another way, increments are the sum of all the items in your sprint backlog. You might deliver one increment in a sprint or several — an increment can be delivered to stakeholders during the sprint (rather than at the end) if it is ready. No need to wait. For a sprint to be successful, each increment must meet the team’s definition of done regardless of whether the product owner releases it or not.
Scrum board vs. kanban board
Scrum and kanban are two very different approaches to managing work. While scrum is a defined framework that requires teammates to follow the structure explicitly, kanban does not have the same level of definition and can be a flexible solution for any team structure. (If you are interested in learning more about kanban, we also have an in-depth guide to kanban.)
The one thing that both approaches have in common is that work is managed on a board. Some organizations might have a physical board (you are probably picturing a white board covered in colorful sticky notes) but most sophisticated teams today use purpose-built software that offers digital scrum and/or kanban board functionality.
Scrum boards are more intensive than kanban boards, and require more upfront investment to configure as a result. The table below explains the basic differences between a scrum board and a kanban board.
| Scrum | Kanban |
Owners | Scrum boards are owned by one scrum team and managed by a scrum master. | Kanban boards can be used by many teams since the board is mostly about workflow, not what you are working on. |
Backlog | The scrum board has its own backlog of items that have been organized and prioritized from the product backlog into the sprint backlog. | The kanban board has a backlog of items. Each has an assigned level of importance and clear objectives. |
Prioritization | Items on the scrum board are prioritized according to resource estimation by the scrum team during daily scrums. | Items on a kanban board do not have a prescribed prioritization method, but may be weighted by urgency. |
Work-in-progress (WIP) limits | Scrum boards limit WIP by sprint, but not by progress. There is no limit, for example, to how many items can be “in progress” at once. | Kanban boards limit WIP by workflow status. |
Tasks | The scrum team is responsible for all tasks on the scrum board. | People are responsible for completing their steps within the workflow, but not responsible for all tasks on the kanban board. |
Changes | Only members of the scrum team can edit or change the scrum board. Product owners should not make changes to a sprint in progress. | Anyone can make changes to the kanban board. Since kanban is not associated with a fixed timeline, changes can happen at any time. |
Duration | Scrum boards are reset at the end of each sprint. | Kanban boards represent ongoing workflows and are continuous without any fixed timelines. |
Reporting | Scrum boards are measured by reporting against velocity with burndown and velocity charts. | Kanban boards are primarily measured by average cycle time of items — how long it takes for each item to go from being added to the backlog to completion. |
Top
Pros and cons of scrum
Scrum is incredibly popular within the agile software development community. Something must be going well with this framework, right? Followers say that scrum ensures high-quality work, increased efficiency, and adaptability — each important in often unpredictable software development environments.
Scrum can illuminate challenges early on. Daily scrums provide a forum for tracking progress and spotting surprises that could derail development. These meetings can also keep teams motivated and encouraged, since the tasks that each teammate accomplishes are showcased often.
Since teams work in fixed intervals, changes can be incorporated into the next sprint. It is possible to consistently deliver value without holding back functionality for code clean up or bug fixes. There are two sides to that flexibility though.
Scrum projects do not have a fixed timeline. That might be confusing at first, since we have repeated often that sprints are a specific duration. Remember, that a sprint is just a container and you might have many sprints before you achieve the overall product goal. In scrum there is no specific end date for projects, so you can end up with delays or scope creep. It is tempting to keep adding functionality knowing that you can always put it in the next sprint.
Scrum teams test their own software — so you may be able to catch and fix defects early on. But when many scrum teams are working on the same product, you can end up with a single point of failure: testing. Remember that an increment must be usable to fit the definition of done.
There is another major limitation that comes with any methodology or process framework. You are reliant on people. At its essence, a company is a collective of people working together against a shared goal. Implementing scrum successfully requires buy-in from everyone in the organization.
Scrum teams should not have hierarchies. But there can be tensions between the product owner, scrum master, and development team. Without openness and trust, infighting and an “us vs. them” mentality can emerge. Developers might be tempted to exclude product owners or scrum masters from meetings thinking that it is up to them to figure out the “how” of the sprint.
Scrum can be shocking to people who are set in particular work patterns. Organizational barriers may need to be removed and that kind of transformation can be painful. Scrum teams work independently, which requires a huge amount of trust — both from stakeholders, in the product owner and scrum master, and within the team. People may resist perceived roadblocks introduced by the new structure.
These issues are not unique to scrum. Most of these issues are the result of negative company culture. That is why the best scrum teams hold true to those five scrum values of commitment, focus, openness, respect, and courage. Think of the values as a touchstone that centers your team and keeps you focused on why you want to build software in the first place — to create something that brings value to the world.
Top
Common scrum metrics
Scrum teams embrace incremental, ongoing improvement in order to deliver value to customers and the business. Tracking scrum metrics allows you to objectively measure performance — typically a specific aspect of your team's productivity, predictability, quality, or value.
The following scrum metrics are examples of data points you can use to increase efficiency, refine processes, and make decisions on when to pivot:
Burndown: A burndown captures the amount of work you have completed against the amount of work remaining in the sprint. Most scrum teams measure work in time, story points, or number of tasks. Display burndown as a trend line on a burndown chart to easily visualize the team's progress.
Progress towards sprint goals: Remember the goals you set during sprint planning? Keep these objectives top of mind by evaluating the team's progress towards achieving each goal. You can measure progress via a percentage completed or some other numerical ranking.
Team capacity: Successful sprints rely on accurate capacity planning — otherwise you will commit to accomplishing more than is possible during the sprint. This is why many scrum teams add up each team member's availability for the next several sprints to calculate total team capacity. Be sure to build in extra time for vacation, illness, and any unexpected absences.
Velocity: Velocity refers to the average amount of work the team can complete during a sprint. By measuring finished work against time, you can better estimate progress and plan future sprints more accurately.
Workload distribution: How much work is each scrum team member responsible for in a given time frame? Workload distribution shows how much work is assigned to each team member for the sprint — so everyone can see each person's workload and capacity.
This sprint burndown report built in Aha! Develop helps you analyze your entire team's progress or focus on individual team members.
While these metrics are commonly associated with scrum, keep in mind that they can be useful no matter which methodology you follow. For example, teams that subscribe to kanban or another agile philosophy may frequently rely on burndown charts and velocity estimates. This can be highly valuable information whether or not you are part of a scrum team.
Top
Scrum certifications and courses
There are many online scrum training courses and certifications you can pursue. These are not always required to practice scrum, but some organizations will require certification for a particular role and many will sponsor employees who are interested in obtaining one. Hands-on instruction can be especially helpful if you are new to software development.
You can find plenty of scrum workshops and courses on free educational platforms, such as Coursera and LinkedIn Learning. Some give attendees an in-depth overview of the topics covered in this guide. Others offer preparation courses for people who want to obtain a certification.
There are a few organizations that offer scrum certifications, with varying costs, levels of competency, and coursework required:
Related: How to choose a scrum certification
