Agile Scrum: What Scrum Is and How it Works

If you’ve heard of Agile project management, you’re likely familiar with Scrum, the best-known Agile framework.

“It’s the one we most often use if we’re going to have a team do an Agile implementation,” says Erin Randall, principal coach and founder at Ad Meliora Coaching, and a certified Scrum master and professional. “We’ll bring Scrum in first because it has a bit more rigor to it.”

Scrum is far and away the most-used Agile implementation tool, according to the 2020 State of Agile Report. About three-quarters of respondents surveyed said they use Scrum or a hybrid of Scrum and another method, such as Kanban.

“It helps that Scrum is easier to understand than other Agile methods,” says Anthony Mersino, founder of Agile and Scrum training and coaching firm Vitality Chicago, and faculty director for the Agile Graduate Certificate Program at Northwestern University.

Agile project management is an approach that features constant team collaboration, adaption to change and iterative work. It’s an alternative to the rigid planning, documentation and implementation process of the traditional Waterfall project management.

Software development companies began working on projects in the Agile mindset in the mid-1990s. The process was established in 2001 with the Agile Manifesto, which outlined a way to innovate software.

Soon after, the 12 principles provided specifics on how projects should be run. For example, Agile projects should feature self-organizing teams that collaborate with the customer and each other, welcome changes, and plan for repetitive product development.

Agile focuses on the customer’s needs and is adaptable, which is important when the team has to create something that didn’t exist before.

“It’s about being able to change quickly and at a low cost,” Mersino says.

Agile serves as an umbrella for many types of implementation, of which Scrum is one, Randall says. Others include Kanban, extreme programming and DevOps.

You might find, for example, that Scrum is not the best Agile implementation tool for your organization and project. Kanban is similar to Scrum, but it is more focused on visualizing the work and encouraging a continuous flow. Some prefer to use a hybrid of Scrum and Kanban (known as ScrumBan), a Scrum extreme programming combination, or other methodologies or hybrids.

Scrum grew out of software development project management because of the need to create products that haven’t been developed before, deal with a change during projects and benefit from collaboration during the process.

The three pillars of Scrum are:

Mersino, who spent many years as a traditional IT product and program manager, said the small, collaborative, self-organizing teams in Scrum are preferable to the traditional project management model where one person calls the shots. The traditional model is ideal for more predictable projects, but, “traditionally, IT projects have not been predictable at all,” he says.

Product development team members enjoy the camaraderie of Scrum, while managers appreciate the transparency, Mersino says.

The Scrum values – commitment, courage, focus, openness and respect – reflect the dedication that teams need for a project to be successful. During Scrum, team members commit to a specific accomplishment during a designated time period, are open about whether it’s working or not, and discuss and solve issues that might impede their progress.

“It takes a lot of courage to work together like this,” Randall says. Team members have to be willing to try new things.

Scrum principles are used outside of the software industry, including in human resources, marketing firms and departments, law firms, construction, transportation, and manufacturing.

The rules of Scrum are easy to understand, which makes the transition from traditional project management easier, Mersino says.

“Part of it is the simplicity. Another part of it is the idea of having a sprint and delivering something at the end of a sprint, which is really appealing to team members, businesses, stakeholders and leadership,” Mersino says.

Rather than waiting six to 12 months for a Waterfall project to finish, in Scrum, “every two weeks you’re building something, you can show it and may be able to implement it in production. It’s very motivating if you’re on a team,” he says.

There are many ways you can start the Scrum process, depending on how much experience your team and organization have.

First, assemble a cross-functional development team with key roles such as product owner. Then define the top stakeholders, which include users and internal and external customers.

“Stakeholders are people who have a stake in what the team does,” Mersino says. “It could be management, customers or customer representatives.” Anyone affected by the solution could be a stakeholder, and “some have a bigger voice than others,” he says.

Internal stakeholders could include a product or executive manager. Some Scrum projects – such as a reorganization plan or a process to create a product like a company newsletter – are entirely internal.

External stakeholders might be a company that is paying for the development of the product. Users could also be stakeholders, whether it’s someone inside or outside of the company who needs to test the product.

During initial meetings, sometimes called “sprint zero,” you make decisions about the product vision and the process.

For example, you can determine sprint length. They usually last two weeks to a month, and the team figures out the length of time that’s best as you divide the project into pieces. You can also put together an initial product backlog, which is the list of project tasks to be completed.

Throughout the process, you can reinforce Scrum pillars as teams ensure transparency, have frequent inspections and make changes based on feedback from stakeholders.

The Scrum team – which is the group that plans and executes the project – includes the development team, product owner and Scrum master.

The development team members cover a variety of specialties within an organization and are accountable for the work in each sprint. Teams can include up to nine members, though Mersino says it’s often around seven per team.

In a traditional project, the project manager plans and assigns all aspects and is ultimately responsible. A Scrum master focuses on being of service to the development team, Randall says. This sort of servant leadership role requires strong persuasion, coaching and facilitation skills, which is why there are a variety of Scrum master certifications.

The product owner is in close contact with the customer and knows what they need from the project. The product owner will define the project, help develop and update the product backlog, and work with the development team to determine the most important tasks for each sprint.

All three parts of the Scrum team interact frequently. The Scrum master usually takes part in key meetings – known as Scrum ceremonies – with the development team, and the product owner will participate in some as well. The Scrum master works with the development team to make sure their goals are met for each sprint, and the product owner looks at the team’s work through the eyes of the customer.

If a company wanted to use traditional project management to create a new software product with 100 features, it would follow a rigid process, and the product could face delays because of issues discovered in late-stage testing, Mersino says.

With Scrum, the product owner can help the development team prioritize the most important features. “Maybe we’re doing 10 of those items per sprint and taking them all the way to ‘done,’” Mersino says. Even if there are problems with creating 20 of the 100 features during the process, you could have a product ready to launch with 80 of the most important features, he says.

During the Scrum process, the team relies on planning tools, or Scrum artifacts, to keep track of tasks and their progress:

Product backlog. This is the list of what needs to be completed in the project, usually in prioritized order. The work is often organized in epics, or larger pieces of work, which are then broken down into user stories, which simply describe the desired outcome for an end user. These smaller tasks, such as creating a specific feature in a software product, could be completed during a sprint. The product owner will work with the customer to complete this list.

“It’s simply a list of things that are desired – either features or functions or needs or customer requests,” Mersino says.

Sprint backlog. Each sprint will have a list that describes and prioritizes what the development team will work on during that time period. The development team looks at the product backlog and decides “what can we commit to doing in this two-week chunk,” Randall says.

Product increment. At the end of each sprint, the team is expected to produce something that meets the agreed-upon definition of done. It could be a software feature that is ready to be demonstrated to the customer.

Definition of done. This is a “standard that the team adheres to, an agreement between the customer and in some cases organization, so they don’t move something to done that’s not really done,” Mersino says. Once this is defined, “there is clarity around it,” he adds. “It’s either done or not done. There’s no gray area.”

The Scrum process relies on defined interactions that will ensure the work is efficient and effective while upholding the pillars of Scrum.

There are four main meeting points, called ceremonies – sprint planning, daily Scrum, sprint review and sprint retrospective:

Sprint planning. The length of each sprint is usually determined at the beginning of the project and remains consistent. Although the entire team is usually in this meeting, it’s up to the development team to figure out how much can be accomplished in each sprint.

“Say you have two weeks,” Mersino says. The team will determine “how many things can we take on and get all the way to done in two weeks,” while also taking into account the skill set of the team, vacations, time off and other considerations. You can’t plan beyond one sprint, he adds.

Daily Scrum. Also called a daily stand-up meeting, this usually lasts no more than 15 minutes. The focus is on development team members “coordinating with each other and making sure they’re on track to achieve the goals of the sprint,” Mersino says. The Scrum master’s role is to help development team members deal with blocks that prevent them from reaching their goals, Randall says. These impediments could include designs or equipment delays or issues with stakeholders.

Sprint review. The team reviews the product or products it created during the sprint, and could invite everyone – including stakeholders – to the discussion. “The more the merrier,” Mersino says. “You’re trying to get feedback and make sure you’re on the right track.”

Sprint retrospective. This is likely a private meeting for the development team to discuss how well the process went during the sprint and what they need to adjust for future ones. “We want that to be a safe place for that team” to discuss what worked and didn’t work, Randall says.

As a project manager, you might have two key decisions to make – whether to use Agile or Waterfall project management, and if you use Agile, which type of implementation tool is the best fit for your project and organization.

If you have an ongoing task that follows a predictable process – such as a server upgrade project that is completed using the same routine every six months – you might want to stick to traditional project management, Mersino says.

But the appeal of Agile in general – and Scrum in particular – is you can split the project into smaller bites, have more realistic expectations of what can be accomplished and demonstrate your progress to stakeholders at the end of every sprint, Randall says.

“We collaborate so much more with people we serve rather than just delivering something at the very end,” Randall says. “We respond to change rather than dictating what’s coming.”

The structure of Scrum is ideal for many projects and teams. For example, Scrum can help you see the skill and knowledge gaps your team members might have, Mersino says. “You can coach or train them on how to remediate this,” he says.

Also, you can anticipate and address situations that can delay project completion. For example, if legal review is a problem, you can bring on a legal representative or train team members to understand the legal requirements, he adds.

Some organizations might choose Kanban – which allows them to visualize the work through a Kanban board – over Scrum. Randall says she has worked with some experienced development teams that prefer Kanban because the workflow is more fluid.

Scrum can have some drawbacks, especially if it’s not used correctly. There might be issues if you:

Mersino says a common issue is when organizations claim that their project is following Scrum guidelines but are actually using the traditional method.

“That’s the most common abuse that is happening out there,” he says. “People get turned off by Agile and Scrum because of it.”

Here are places to get more information about Scrum.