The Scrum framework is the most popular agile framework today. Organizations across geographies and sectors are using Scrum to build self-organized teams that take products to market faster and solve complex problems in an agile way.
Much has been said and written about Scrum. And though “all you could possibly want to know” is indeed a clickbaity title, in this post I’ve tried to collect the answers to the most common questions that people ask about Scrum on the Internet.
No matter if you’re just getting started with the Scrum framework or have been using it for a while, but are curious about where it comes from and what makes it work so well, keep on reading.
What Is Scrum?
Scrum is a lightweight framework that allows teams to build complex products.
The Scrum framework was created by Jeff Sutherland and Ken Schwaber in the 1990s. Sutherland and Schwaber are also two of the 17 creators of the Manifesto for Agile Software Development.
As agile spread in fast-growing startups and tech companies in the early 2000s, Scrum also grew into the most popular and widely-adopted agile framework in the world. Today, Scrum Alliance and Scrum.org, the two training organizations founded by Sutherland and Schwaber, have collectively trained and certified millions of professionals in Scrum.
What Scrum Is Not
Scrum isn’t a methodology for software development. Unlike Extreme Programming (XP), Scrum doesn’t prescribe specific methods for how to build software in an agile way. Scrum is a product development framework that’s intentionally lightweight and purposefully incomplete.
Like an empty office room in a newly-constructed building, the utility of Scrum comes from the structure that it gives you—and the emptiness that it allows you to use the room as you need.
Scrum isn’t the solution to all people, process, and technology problems. If the organization and leadership team are unwilling to respect the judgement and commitments of the Scrum Team, the Scrum framework won’t work. If the Scrum Team chooses to adopt only what they think will work for them from the framework, they’ll have a harder time getting results.
If the mindset of the team and its stakeholders isn’t agile (or their approach isn’t empirical), the fault is not in Scrum. Scrum can allow the Scrum Team using the framework—and the stakeholders who communicate and collaborate with them—to solve these problems. Only if they acknowledge them as such and choose to do so.
Scrum can’t be taught in a couple of days. As much as some companies that provide Scrum training want to convince you otherwise, Scrum isn’t something that you can learn in a couple of days—no matter how good the trainer. Scrum is a framework that helps you solve complex problems. It’s easy to understand (the 2020 edition of the official Scrum Guide is only 14 pages long, including the cover page and table of contents), but it’s also difficult to master.
To use Scrum to their competitive advantage, organizations, teams, and individuals need to take a long-term view adopting an agile mindset and applying it with the help of the Scrum framework. Using Scrum is an investment in time, patience, and craftsmanship.
Scrum isn’t just for software developers. Yes, the agile movement and the Scrum framework started out in software development teams, within the software development field. Today, it’s 25 years since Scrum was created and nearly two decades since a group of 17 programmers signed the Agile Manifesto.
The agile mindset and the Scrum framework are no longer limited to people in the software development field. Today, they’re used by Saab to build fighter jets, John Deere to develop connected tractors, and the National Public Radio in the U.S. to pilot radio shows that people actually want to listen to.
And this is just a small set of examples from thousands of companies that use agile and Scrum to get things done smarter, faster, and cheaper.
How Scrum Works
In Scrum, a Scrum Team of 10 members or fewer builds a product in an iterative and incremental way by working in short cycles called “sprints” and shipping the product in small chunks called “increments.”
Working in sprints and shipping in increments, a Scrum Team achieves a unique rhythm and a sustainable pace of agile delivery in the long term. The product is the sum of all increments shipped by the team and the value is the outcome of the product and its usefulness to the organization that sponsors it, customers who pay for it, and users who use it.
The Theory Behind Scrum
The Scrum framework is founded on the principles of empiricism and lean.
Empiricism is a philosophical school of thought according to which the best way to obtain knowledge is through “sensory experience.” Empiricism began with the emergence of experimental science in the 17th and 18th centuries. To a large extent, it gave the foundation of science and the scientific method as we know them today.
Lean is a managerial approach created by Toyota and a number of other Japanese companies in the 1930s. Lean companies maximize the delivery of value and eliminate waste by focusing on what creates value for the customer, visualizing how that value flows in the delivery process, and continuously streamlining that flow by making small changes that improve it and removing the steps that create inefficiencies.
The Three Scrum Pillars
Scrum works by taking some of the core principles of empiric thinking and lean product development—and combining them with the practice of close customer collaboration. In doing so, the Scrum framework describes three “pillars” of the framework:
- Transparency. The key to making Scrum work is making work visible. This is done through the three artifacts of Scrum: the product backlog, the sprint backlog, and the increment.
- Inspection. Frequent inspection allows the Scrum Team to welcome change at any stage of the project and adjust their plans as necessary. This is done through the five Scrum events: Sprint Planning, Daily Scrum, Sprint Retrospective, and Sprint Review.
- Adaptation. When a Scrum Team learns something new through inspection, they are expected to adapt. Adaptation can happen through course-correction or through continuous improvement.
Scrum is best used for products, problems, initiatives, programs, and projects where the vision, mission, goal, and/or objectives are clear, but how to achieve them is not. The Scrum framework allows a Scrum Team to self-organize by optimizing predictability and controlling risk through working in short cycles, shipping in small chunks, and seeking out feedback early and often.
The Five Scrum Values
The Scrum framework is built on five values:
- Commitment
- Focus
- Openness
- Respect
- Courage
Everything the Scrum Team does is a commitment. The product has a product goal. The team’s commitment to the product goal is reflected in the work items on its product backlog, sprint goals, and sprint backlogs, as well as the increments they ship within their sprints.
For the Scrum Team to make their commitments, focus is key. Focus is as much about what the team chooses to do as it is about what they choose not to do. The best-performing Scrum Teams are highly selective about what they focus on.
Openness, respect, and courage are essential for the team and its members to communicate and collaborate between themselves and with their stakeholders.
Openness allows them to talk about the state of things as it is, without masking it in politics.
Respect enables them to value each other’s opinions and contributions, so that they can partner up to a common vision, mission, and set of goals.
Courage permits them to challenge the status quo as needed. Without courage, the team’s members cannot be open and respectful to each other.
Roles, Events, and Artifacts
The Scrum framework has roles, events, and artifacts—as well as the rules that help a Scrum Team to use them. The rules are described and kept always up-to-date in the official Scrum Guide (scrumguides.org). Every few years or so, the creators of Scrum enhance the guide.
All requirements for the product are captured on the product backlog. The product backlog is a live artifact that contains descriptions of the work the team is focusing on the order/sequence and/or criticality/priority of each work item. Different teams describe their work items in different levels of specificity and granularity.
There are only three roles in a Scrum Team: the Product Owner, the Scrum Master, and the Developers. The Product Owner is there to maximize the value of the product that the team is building. The Scrum Master helps the team to practice Scrum and apply the agile mindset. Anyone who helps to build the product is a Developer (whether they write code or not).
The Scrum framework has 5 events:
- The Sprint
- The Sprint Planning
- The Daily Scrum
- The Sprint Retrospective
- The Sprint Review
The Sprint
The Sprint is simply a container event for the remaining 4 events.
Scrum Teams work in sprints typically 1 to 4 weeks long, with a preference for the shorter timeframe. This allows them to welcome change, deliver in small chunks, and seek out feedback early and often. In my experience, most Scrum teams work in 2-week sprints.
A sprint is nothing but a timebox. It has a start date and an end date, determined by the sprint duration. The sprint is like an hour on the clock or a day in the calendar. It’s there to help the team manage time—and is fully independent from what goal and items they use it for.
The Sprint Planning
Each sprint starts with a Sprint Planning, where the Product Owner lays out a sprint goal. They then collaborate with the Developers to determine which work items from the product backlog will help the Scrum Team achieve that sprint goal. Each work item from the product backlog that a Developer can commit to can go in the sprint backlog.
The effective Sprint Planning meeting is a conversation between the Product Owner and the Developers on what creates value. During the course of the conversation, the Developers need to make commitments and the Product Owner needs to make trade-offs. The Sprint Planning is as much about what the Scrum Team will not do as it is about what it will do during the sprint.
The Daily Scrum
During the course of the sprint, the Developers meet for 15 minutes every day to inspect their progress toward the sprint goal—and to adapt the sprint backlog as needed. This is called the Daily Scrum meeting. The Daily Scrum usually happens at the beginning of the day. The team uses it to identify the need for breakaway conversations or working sessions.
The effective Daily Scrum is not a status report meeting, but an act of communication and collaboration. High-performing Scrum Teams use the Daily Scrum to inspect and adapt their plan (the sprint backlog) for how to best achieve the sprint goal. The Daily Scrum is as much about syncing up as it is about correcting the course as necessary.
The Sprint Retrospective
Before the end of a sprint, the members of the Scrum Team get together on the Sprint Retrospective meeting to discuss what went well, what could have gone better, what problems they faced, and which problems they solved or didn’t solve. The Sprint Retrospective allows the team to practice kaizen, a Japanese term for continuous improvement.
In newly-formed Scrum Teams, the Sprint Retrospective is usually focused on how to follow the rules of the Scrum framework. Though that’s necessary (and useful) in the early stages of a Scrum Team, the most effective Sprint Retrospective happens when its members focus on the substance; not the form—and continuously weed out the root causes of their problems instead of talking about the symptoms.
Achieving a Sustainable Pace
In any project that uses the Scrum framework, the Scrum Team is working to make two things happen:
- Achieve the product goal;
- Achieve a sustainable pace of agile delivery.
The product goal is the highest-level goal that the Scrum Team is working toward. It informs the product backlog, as well as the individual sprint goals and sprint backlogs that the team commits to. Once the Scrum Team has achieved the product goal, they focus on a new one.
Like the best drivers in NASCAR or leading cyclists on the Tour de France, it is the sustainable pace of agile delivery that enables the team to keep achieving product goals faster and better. To time their pace, the team estimates their work in story points and measures their delivery in velocity.
Story points are a relative estimate of the effort it takes to complete a single work item on the product or sprint backlog. Story points are based on the Fibonacci sequence (0, 1, 1, 2, 3, 5, 8, 13, 21, 34, …, n). Velocity is the amount of work complete as measured by the number of work items completed (in other words, work that meets the team’s Definition of Done) for a single sprint.
Internally, the team uses story points and velocity for two reasons:
- To make better-informed commitments;
- To surface systemic problems that they can solve together.
Externally, the team uses story points and velocity for two reasons:
- To make better-informed product roadmaps;
- To project their progress toward target/delivery dates.
Whatever the use case, the Scrum Team and its stakeholders always remember that story points are relative estimates and software development is an empirical process. The only way to tell if a plan is going to work out or not is to focus and try to make it happen.
The Sprint Review
The Sprint Review is the last and final event of a sprint because it concludes the sprint. At the review, the Product Owner invites all relevant stakeholders who have an interest to inspect the increments delivered by the team in the sprint—and give the team their feedback to help them adapt their plans for the next sprint/s to come.
Most Scrum Teams treat the Sprint Review as a demo. And most stakeholders choose to stay silent throughout it. The effective Sprint Review is a conversation and a collaboration, where the team and its leaders, sponsors, customers, and/or users interact to understand what has been built and discuss what could be built next that creates the highest value.
The Backlog Refinement
The “sixth” and “hidden” event in Scrum is the Backlog Refinement meeting. To have a productive Sprint Planning, the Scrum Team needs a product backlog of ready work items that they can commit to delivering to meet the sprint goal.
The Backlog Refinement meeting is the event in which some of all members of the Scrum Team meet and refine the product backlog. As an outcome of the Backlog Refinement, the product backlog contains well-formulated and readily-estimated work items the team can work on.
Who Created the Scrum Framework?
The Scrum framework was created by Jeff Sutherland and Ken Schwaber in the 1990s.
Scrum was used for the first time in 1993 to build the first object-oriented design and analysis tool that incorporated round-trip engineering. This happened at Easel Corporation, where Jeff Sutherland was VP of Object Technology.
In 1995, Jeff Sutherland and Ken Schwaber presented the Scrum framework for the first time in their paper called “Scrum Development Process” at the annual OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) research conference.
At the time, Ken Schwaber was CEO of Advanced Development Methodologies (ADM), a company whose mission was to help improve the software development practice. Easel Corporation was acquired by another company in 1995 and Sutherland joined Individual in 1996, where he and Schwaber introduced Scrum as the software development process.
In 1996, Sutherland joined a company called IDX Systems as CTO and Senior VP of Engineering and Product Development. IDX Systems was one of the biggest companies that built software for the healthcare industry at the time—Sutherland and Schwaber used it as a proving ground for the Scrum framework and worked with numerous teams to implement it.
In the early 2000s, Sutherland and Schwaber were part of the group of 17 software development thought leaders who got together on a ski retreat in Snowbird, Utah, and created the Manifesto for Agile Software Development, giving the start to the agile mindset as we practice it today.
Why Is It Called “Scrum?”
The name “Scrum” comes from a January 1986 article in Harvard Business Review called “The New New Product Development Game” by Harvard Business School professor Hirotaka Takeuchi and organizational theorist Ikujiro Nonaka.
In the 1980s, a number of American and Japanese product companies like 3M, Brother, Canon, Hewlett-Packard, and Honda were significantly outperforming their peers. Takeuchi and Nonaka studied these companies to find out what they were doing differently to be more innovative and bring better products to market faster than their competition.
They discovered that each of these companies used a new and similar approach to developing products. The companies would build cross-functional teams, task them with complicated challenges, and allow them to self-organize as they came up with the solutions.
Often, these teams had no beaten path to walk on, so they couldn’t come up with an end-to-end project plan to deliver in a linear and sequential way. Instead, the teams worked in overlapping phases that enabled them to respond to change and regroup when bottlenecks appeared.
Takeuchi and Nonaka likened this way of work to a game of rugby and the scrum formation. A “scrum” is a way to restart a paused game of ruby where players pack down closely together with their heads down as each of them tries to grab hold of the ball.
In talks about the origins of the Scrum framework, its creators Jeff Sutherland and Ken Schwaber often like to say that Takeuchi and Nonaka’s “The New New Product Development Game” is one of the foundational pieces of research that informed the way Scrum works.
Why Does Scrum Work?
In the early days of Scrum, the framework’s founders Jeff Sutherland and Ken Schwaber collaborated with process control scientists at DuPont, one of the leading chemical companies in the world, to determine what made the framework work so well when compared to the traditional software development practices most companies used at the time.
In the 20th century, DuPont experienced a number of explosions in its plants worldwide. After the Bhopal disaster, a gas leak that killed several thousand workers and exposed 500,000 residents of the city of Bhopal in India to methyl isocyanate gas, DuPont decided to hire some of the world’s best scientists to prevent explosions of this magnitude from happening in any of their production plants ever again.
The reason why Scrum worked so well, Schwaber found out, was in one of the first principles of industrial process control theory. According to industrial process control theory, there were generally two types of processes: predictive processes and empirical processes.
- Predictive processes were complicated, but could be run as an assembly line. Every step of the process had a highly predictable outcome with little deviation. Predictive processes could be run with a predictive control system where every step, its inputs, and its outputs, could be planned in a linear and sequential way.
- Empirical processes were complex and their outcomes were difficult to predict. These processes, like mixing chemicals in a vat and exposing them to high temperatures to trigger chemical reactions, required close monitoring and continuous adjustment. Empiric processes had less predictable outcomes with high deviation. They required a different, empirical control system.
“In every case of an exploding chemical plant,” Scrum co-founder Jeff Sutherland recalls his and Schwaber’s learnings, the process control scientists had found “that somebody had applied a predictive control system to an empirical process.”
From the lens of industrial process control theory, software development was an empirical process. Research has shown that as many as 65% to 70% of a software development project’s original requirements would change throughout the course of the project.
Software development is an empirical process. The vision, mission, goals, and objectives can be known from the beginning, but the implementation approach and final outcomes that deliver on them are, for the majority of software products, not.
Which is why software development requires an empirical process control system. One that allows the team building the product to continuously monitor the state of their product, learning valuable lessons and adjusting their plans along the way.
Which Projects Is Scrum Suitable For?
First and foremost, Scrum works best if your organization (or business unit, or department, or team) has already adopted an agile mindset.
At least to the extent that it allows a small team of 10 people or less to self-organize and determine their own scope of work (and approach to getting that work done) based on a vision, mission, and goals aligned with the rest of the organization.
Second, in the long term Scrum only tends to work out in organizations whose leaders, sponsors, and managers actually participate in the Sprint Reviews.
It’s a simple ask: book up to 4 hours of your time every 1, 2, 3, or 4 weeks to see how the product that this Scrum Team is building is taking shape. Have a conversation with them about the lessons that they’ve learnt and the challenges that they’re having.
Scrum necessitates stakeholder participation. Unfortunately, in many companies this is too much to ask for—even if it is completely in the interest of the people sponsoring and supporting the team to participate in their rituals and give their feedback on the events where they are expected to.
Third, Scrum is not something that comes intuitively to anyone who needs to practice it. They need to build an understanding of the framework’s mechanics.
This is best done through training and certification. Below in this blog post, I’ve shared what I consider to be the best training courses and most recognized certificates for practitioners of the Scrum framework.
If you want a team to get started well in Scrum, help them get the training they need in case they don’t have much (or any) experience with the framework. That includes the Scrum Master, the Product Owner, and the Developers. If you want an experienced team to excel in Scrum, help them get coaching from some of the best Agile Coaches in your field of work.
Finally, Scrum is for initiatives, programs, projects, products, services, or problems where the vision, mission, goals, and/or objectives are clear—but how to achieve them is not.
The Scrum framework allows a team of capable and empowered individuals to self-organize and solve complex problems in an iterative and incremental way. In doing so, they welcome change and continuously improve their ways of working.
If this is not what your program or project needs, reconsider whether you truly should use Scrum.
Which Scrum Certification Should I Get?
The Scrum framework is taught by Scrum Alliance (scrumalliance.org), Scrum.org (scrum.org), and Scrum Inc. (scruminc.com).
Scrum Alliance was founded in 2001 by Ken Schwaber and Mike Cohn. Scrum Inc. was founded by Jeff Sutherland in 1995. Scrum.org was founded by Ken Schwaber in 2009.
Each of the three organizations were founded by the creators of Scrum and offer the best training courses and certification for practitioners of the framework. Of the three, Scrum Alliance is the most widely recognized by hiring managers and industry professionals in the world.
Which course should I take if I’m just getting started? If you’re just getting started with agile, you probably want to get the basics of Scrum right and get a certificate to put on your CV that gets you hired. For that, I recommend taking a CSM, CSPO, or CSD course (details below) from an instructor licensed with Scrum Alliance.
Which course should I take if I’m experienced with Scrum? If you’re experienced with Scrum and looking for answers to a specific challenge, I recommend taking one of the courses from Scrum.org or Scrum Inc. UX/UI professionals should consider the dedicated PSU training by Scrum.org. Leaders looking to scale agile and Scrum in their organizations should consider Scrum Inc.’s Certified Scrum@Scale Practitioner training.
Perhaps the best training on agile leadership is with Scrum Alliance’s CAL track. Coaches should consider the Scrum Inc. Licensed Agile Coach training as Scrum Inc. has built an impressive amount of case studies for Scrum and Scrum@Scale its trainers pull from.
Scrum Alliance Certification
The Scrum Alliance offers 5 certification tracks:
- For Scrum Masters
- Certified ScrumMaster (CSM)
- Advanced Certified Scrum Master (A-CSM)
- Certified Scrum Professional – Scrum Master (CSP-SM)
- For Product Owners
- Certified Scrum Product Owner (CSPO)
- Advanced Certified Scrum Product Owner (A-CSPO)
- Certified Scrum Professional – Product Owner (CSP-PO)
- For Developers
- Certified Scrum Developer (CSD)
- Certified Scrum Professional (CSP)
- For Leaders
- Certified Agile Leadership Essentials (CAL-E)
- Certified Agile Leadership for Teams (CAL-T)
- Certified Agile Leadership for Organizations (CAL-O)
- Certified Agile Leadership I (CAL-I)
- Certified Agile Leadership II (CAL-II)
- For Coaches and Trainers
- Certified Team Coach (CTC)
- Certified Enterprise Coach (CEC)
- Certified Scrum Trainer (CST)
For details, go to Scrum Alliance’s website at scrumalliance.org.
Scrum.org Certification
Scrum.org offers five training and certification tracks:
- Professional Scrum Master (PSM)
- Professional Scrum Product Owner (PSPO)
- Professional Scrum Developer (PSD)
- Professional Scrum with User Experience (PSU)
- Scaled Professional Scrum (SPS)
- Professional Scrum with Kanban (PSK)
- Professional Agile Leadership (PAL)
For details, go to Scrum.org’s website at scrum.org.
Scrum Inc. Training and Certification
Scrum Inc. offers five certification tracks:
- Scrum Inc. Scrum Master
- Scrum Inc. Product Owner
- Certified Scrum@Scale Practitioner
- Scrum Inc. Licensed Agile Coach
For details, go to Scrum Inc.’s website at scriminc.com.
The Bottom Line
Scrum is a lightweight framework that organizations—large and small, across any sector or geography—can use to build complex products and solve multi-faceted problems.
In Scrum, a small and self-organized team of 10 people or less communicates and collaborates using the Scrum roles, events, and artifacts, to build a product.
Scrum Teams adopt an empiric and lean way of thinking, and an agile way of doing. They work in short cycles called “sprints” and ship products in small chunks called “increments.”
Doing so allows them to stay flexible, welcome change, learn lessons, and adjust their plans. Simply said, Scrum is a framework that a team can use to become highly adaptable and responsive.
Learn it, try it, use it, master it. Scrum is the result of much research and experimentation in the 1990s. Since it gained traction with the rise of the agile movement in the early 2000s, it’s become the world’s leading product development framework.
