Scrum is an Agile framework for developing new products and extending existing ones. Scrum is one of the most common frameworks implemented in Agile. It has been around since the mid 1990s, and provides a repeatable, consistent, and effective set of events to help development teams build products.
Scrum is not by itself a technique to build products, rather it provides the framework to enable teams to collaborate and follow a set of rules. Teams can then employ the specific techniques most suitable to designing and developing their products.
Scrum enables teams to build products using an iterative and adaptive process, therefore reducing risk and improving the outcome. It reduces the cost of changing and adapting the plan to varying requirements or customer needs, and therefore reduces the overall risk of the project. Work is usually done in multiple iterations of the same duration. During each iteration, the team builds a piece of the product, tests it, and collects feedback from customers and stakeholders. The team then prepares to work on the next iteration and repeats the process until the full product is completed. Because Scrum offers multiple opportunities for inspecting the work and collecting feedback, it allows teams to validate their product along the way, or quickly change course if needed.
Download the pdf with the Scrum workflow
The Scrum workflow
Scrum is an iterative framework composed of a series of events and artifacts. Teams iterate through each cycle following a well-defined schedule of events. At the end of each iteration, the cycle starts all over again. Each cycle is timeboxed and always has the same duration. One cycle of the process is called a Sprint.
The Sprint, in Scrum, is equivalent to one cycle through the full Scrum process. A Sprint is always timeboxed, i.e. its duration is predefined and always the same. Sprints usually last between one week and one month, and the most common duration is two weeks.
Sprints enable rapid iterations and incremental delivery of value:
A Product Owner orders the work for a complex problem into a Product Backlog.
The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
Repeat
Scrum Guide, 2020
At the beginning of each Sprint, the Product Owner selects a list of items from the Product Backlog based on priority, and presents them to the rest of the team during the Sprint Planning meeting. At the end of this meeting the team produces the Sprint Backlog, a list of all work the Developers commit to for the Sprint. The work can then begin.
For the duration of the Sprint the team focuses on delivering the work it has committed to. Every day, it spends a short amount of time (15 minutes) on the Daily Scrum meeting (also called Daily Stand-up). This is an opportunity for each Developer to share what they are working on, update their plan towards the Sprint Goal, and identify any impediments to completing the work.
At the end of the Sprint, the team delivers the Product Increment, the result of the work performed. This is then presented to the stakeholders and customers at the Sprint Review meeting, and they provide validation and feedback to help the team adjust their plan for the next iterations.
As a final step in the Scrum iteration, the team meets for a Retrospective meeting, where the Scrum team reviews how it performed the work and uncovers opportunities for improvement. This enables the Scrum process to adapt and self-correct.
The Sprint then ends and the team gets ready to start a new Sprint. Any work that is not completed in the Sprint, or any new work that is created as a result of feedback from the Sprint Review meeting, goes back into the Product Backlog. The Product Owner then reviews all the items and updates the priorities, before a new Sprint can start.
Three pillars of empiricism
Scrum upholds the three fundamental pillars of empiricism: transparency, inspection, and adaptation.
Transparency
Scrum provides multiple opportunities for the team and its stakeholders to come together, inspect, and validate the work being done. Because the work does not happen in a black box, everyone can see what the team is doing and what to expect.
The Product Backlog is a living document that the Product Owner shares with the rest of the team and their stakeholders. Because the Backlog is visible and shared among team members and stakeholders, everyone knows what the team is working on and what’s coming next. The work that the team commits to is not dictated by the Product Owner, but is negotiated with the team members. User Stories are not hard-written requirements, but rather placeholders for conversations. The team self-organizes to find the best ways to do the work and deliver the expected results.
The Sprint Review is a key moment in the Sprint timeline wherein the team has the opportunity to share the work done with stakeholders and customers, and collect their feedback. Customers and stakeholders gain visibility into the work, and the team can adjust the plan if needed.
Transparency enables stronger collaboration, promotes trust among everyone involved, and reduces the risks of rework.
Inspection
Scrum provides multiple opportunities for inspecting both the work product and the process that the team adopts to create it. Stakeholders and customers have opportunities to participate in the development process at regular intervals and to provide feedback on the work being done. The Product Owner reviews and accepts the work as the Developers complete it. And the team reviews its processes and finds ways to better work together.
By inspecting the work being done, the team creates an environment that fosters transparency and adaptation to changing conditions.
Adaptation
Adaptation is the ability to change course when conditions are different than anticipated. This is a cornerstone of any Agile method, and is unquestionably fostered with Scrum. Work happens in relatively short intervals (one week to one month) that allow for frequent reviews and feedback from stakeholders and customers. This allows the Scrum team to quickly correct course if needed, before building something too big to pivot.
But adaptation is not only related to the work being done. In fact, Scrum allows for auto-correction of the process itself. If the Scrum team determines that one or more elements of their work process is not satisfactory, it can discuss and review options for improvement. Scrum assumes continuous evolution of processes, work agreements among team members, and supporting systems.
For example, if at some point conditions have changed and the team’s “definition of done” is no longer acceptable, they can amend it. Nothing is static. Scrum is considered a framework, as the actual processes and tools used are in continuous evolution.
The five Scrum events
Want to learn more about the 5 Scrum events?
Read our guide to the five Scrum events with tips on how to make them effective.
Scrum guide
For a quick reference to Scrum, you can download the Scrum Guide from Jeff Sutherland and Ken Schwaber. Jeff and Ken invented Scrum in the mid-1990s.
Interested in what has changed in the 2020 release of the Scrum Guide? Read our analysis here.
If you are interested in a training class for Scrum and Agile, check out our training page or contact us for a custom program.
Scrum workflow diagram and exercise
You can download a pdf with the full diagram of the Scrum workflow to use as reference or as a poster in your workspace.
The pdf includes an exercise that you can run with your team to get everyone aligned on common terms and definitions of the Scrum workflow.
This is a fun way to learn the Scrum workflow and you can do it with your team or with a class of students.
Scrum test
Test your Scrum knowledge with our Scrum test and see how well you know Scrum. If you need help to learn more about Scrum and get the experience needed to pass the exam, check out our training page with a list of upcoming CSM training classes.
