The Complete Guide to Scrum

What is Scrum?

Even if you have never heard a thing about it, by the end of our definitive guide, you’ll know everything you need to know about the what, how, and why of this powerful agile methodology.

Let’s dive in.

What does Scrum mean?

The term “Scrum” comes from rugby. It was first used in the context of product development in a 1986 paper published in the Harvard Business Review titled “The New New Product Development Game.”

The authors, Hirotaka Takeuchi and Ikujiro Nonaka, saw that traditional frameworks for project management no longer suited the fast pace of development. “What we need today,” they concluded, “is constant innovation in a world of constant change.”

They described how massive companies like Honda and IBM were finding success by letting small groups of autonomous teams take on projects without rigorous oversight. They likened this “holistic method” to a Scrum in rugby, where “the ball gets passed within the team as it moves as a unit up the field.”

A lot has changed since then. But the world has only become more fast-paced and hyper-competitive. And Takeuchi and Nonaka’s model of small, autonomous teams that deliver complete products is still at the heart of Scrum as it’s practiced today.

How does Scrum work?

Scrum is a process framework that uses small teams to build products that continuously improve. Like Kanban, XP, and other agile methodologies, Scrum employs lightweight, iterative, and integrated development.

It’s a mindset and approach rather than a specific technique. In other words, Scrum lays out a set of working relationships that help people collaboratively manage complex projects. These Scrum relationships are broken down into artifacts, ceremonies, and roles.

Instead of hierarchy, Scrum promotes self-organization. It leaves the teams to own the execution of their own work. This is why it’s so important for Scrum team interactions to be grounded in the three pillars of transparency, inspection, and adaptation:

• Transparency: Significant aspects of the project must be visible to those responsible for outcomes. Good Scrum teams share information constantly.
• Inspection: Every Scrum event is an opportunity to analyze progress and processes for potential problems and improvements.
• Adaptation: Adjustments are made accordingly.  

All of this might seem a bit sterile, but during meetings, the question of progress can get personal. It’s easy to let emotions and disagreements cloud your ability to inspect and adapt. Great teams use the five Scrum values—commitment, courage, focus, openness, and respect—to build the strong relationships they need to enable open communication.

Scrum team roles

The Scrum team is made up of the product owner, the Scrum master and the development team. Scrum teams are:

• Self-organizing: Individuals decide how to accomplish their work, as opposed to getting instruction from above.
• Cross-functional: The Scrum team is made up of all the skills and capabilities needed to complete the work.

Think back to Takeuchi and Nonaka’s rugby metaphor and how Scrum teams pass the ball within the team as they move up the field. That means they shouldn’t need to ask anyone outside the team for direction or support to deliver a useful product increment.

What it doesn’t mean, of course, is that the Scrum team is completely cut off from the company.

For example, the product owner is responsible for interfacing with stakeholders outside the team to figure out what the team should work on. They are the best-positioned to know which features and fixes will add the most value.

The development team is responsible for completing the product increment. Developers work with the product owner to make sure they are choosing product increments that will add value, but they alone decide how to get it done.

The Scrum master facilitates Scrum events and makes sure the development team is clear of blocks and distractions. Scrum masters help the team improve their processes and are responsible for communicating the results to outside stakeholders.

Here’s a simple way to think about the roles and responsibilities of the Scrum team:

Scrum teams work in short time-boxed periods known as sprints (typically two to four weeks) to create product increments that are potentially releasable.

So, the average Scrum team has 10 workdays to select, complete, and integrate a product increment. To maintain this fast pace, they use the Scrum artifacts mentioned above to track the sprint input (what to work on) and output (what gets done).

Side note: Keeping the team on track also means using the right Scrum software.

Let’s go over those artifacts in more detail.

Scrum artifacts

The first is the product backlog: a list of all desired features, fixes, and maintenance that the team could work on. Because sprints are short, Scrum teams can only work on a few items from the product backlog at any time.

The product owner is responsible for prioritizing the product backlog so that the team is choosing from the highest-priority or valuable backlog items. Together with the development team, the product owner regularly refines the backlog (also known as backlog grooming) to keep it up to date.

At the beginning of the sprint, the development team chooses the backlog items that will become the sprint backlog, then plans how to get this work done by breaking each item down into tasks.

By the end of the sprint, the team should have completed the sprint backlog items. This constitutes the product increment. Product increments are supposed to be useable, additive (building on previous iterations of the product), and potentially releasable. They are fully integrated and meet the definition of “done” as determined by the team.

Now that you know the Scrum artifacts and roles, it’s time to take a closer look at the sprint.

Tip: Looking for a way to keep your team on the same page? Scrum boards are designed to provide a real-time visual snapshot of the sprint ahead.

Scrum ceremonies

There are four formal Scrum ceremonies that break down the work of the sprint. Regardless of its length, these events provide the sprint’s basic structure and important moments for the team to inspect and adapt its processes.

The sprint begins with sprint planning, when the entire team comes together to choose items from the prioritized product backlog to work on that they can reasonably expect to finish. No two backlog items are the same, so the product owner works with the development team to understand each item’s “size” and the team’s capacity to avoid overloading them.

Now for the development team to break items down into tasks. Usually it’s enough to decompose just the first few days’ worth of work by the end of sprint planning.

To inspect the sprint as it progresses, the team meets for 15 minutes at the beginning of each day. This Scrum ceremony is known as daily Scrum, when the development team comes up with a plan for the day ahead. The goal is to cover:

• What each person has done in the last 24 hours
• What they plan to do in the next 24 hours
• Any issues or concerns they have about completing the sprint backlog

This routine ceremony helps team members with different skill-sets coordinate their work. It brings dependencies to light and regularly checks in to see that the team is still working toward an integrated, functioning product increment. (Although there are edge-case reasons for skipping, most teams hold daily Scrum every day.)

And transparency is key. While the development team leads daily Scrum, the Scrum master helps keep that communication open and focused. It’s up to them to make sure that only the development team participates and is comfortable sharing problems.

Tip: Scrum masters need to have certain soft skills to promote healthy team interaction. Here are the Scrum master interview questions you need to ask to find the right candidate.

At the end of the sprint, the team inspects the product increment during sprint review. They might feel free to invite stakeholders from outside the team—at the product owner’s discretion. This is the time to present the product and discuss the work of the sprint: has the “done” product increment delivered the expected value? Did backlog items fit true to expected size?

Based on this knowledge, the Scrum team adapts the product backlog and talks about what to do next. This generates feedback and ideas that are useful for the final Scrum ceremony: the sprint retrospective.

Held after sprint review but before the team begins the next sprint, this ceremony is prime time for the team to inspect and adapt their processes. The retrospective agenda is distinct from that of the sprint review in that the team is focusing on itself, not the product.

A successful retrospective helps the Scrum team identify and implement new and improved ways to work. It’s about about what went well, what caused problems, and the team’s relationships, processes, and tools. What of these can be done differently to make the next sprint more productive and fun?

Here’s where the Scrum master’s soft skills and creative ideas for retrospective exercises shine through. It’s their job as facilitator to keep finger-pointing to a minimum and brainstorming as open and engaging as possible.

The end goal of the retrospective is for the Scrum team to negotiate several concrete improvements they can carry forward into the next sprint. Retrospective tools can help track commitments and feedback.

Tip: Running your first retrospective? Here’s an example agenda you can copy from one of our most productive retros at FYI.

Professional development for Scrum

So, you’ve got the basic concepts of Scrum. Putting them into practice is much more difficult. And folks with the expertise to help companies transition seamlessly to Scrum are in high demand.

One of the most straightforward ways to demonstrate your experience? Through a Scrum master certification. Choosing the right one for you might depend on your personal goals or a prospective employer’s requirements.

Scrum training courses are another good option for people looking to learn more. Some are geared toward total beginners; others for advanced practitioners looking to enhance their knowledge in a particular domain.

There are also a ton of great Scrum books out there. (And not-so-great ones you can avoid by skipping right to this list of the nine books every Scrum master should read.)

Tip: Interested in learning more about scaling Scrum, specifically? Check out my post on how to run Scrum of Scrums to coordinate multiple teams.

Final thought: Scrum is about…

…making work more enjoyable.

At its core, Scrum is about making sure teams are working together on valuable projects in a sustainable way. Burnout is real. And over the long term, it’s guaranteed to sap motivation and productivity.

It’s no accident that whenever I talk about Scrum with someone who has really made it work for their company, the words “fun,” “exciting,” and “proud” come up a lot. The rest should fall into place.