What is Scrum? Why Do You Need It?

My conversation with Dominika started with the fundamental question: when we say “Scrum,” what do we mean by that? Her answer matched almost exactly the definition provided in the official Scrum Guide:

“Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.”

Oh, and Scrum is also a rugby term, meaning a “restarting of play after a minor infringement” (or so says Wikipedia, because I don’t know a thing about rugby). That’s where it got its name, actually.

But really, Scrum results from an evolutionary process to make work on complex products faster and better. It’s a set of guidelines for roles and events used by development teams around the world.

But really really, Scrum is an answer to a software development model called Waterfall. In Waterfall, all the features of the ordered product are delivered at once, as a complete package. You may design and order a piece of software, let the developers do their work, and then receive the finished product a year later.

I’m sure you can see the potential problems with Waterfall. It sounds convenient at first and is a better choice sometimes. But a lot can change during a year. What if the finished product no longer fits your vision? What if it’s no longer viable on the market?

Clearly, with complex and ever-evolving products, another approach is needed. Something more Agile.

Scrum is a key component of agile software development, emphasizing iterative and incremental progress to adapt to changing project needs.

What Is a Scrum Framework?

The Scrum framework is a lightweight yet powerful approach to managing complex projects. It relies on cross-functional and self-managing teams to deliver products and services in short cycles. The Scrum framework consists of three core components: accountabilities, artifacts, and events. These components work together to create a cycle of continuous improvement and adaptation.

At its heart, the Scrum framework is based on the principles of empiricism and iteration. Empiricism emphasizes the importance of transparency, inspection, and adaptation in managing complex projects. This means that Scrum teams make decisions based on what is known and observed, rather than on speculative plans. Iteration, on the other hand, refers to the process of repeatedly cycling through rounds of delivery to arrive at a desired outcome. This iterative approach allows teams to refine their work continuously, ensuring that they are always moving towards the best possible product.

The flexibility and adaptability of the Scrum framework make it particularly beneficial for teams that need to respond quickly to changing requirements. Whether you’re in software development, engineering, or marketing, the Scrum framework can help your team deliver high-quality products efficiently. By breaking down work into manageable chunks and focusing on continuous improvement, Scrum teams can navigate the complexities of modern project management with confidence.

Scrum Is All About Pace and Practice

In comes Scrum, which understands that you can’t eat an elephant in one bite, or complete a software project in one year-long marathon.

Work under Scrum is done in Sprints – time-boxed periods of one month or less, during which the Scrum Team creates a potentially releasable Increment of the product. Then they show each Increment to the client, confronting it with their expectations and making sure that features included so far fulfill their needs.

Scrum strongly favors the empirical approach, focusing on what works in practice. Every Sprint provides the team with important empirical knowledge they can apply in subsequent Sprints, improving the process every time. This continuous improvement process helps teams perform better in future sprints, enhancing their efficiency and collaboration.

This applies especially to time estimates. You may notice, especially if you’re a developer, that when you try to predict how much time a piece of work will take, you are often way off the mark.

In Waterfall, if you misjudge the time needed to complete a piece of work, the deadline for the entire project might get missed. In Scrum, on the other hand, it will at most affect the current Sprint, and any potential delays will be communicated to the client at the end of the Sprint.

The core of the Scrum process are Scrum Accountabilities – previously called “roles” (Developers, Product Owners, and Scrum Masters) – and Scrum Events, which we will outline next.

Accountabilities within the Scrum Team

Scrum is geared toward teams and facilitating teamwork. The main idea behind Scrum is that teams performing highly creative work require autonomy to achieve excellence. A team works best when it is driven by objectives, not tasks. How they achieve those is for them to decide.

The Scrum Team consists of one Scrum Master, one Product Owner, and a Scrum Development Team. It is a cohesive unit of cross-functional, self-organizing professionals focused on the Product Goal. All the roles support each other – the organization and the client. The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.

What is important to note from the get-go is that a Scrum Team has a flat structure. There is no boss, no manager, no “person in charge.” Instead, members of the team support each other to ensure that everyone is doing their best work and to guarantee effective communication.

(That goes only for the team’s internal structure, of course. Outside of the team, management can still support the process through what’s sometimes referred to as “servant leadership.”)

Let’s dig into each of the Scrum roles and see who’s who.

Who Are the Developers in a Scrum Team? What Do They Do?

The core of the Scrum Team are the developers, the ones responsible for the “how,” who create the actual product. Without them, the whole endeavor wouldn’t make much sense. Their job is to deliver a releasable Increment of the final product each Sprint.

They are also responsible for the quality of the Increment they deliver. To use a quote from the Scrum Guide: “Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.”

The Scrum Guide characterizes the Development Teams as “self-organizing.” They are bound by predetermined rules established with the client, but within those boundaries no one, not even the Scrum Master, can tell them how exactly to implement the required features.

Another aspect of the Development Team’s independence is that its members should have all the necessary skills to deliver the required features. As a complete package, they do not have to rely on external help, lowering the risk of slowing down the Sprint. This is why Development Teams often include not only programmers, but also UX designers and software testers. These cross-functional groups exemplify the collaborative culture of agile teams, working together to achieve their goals effectively.

You don’t want your Development Teams to be too big or too small. If the team has fewer than 3 developers, there is little potential to deliver meaningful Increments during a Sprint. On the other hand, teams with over 9 developers take too much work to coordinate their efforts.

Who is a Scrum Master? What Does a Scrum Master Do?

The Scrum Master (SM) The Scrum Master is accountable for the Scrum Team’s effectiveness, or the “how fast.” The Scrum Master ensures that the team’s work is as productive as possible.

Obviously, having just interviewed one, this is the role I’ve learned the most about.

Scrum Masters are the grease in the team’s gears, ensuring that work progresses smoothly. They do it in a variety of ways: by facilitating Scrum meetings, by asking difficult questions such as, “Why are we doing this?” and sometimes by holding one-on-one coaching sessions with other team members.

The Scrum Master’s moment-to-moment work focuses on communication and motivation. One moment, they may be checking if the client is aware of upcoming meetings and is prepared for them; the next, the SM might be asking the team, “What can we change?” during one of the meetings.

They may also be looking for ways to visualize the team’s progress, showing that more tickets are being completed than created, or illustrating how the team’s planned improvements have been implemented since the previous Sprint.

The SM is also an educator, teaching the team about the psychological processes that influence their daily work, showing the factors influencing team relations and helping them maintain a positive and productive mood.

A Scrum Master strives to focus on facts, not opinions. You’d be surprised how often we can’t differentiate between the two. “Our backlog is not prioritized” is a fact. “We can’t get anything done with this messy backlog” is an interpretation of that fact. The Scrum Master keeps the conversation focused on facts and practical solutions instead of emotions and doomsaying. If the team complains about, say, getting “too many emails,” the SM comes back to them with actual email usage data, which may show that the actual time spent on emails has been declining.

The Scrum Master also protects Developers from unnecessary external influence, often coming from the client. On the whole, the role of the SM is to help the others understand which of their interactions with the team are helpful and which aren’t.

The SM makes sure that the team does not become overburdened with work at any point. Any new features that the client orders can become a serious impediment, and shouldn’t be passed to the team during a Sprint.

After all, interrupting a sprinting person is just asking for them to trip up.

There’s a popular opinion that the Scrum Masters don’t really do much, because their work doesn’t result in a concrete product – but as you can see above, the SM provides plenty of value. Without a Scrum Master, the Scrum Team may soon forget how to use Scrum properly, losing out on both motivation and efficiency. By embodying Scrum values such as commitment, courage, focus, openness, and respect, the Scrum Master fosters an agile culture within the team.

Who is a Product Owner? What Does a Product Owner Do?

The Product Owner (PO) handles the product, or the “what.” They make sure that the features of the upcoming product are clearly defined for the developers and valuable for the client. In many sources, especially in Scrum Guide, the Product Owner is presented as a value maximizer of the product, which seems to be the shortest and best definition of this role.

The Product Owner is the one that communicates the needs of the client, and what the client needs is simply the best product they can get. Therefore, the Product Owner is also in charge of the product vision, keeping in mind both its features and overall design, but also the associated costs and the market situation.

Their typical stance looks a little like this:

“The main users of the system spend too much time looking for a single transaction in the application. In the next Sprint, we need to make that time shorter. If you have any questions about the requested features, feel free to ask me.”

The PO is also in charge of the value of the work that Developers perform. They need to have the product vision and spread it among the team and the stakeholders. To succeed, it is crucial that their decisions are respected by the whole organization.

One of the PO's top responsibilities is managing the Product Backlog – making sure that items in the backlog are clearly defined, understood, and prioritized. This doesn't mean that the Product Owner must define and prioritize items alone, but they are the person held accountable for keeping the Backlog in order.

Dominika stressed that Product Owners do not have to be technically minded people. Instead, they should have strong business skills to facilitate communication between the client and the team.

While the Scrum Masters usually work in the same room as the team, Product Owners can be both internal and external, i.e. either on the client's or the contractor's side. Either way, they will do all they can to ensure clear priorities and communication.

What are Scrum Events? Why Do You Need Them?

To make sure that every Sprint is a success and results in a releasable product Increment, Scrum employs a range of Scrum Events, sometimes called ceremonies. Each has its own objectives and characteristics.

Sprint Planning

This is the first meeting of a new Sprint. At the planning meeting, the team establishes what part of the work they want to tackle during the coming Sprint.

They look at the Product Backlog and choose the most valuable features that they can realistically implement in the coming iteration, creating the Sprint Backlog and the Sprint Goal. This is also the time when the entire Scrum Team establishes how exactly the features will be implemented.

Daily Scrums (Stand-Ups)

The Daily Scrum occurs, as you might guess, every day during the Sprint. It should not take more than 15 minutes and the main purpose of it is to inspect progress toward the Sprint Goal.

This meeting also helps ensure that the team is aware of what work has been completed the previous day, what will be done today, and what blockers may impede work in the coming days. Thanks to the Daily Scrums, the team always knows whether it is on track to achieving the Sprint goals.

The Daily Scrum is sometimes referred to as the Daily Stand-Up because of the widely accepted practice of standing up during the meeting. This is to ensure that the meeting remains compact; nobody wants to stand around for an hour and a half, after all.

But if you asked Dominika, standing up is really not as important as some practitioners might think. As long as the team establishes work synchronization and creates a plan for the day, they might as well be lying down on waterbeds.

Backlog Refinement

Backlog Refinement is not included in the official Scrum Events, but Dominika still mentioned it as one of the most important points of a Sprint.

During the Backlog Refinement, the team discusses what the PO/client needs and how to deliver it. Individual elements of the backlog are revised and compared to the overall project vision. In short, the team wants to know “Why do we want this?” in order to avoid unnecessary work on impractical features.

The importance of working on the Backlog becomes apparent at the start of the next Sprint. With a refined Backlog, the team can be sure that the planned features fit the client's needs. They can plan the Sprint accordingly and get to work on implementing the features.

The Backlog Refinement doesn't need to be an actual meeting; what's important is the process. If the team chooses to refine the backlog piecemeal along the course of the Sprint, that is absolutely fine.

Sprint Review

The Review marks the end of the Sprint and usually takes place during a conference call with the stakeholders of the project. The team shows the effects of their work to the stakeholders, sometimes explaining why some features did not make it into the resulting Increment.

This meeting is the most important to keep all stakeholders happy and informed and to discuss the product vision together. It also helps to inspect the outcome of the Sprint and determine future adaptations.

The Sprint Review is an opportunity for the stakeholders and the Scrum Team to meet. It also helps developers change their perspective: instead of “just doing the work,” they shift to true development with the product vision in mind.

The Scrum Guide recommends a 4-hour Sprint Review meeting for each 1-month Sprint, but the meeting will be shorter for shorter Sprints.

Retrospective (Retro)

The Retrospective marks the true end of the current Sprint. Although the next Sprint starts immediately after the last one, the Retrospective serves more as a moment of reflection and preparation before the next Sprint properly kicks off with another planning meeting.

The team starts by discussing any problems that may have arisen during the last Sprint and any improvements they would like to introduce in the next one. This is the time to go over any difficulties with the goal of making each new Sprint better than the last.

Scrum Artifacts

Scrum artifacts are the tangible components of the Scrum framework that provide transparency, inspection, and adaptation. These artifacts help Scrum teams and stakeholders visualize the progress of the project and make necessary adjustments. The three main Scrum artifacts are:

1. Product Backlog: The product backlog is a prioritized list of features, requirements, and tasks that the development team needs to complete. Maintained by the Product Owner, the product backlog is a living document that evolves as the project progresses. It serves as the single source of truth for what needs to be done, ensuring that the team is always working on the most valuable tasks.
2. Sprint Backlog: The sprint backlog is a subset of the product backlog that is selected for a specific sprint. It includes the tasks and features that the development team commits to completing during the sprint. The sprint backlog is created during the Sprint Planning meeting and serves as a plan for the sprint, guiding the team’s work and helping them stay focused on the sprint goal.
3. Increment: The increment is the working product that is delivered at the end of each sprint. It is a tangible representation of the progress made by the development team and must meet the Definition of Done. Each increment builds on the previous ones, ensuring that the product evolves in a coherent and functional manner.

By providing a clear and transparent view of the project’s progress, Scrum artifacts help teams identify areas for improvement and make necessary adjustments. They are essential tools for ensuring that the team remains aligned with the project goals and can adapt to any changes that arise.

Empiricism and Iteration

Empiricism and iteration are the core principles of the Scrum framework, guiding how Scrum teams manage complex projects. Empiricism emphasizes the importance of observation, experimentation, and learning. In the context of Scrum, this means making decisions based on what is known and observed, rather than on speculative plans. Transparency, inspection, and adaptation are key to this approach, allowing teams to continuously refine their work.

Iteration, on the other hand, refers to the process of repeatedly cycling through rounds of delivery to arrive at a desired outcome. In Scrum, this iterative process is embodied in the concept of sprints. Each sprint is a short, time-boxed period—typically lasting between one week and one month—during which the development team delivers a working product that meets the sprint goal. This approach allows teams to deliver value incrementally, making it easier to adapt to changing requirements and ensure that the product evolves in the right direction.

By combining empiricism and iteration, the Scrum framework enables teams to manage complex projects effectively. The focus on observation, experimentation, and learning ensures that teams can respond quickly to new information and changing requirements. Meanwhile, the iterative approach allows for continuous improvement, helping teams deliver high-quality products in short cycles. This combination of principles makes the Scrum framework a powerful tool for navigating the complexities of modern project management.

Final Thoughts on Scrum

Scrum is simple to understand and difficult to master – by definition.

Regarding “simple to understand,” we hope this article provided you with a basic overview that will help you improve your work with Scrum teams in the future.

As for “difficult to master,” keep in mind that implementing Scrum is just the first step, after which you need to stick to its rules and let it run its course before reaping the benefits.

Not every software house manages to see that process to the end. They end up with half-baked Scrum-like practices that don't really bring much benefit at all and also contribute to some misconceptions about Scrum as a whole. Although implementing only parts of Scrum is possible, the result is not actual Scrum.

We discuss the Scrum misconceptions and mistakes as well as the three pillars of Scrum in other posts. If you want to be the first to get our new blog articles, stay tuned by following our social channels – here's our Facebook, Twitter and LinkedIn.

Over the years, we've helped a number of clients implement Scrum at their companies, particularly Evalueserve, who singled the change out as a key contributing factor in what they called their “best year ever for product innovation.” You can check out the full case study here to learn more.

And if you have any questions or needs related to Scrum or Agile, just reach out to us and we'll gladly support you however we can!