Scrum is a lightweight framework for managing complex work, most commonly used in software development but applicable to any project that benefits from iterative progress. Rather than planning everything upfront and executing a rigid plan, Scrum organizes work into short cycles called Sprints, letting teams deliver small pieces of a product, gather feedback, and adjust course along the way. It’s built on a simple idea: you can’t predict everything at the start, so you’re better off learning as you go.
How Scrum Actually Works
Scrum is rooted in what’s called empirical process control, which just means making decisions based on what you observe rather than what you predicted months ago. Three pillars support this approach. Transparency means everyone involved can see the current state of the work and the product. Inspection means the team regularly examines what they’ve built and how they’re building it. Adaptation means when something isn’t working, the team changes course quickly rather than sticking to an outdated plan.
In practice, a Scrum team works in Sprints, which are fixed time periods of one month or less (two weeks is the most common choice). Each Sprint produces a usable piece of the product. At the end, the team shows what they built, gets feedback, reflects on how the Sprint went, and plans the next one. This cycle repeats until the product is complete or the project wraps up.
The Three Roles on a Scrum Team
A Scrum team is intentionally small, typically ten or fewer people, with three distinct roles. There are no project managers, no team leads, no hierarchy beyond these three.
Product Owner
The Product Owner decides what the team should build and in what order. They own the product backlog, which is the prioritized list of everything the product needs. Their job is to maximize the value the product creates for users and the business. That means setting product goals, collecting feedback from customers and stakeholders, ordering backlog items by priority, and knowing when to say no to requests that don’t serve the product’s direction. The Product Owner has the final word on what goes into the product, but they don’t tell the team how to build it.
Developers
Developers are the people who do the work of building the product. In software teams this usually means programmers, designers, and testers, but in other industries it could be anyone doing hands-on creation. Developers decide how to accomplish the work the Product Owner has prioritized. They manage their own Sprint backlog (the subset of work they’ve committed to for the current Sprint), check in with each other daily, and are collectively responsible for delivering a quality increment at the end of each Sprint.
Scrum Master
The Scrum Master is responsible for making sure the team follows the Scrum framework effectively. They’re part coach, part facilitator, part obstacle remover. Day to day, a Scrum Master facilitates meetings, helps the team understand backlog items, coaches the Product Owner on how to organize the backlog for maximum value, and clears roadblocks that slow the team down. In organizations still getting used to Scrum, the Scrum Master also helps the broader company understand how to work with a Scrum team without undermining the process.
The Five Scrum Events
Scrum defines five formal events, each with a maximum time limit (called a timebox) to keep things focused. For a one-month Sprint, the timeboxes are at their maximum. Most teams running two-week Sprints cut these roughly in half.
The Sprint
The Sprint is the container for all other events. It lasts one month or less and produces a usable product increment. Once a Sprint starts, its length doesn’t change, and no changes are made that would put the Sprint goal at risk. When one Sprint ends, the next one starts immediately.
Sprint Planning
At the start of each Sprint, the team meets for up to eight hours (for a one-month Sprint) to answer three questions: Why is this Sprint valuable? What can we deliver? How will we get the work done? The outcome is a Sprint goal and a Sprint backlog of items the team commits to completing.
Daily Scrum
Every day during the Sprint, the Developers hold a 15-minute meeting to inspect their progress toward the Sprint goal and adjust their plan for the day. This isn’t a status report to a manager. It’s a coordination meeting where team members sync up, flag blockers, and decide what to tackle next.
Sprint Review
At the end of the Sprint, the team presents what they built to stakeholders in a meeting lasting up to four hours. This isn’t a slide deck presentation. The team demonstrates the actual working product, collects feedback, and discusses what to work on next. The Product Owner uses this feedback to refine the product backlog.
Sprint Retrospective
After the Sprint Review, the team spends up to three hours reflecting on how the Sprint went from a process standpoint. What worked well? What didn’t? What should change? The Retrospective is where the team identifies concrete improvements to carry into the next Sprint. This is the adaptation pillar in action.
Artifacts: What the Team Tracks
Scrum uses three artifacts to keep work visible and organized. Each artifact has a commitment tied to it, giving the team a clear target to measure progress against.
The Product Backlog is the master list of everything the product could eventually include, ordered by priority. Its commitment is the Product Goal, a long-term objective that describes the future state of the product. The Product Owner continuously refines this list as the team learns more.
The Sprint Backlog is the set of items the team pulls from the Product Backlog for the current Sprint, plus a plan for delivering them. Its commitment is the Sprint Goal, a single objective that gives the Sprint coherence and purpose.
The Increment is the sum of all completed backlog items at the end of a Sprint. Its commitment is the Definition of Done, a shared standard that spells out exactly what “finished” means. If a backlog item doesn’t meet the Definition of Done, it doesn’t get released or presented at the Sprint Review.
The Five Values Behind the Framework
Scrum also defines five values that shape how team members are expected to work together: commitment, focus, openness, respect, and courage. These aren’t just motivational posters. Commitment means the team follows through on its Sprint goals and supports each other. Focus means prioritizing Sprint work over distractions. Openness means being transparent about progress and problems. Respect means trusting teammates as capable professionals. Courage means raising uncomfortable truths, pushing back on unreasonable requests, and tackling hard problems head-on.
Teams that ignore these values while following the ceremonies tend to end up doing “Scrum in name only,” going through the motions of standups and Sprint Reviews without getting the benefits of the framework.
Where Scrum Is Used
Scrum originated in software development in the 1990s and remains most popular there, but it has spread well beyond tech. Marketing teams use it to manage campaigns. Hardware teams use it to develop physical products. HR departments have adopted it for organizational change initiatives. The framework works best when the work is complex, requirements are likely to change, and the team benefits from frequent feedback loops. It’s less suited for routine, highly predictable work where a simple checklist would suffice.
Getting Certified in Scrum
Two organizations dominate Scrum certification. Scrum Alliance offers the Certified ScrumMaster (CSM), which requires completing a training course (typically two days) and passing a 50-question multiple-choice exam with a score of at least 37 out of 50. Course prices range from $250 to $2,495, depending on the instructor, location, and format. The certification must be renewed every two years by earning Scrum Education Units through activities like attending events, reading books, or watching webinars.
Scrum.org offers the Professional Scrum Master (PSM) certification, which does not require a course and can be attempted by anyone willing to pay the exam fee. Many people study independently using the Scrum Guide, a free document that serves as the official definition of the framework, and then sit for the exam when they feel ready.
Neither certification is legally required to work as a Scrum Master or on a Scrum team, but many employers list one or both as preferred qualifications. For people early in their careers, a certification signals familiarity with the framework. For experienced practitioners, it tends to matter less than a track record of running Scrum teams effectively.