Software has changed a lot over the last couple of decades. (It goes without saying, right?) And—more importantly—it keeps changing. Naturally, the software development process changes, too. 

That being said, it’s not sustainable to constantly invent new software development processes. Wouldn’t it be best to create a development process flexible enough to accommodate the advances and changes in software development? Enter Agile software development. 

Agile software development is an iterative, adaptable approach to software development. In this post, we’ll break down one of the most popular Agile frameworks: the Scrum methodology. 

What is Scrum?

Scrum methodology (also called the Scrum framework) is an Agile framework for software development.

So what exactly does that mean?

Traditional software development processes operate linearly—planning first, then development, then testing, and so on. Agile software development, on the other hand, takes an iterative approach. Projects are broken into short stretches of time called sprints. (A sprint typically lasts between two weeks and a month.) 

With each sprint, the development team adds and improves features to gradually deliver the best product possible. Testing and development happen frequently and often overlap. (Want to read more about Agile software development? We’ve got a post dedicated to the topic!)

There are a number of frameworks that fall under the Agile umbrella—Scrum, as mentioned above, is one of those frameworks. 

The Scrum methodology is characterized by its focus on teamwork and collaboration. In fact, the name Scrum is taken from rugby scrums, a part of the game that requires a coordinated team effort. During each sprint, Scrum teams meet daily to track their progress, identify and address roadblocks, and keep the project on course. (More on the types of Scrum meetings later!)

Scrum key principles

The Scrum framework is built around six core principles—each aspect of the Scrum method, from daily sprint meetings to Scrum artifacts, reflects these principles. So let’s get into them! The six key Scrum principles are: 

1. Control over empirical processes: With its focus on transparency, adaptation, and frequent evaluation, the Scrum method helps development teams test and improve their product at each stage of the process.

2. Self-organization: To successfully use the Scrum framework each member of the team must fully buy in to the process. This requires a high level of independence and self-organization. 

3. Collaboration: To deliver the best product possible, a software development team has to work together. Teams share responsibility and accountability throughout each cycle. As the saying goes: succeed together, fail together. 

4. Value-based prioritization: One of Scrum’s defining features is its flexibility. To adapt to and address new demands and requirements for the project, Scrum teams constantly evaluate and reprioritize each task they need to accomplish. 

5. Time-boxing: In the Scrum methodology each element of a sprint has a clearly defined timeline. The sprint itself is two weeks long, but daily meetings also operate on strictly held timelines. 

6. Iterative development: Because Scrum is an Agile framework, products are built iteratively. This allows for constant improvement, flexibility, and, at the end of the day, a high-quality product. 

Who is part of a Scrum team?

We’ve been throwing around the term “Scrum team”—let’s take a look at what it actually means. On one level, it’s self-explanatory: a Scrum team is simply a software development team using the Scrum framework. But there’s a little more to it than that. 

To help each sprint operate smoothly, the Scrum methodology outlines three positions—often called Scrum roles—that every Scrum team should include: Product Owner, development team, and Scrum Master. In the following section, we break down each role and their responsibilities for you. 

Product Owner

To deliver the best possible product, a development team must be acutely aware of the customer’s needs and expectations. There needs to be an open line of communication between the two parties. So how do you achieve this? Enter the Product Owner. 

The Product Owner is responsible for knowing the product inside and out. They are the primary point of contact between the customer and the development team. They take the customer’s requirements and translate them into action items—this means creating and maintaining the product backlog. 

Each Scrum team has one product owner (this should never be a shared role). 

Development team

This one is pretty straightforward: The development teams are the individuals who, well, develop the product. Scrum development teams should be small and have a wide skill set—a typical team includes both designers and coders. 

Remember the key principles of Scrum? This is where collaboration comes in. Members of a Scrum development team should train other team members in their skills to help avoid bottlenecks. Because the Scrum development team is responsible for doing the actual coding, they are responsible for estimating and allocating the time and resources required for each backlog item. 

Scrum Master

If you haven’t picked up on this already, let’s make one thing clear: The Scrum framework calls for a lot of meetings. And someone has to schedule, coordinate, and moderate those meetings. This is where the Scrum master comes in. 

The Scrum master’s domain is everything Scrum related. How is the team implementing Scrum methodology? Are there areas that require fine-tuning or improvement? How can the team get better with each sprint? 

Additionally, they are responsible for making sure Scrum meetings are scheduled and running smoothly. 

Scrum artifacts

We’ve covered a lot of Scrum jargon, but we’re not quite done yet. In Scrum, an artifact is simply a mechanism—or tool—for managing and completing work. There are four main Scrum artifacts: 

Product backlog

The product backlog, maintained by the Product Owner, is a list of requirements for the final product. As priorities change, the Product Owner shuffles and re-orders the backlog. At the beginning of each sprint, Scrum teams will select a number of tasks from the product backlog to address during that sprint. 

Sprint backlog

Each sprint, the tasks selected from the product backlog are put into the sprint backlog. The sprint backlog is maintained and used solely by the development team. Often, these tasks are organized on a Scrum board—a visual framework for tracking the progress and priority of each task. Tasks are sorted into columns on the board: stories, to do, in progress, and complete. As tasks are completed, the development team moves them through these columns. 

User story

User stories are a way of describing backlog items. The product backlog is essentially a list of features that need to be included in the final product. User stories describe those features from an end user’s perspective: Why does the user need this feature and how will it look in practice?

Product increment

At the end of each sprint, you are (hopefully!) left with a pile of completed tasks—together these make up the product increment. Which is to say, the product increment is simply the working version of the product at the end of a sprint. 

Scrum events

We’ve mentioned Scrum meetings (and how many of them there are) a few times without any explanation—at long last, here’s the explanation! The Scrum framework is built around a number of “events.” Some of the most common—and important—Scrum events are: 

Sprint

The sprint is the backbone of Agile software development—it’s the “meat” of the Scrum process. Sprints, which typically last between two and four weeks, are the organizing unit of Scrum. Work is planned out in sprints, meetings are scheduled around sprints, etc.

Sprint planning 

If you’re driving in unfamiliar territory, you don’t just start driving. (Or maybe you do, but it probably doesn’t end too well.) You’ll want to consult a map and figure out the best route to your destination. 

Similarly, Scrum teams don’t select a few backlog tasks and launch pell-mell into a sprint. There’s a lot of planning involved. A sprint planning meeting, held at the beginning of a sprint, should be a few hours long—plan on two hours for each week of your sprint. During that time, you and your team need to answer a few questions: What are we going to achieve this sprint? And how are we going to achieve it? Be as specific as possible. 

Daily meeting

Daily meetings—also called daily scrums or standup meetings—are short (fifteen minutes, ideally) meetings held at the same time each morning. During these meetings the development team discusses what they accomplished the day before, and what they hope to accomplish today. 

Sprint review

The Scrum method encourages transparency between all stakeholders. Sprint review meetings help facilitate this transparency. Held at the end of each sprint, these meetings allow the Scrum team to present the product—in its current iteration—to other stakeholders. Based on the feedback given in this meeting, the Product Owner refines the product backlog. 

Sprint retrospectives

Sprint review meetings are attended by a number of stakeholders—sprint retrospectives are just for the Scrum team. These meetings are held at the end of each sprint and give team members a chance to reflect on the previous sprint. 

During sprint retrospectives, ask your Scrum team a series of questions: What went well? What went poorly? And, most importantly, how can we improve next sprint? 

The benefits of Scrum

Hopefully you’ve got at least the Scrum basics down pat. Now what? You’ve got to decide if the Scrum method is something your team could benefit from. 

The benefits of Scrum lie largely in the fact that it is an iterative approach. By using the Scrum framework, your team will be able to adapt to the ever-changing world of software development and deliver a product that gets better with each sprint.