What is Scrum?

Scrum is an Agile project management framework that organizes projects in iterations called Sprints. The Scrum team is responsible for delivering value, while the Product Owner communicates with the stakeholders and prioritizes the work. This iterative approach allows Scrum to produce work and test it quickly.

A complete overview of the Method, Practices & Tools

Scrum is one of the most popular frameworks used to practice Agile. In fact, some even think that the two terms are the same. However, this is not true. Agile is an iterative project management approach that speaks about delivering most value and gives 12 principles for companies to follow. While Scrum is one of the frameworks that teams and companies use to instill Agile values into their daily operations. So, what is Scrum? Let’s learn more about the framework to find out what makes it so popular.

The history of Scrum 

It was in the 90s that the talks about improving the way software development teams deliver results started to happen. Waterfall projects were constantly late and anything the managers did to improve the situation made them even later. Looking for something that will work, it was Jeff Sutherland that started working with smaller teams and organizing projects around iterations. He quickly found that arranging work in this manner offered transparency, focus and commitment that waterfall projects previously lacked. 

As the teams started showing results, talks of the process grew. A colleague of Jeffs’ drew the parallel between a small software team working closely together and the rugby scrummage. Thus, the name Scrum was born. And it was Ken Schwaber and Jeff Sutherland in the 1995 OOPSLA conference that officially introduced the process of Scrum to the public. 

Since then Scrum was improved by many others and grew from a process into a fully formed framework. And as such became one of the most popular ways of applying Agile.  According to the 14th State of Agile report, 58% of respondents said they were using Scrum to practice Agile. Some of this popularity should undoubtedly be credited to the fact, that Scrum is quite easy to understand. However, the main reason for the wide application is that it offers a way to address complex problems, while productively and creatively delivering results of the highest possible value.  

Article looks too long? Get a summary of Scrum Methodology in 1-page infographic!

Scrum in project management

The way Scrum works is simple – the team plans and completes work in 1-4 week iterations, delivering an incremental addition to the value after each Sprint. A meeting with stakeholders is then held after each Sprint to gather feedback and the team can adjust the course of action for the next Sprint according to their comments. Making it easy to react and adapt to any changes happening inside or outside the company. 

Therefore, when practicing Scrum the team can communicate easier, gather feedback faster and keep working in the direction that is the most suitable for all the stakeholders. This way of operations requires transparency and accountability, while the team works as one unit with a single goal. 

Scrum works best when it is applied in a team setting. Thus, even large organizations should organize work around autonomous teams. Scrum can be scaled to fit companies of various sizes. However, as the company size goes up, Scrum productivity goes down. You should prepare for such a scenario and not blame your teams.

How does it work? 

To organize the work and achieve the desired results, Scrum uses particular roles, tools and practices. And it is by knowing them, that you will get the full idea of what working within a Scrum project looks like. So here they are. 

Scrum Roles

The first thing you will do, when adopting Scrum is focus on the structure of your company. The framework is best when the work is centered around small teams with specific goals. Thus, you will have to review and maybe rethink your structure. Once the teams are set, you will also have to assign new roles within them. Scrum requires 3 particular roles to be available within each team. 

First up – What is a Scrum Team

The largest and the most familiar role to the new practitioners. Scrum team definition states it is a group of cross-functional professionals that work together to deliver the end result. Contrary to traditional project management practices, it is entirely the Scrum teams’ responsibility to plan tasks and deliver value after each Sprint. As the Product Owner only sets the direction but does not plan or assign tasks. 

To achieve this autonomy, the Scrum team size has to account for enough varying professionals to deliver value. Keeping in mind that a team smaller than 3 people can have skill constraints and a team larger than 12 can become too complex to work effectively. 

Second – The Product Owner 

Commonly confused with a project manager, the role of the Product Owner is a little different. Their sole responsibility is setting the overall vision and direction for the end product. To achieve this, they have to communicate with the stakeholders and gather their requirements. Prioritize User stories according to their importance and relay this information to the Scrum team. 

Product Owner is there to lay out a plan of what should be done, while the Scrum team choses on how to do it and delivers the work independently. 

Lastly, the Scrum Master 

The last role defined in the framework is the Scrum Master. While this again sounds like some sort of a manager, it is not. The Scrum Master is there to aid the team in applying the practices on the daily basis. They help transition to Scrum by providing training and then work on continuous process improvement within the team. Here is a full article explaining the difference between a Scrum Master and a project manager.

Just like the Product Owner, it is a supportive role for the Scrum team to help deliver the best results. While the Product Owner and the Scrum Master can be part of the Scrum team, usually they are not as it creates a certain conflict of interest.

Scrum Tools

Once your team structure is sorted, it is time to talk about the tools and artifacts of Scrum. Working in an iterative manner requires a little different way of planning and tracking the work, thus the framework uses a Scrum board, User Stories, and Story Points to describe the work the team is doing. Here is a little more on each of these tools. 

Agile Scrum Board 

The Scrum board is one of the most important tools that allow to effectively plan and track the progress that is being made towards the end goal. It is usually composed out of 2 sections that are managed by the Product Owner and the Scrum team. 

The first Scrum board section is the Sprint Backlog. This is a place the Scrum team uses to divide User Stories into actionable tasks and estimate their duration for the Sprint. Sprint Backlog is emptied out during the Sprint and then refilled with new tasks by the Product Owner during each Sprint Planning session. 

Progress tracking columns are the second section of the Scrum board. This is managed solely by the Scrum team and helps them track the progress that is being made during the Sprint. This section can be simple with just two sections – Doing and Done or as elaborate as the team needs to track the progress effectively. Here is a Scrum board example in Teamhood. 

To effectively track and prioritize customer requests, the Product Owner usually has a separate board called the Product Backlog. It holds all the plans for the project in the form of prioritized User Stories. While the Scrum team can also gather User Stories from the stakeholders it is only the Product Owner that can add them to the Product Backlog. This board is used during every Sprint Planning to set the Sprint goal and plan the Sprint Backlog.

User Stories 

To define plans and work items Scrum uses User Stories. These are gathered from the client and define what the end result of the project should be. To help write the User Stories, there is a certain format they have to fill – As a …, I want …, so that … . 

So as the Product Owner consults with the clients and stakeholders, he or she writes down the User Stories in this format and places them in the Product Backlog according to their priority. Then, during the Sprint Planning, the Scrum team takes the most important user stories and splits them into actionable tasks for them to complete. 

When writing User Stories, it is important to remember that the Scrum team has to be able to accomplish them during one Sprint. If that is not possible, the User Story becomes an Epic. Which then the Product Owner divides into smaller User Stories. Read more on User Stories. 

Story Points 

Lastly, once the Scrum board is set and filled with User Stories, the team has to estimate their duration. For this practitioners have two options – hours or Story Points. Estimating in hours is self-explanatory while using Story Points is something particular to this framework.

At first, it may be a little confusing to define what one Story Point is worth, but in reality, it is quite simple. As the Scrum team plans out tasks for the Sprint, they should identify the smallest task and assign 1 Story Point to it. Then, weigh the rest of the tasks against it and assign Story Points accordingly. 

After few Sprints, the Scrum team will know the approximate value of a Story Point and how many they can deliver in an iteration. Thus, defining team Velocity. Also, usage of such an estimation metric allows the team to focus on evaluating the tasks without the pressure of time constraints. 

Scrum ceremonies

Now that you know of the roles and tools this practice uses, the last thing to find out about Scrum is how it works on a daily basis. Being an iterative method, the project is run in 1-4 week-long iterations called Sprints. And to ensure these Sprints are effective, there are 4 specific events to be held during each of them – Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. 

But first more about the Sprints themselves. 

The Sprint 

Sprints are the heart of Scrum – it is a time-defined work iteration with a specific goal for the team to achieve. The duration of a Sprint is individual to each team, but it usually lasts 1-4 weeks. During this time the team plans, executes and reviews the work with stakeholders. And once the Sprint is over, another one begins immediately until the project reaches its end. 

It is important to note, that once a Sprint has begun it has to be finished according to the timeframe. In an event that the Sprint goal has become obsolete, the Product Owner can cancel a Sprint and plan a new one. However, this is not recommended and rarely happens.  

4 Key events happen during every Sprint to make it effective. 

Scrum meetings

I. Sprint Planning 

This is a timeboxed 8-hour event where the Scrum Team and the Product Owner discuss and set the goal for the Sprint. Then, the team picks User Stories from Product Backlog to help achieve this goal and divides them into actionable tasks. Lastly, all these tasks are placed in the Sprint Backlog and evaluated in hours or Story Points to see if the team can achieve them during the Sprint.  

The role of the Product Owner during Sprint Planning is to help set the goal. However, it is solely up to the Scrum team to choose which User Stories will help achieve this goal. 

II. Daily Scrum 

Once the Sprint Planning is complete, the team starts working. To keep everyone on track and solve any issues that appear, the team holds a 15-minute meeting every day called the Daily Scrum. Here each of the team members shares what they worked on yesterday, what they will be doing today, and how it will help achieve the end goal.  

It is important to note that this meeting is not about reporting status. It is about sharing what has been done towards the goal and voicing any issues that team members see with reaching this goal during the Sprint. This way, the Scrum team can identify and solve issues faster. 

III. Sprint Review 

After the allocated time for a Sprint runs out, the team has most likely achieved a substantial improvement towards the end goal. Thus, it is important to check if this additional value is what the stakeholders wanted. A 4-hour Sprint Review is held just for that.  

Here, a representative of the Scrum team presents the Sprint results and the stakeholders provide their feedback. The Product Owner then gathers these comments and if necessary, makes changes to the Product Backlog to reflect the change of direction before the next Sprint starts. 

IV. Sprint Retrospective 

The last thing that happens before a new Sprint is holding a 3-hour Sprint Retrospective meeting. As the Scrum Team and the Scrum Master gather to discuss the work process. The focus here is on how well the team has worked together during the Sprint. As well as what can be improved in the next iteration to make the process more effective.  

While all the Sprint events have predefined times, these are more of a suggestion than a requirement. In fact, more experienced and effective practitioners often take much less time than allocated. So, if your meetings are shorter there is no problem. Make sure though to not hold your meetings for longer than the described time as they run the risk of becoming ineffective. 

Common Misunderstandings 

Using Scrum roles, tools, and events most teams can create a process that is reactive to changes and delivers more value. However, as with any framework, there are bound to be misunderstandings amongst the practitioners. Here are some of the most common ones: 

1. Scrum Master is in charge

While the word ‘master’ sure sounds grand, the Scrum Master is not there to give orders. The role of the Scrum Master is all about binding people and helping them work together in the Scrum way. They have to facilitate the Scrum process in changing people’s perceptions, adapting the company culture, and then helping to fulfill the daily Scrum operations.

Scrum master is not in charge of anything, but making sure the Scrum process works

2. Daily Meetings are just about checking in

While it may seem just like a check-in on the surface, Daily Scrum is actually a way for the team to meet and discuss a further course of action. To better understand its purpose we could look at this meeting like a football huddle. Where the team gathers, tries to figure out why the quarterback got injured and what is the best course of action to win the game.

Daily Scrum is there to replan and shift focus according to the changed circumstances. While making sure the Sprint Goal is being met. Some teams even shift the focus of this meeting from reporting the progress onto the Sprint Backlog. As they take the most important task there and discuss what they can do to make sure it is completed today. Thus focusing on the goal what can be done to reach it.

Daily meetings are not about reporting, but about finding a better way to do things today

3. The meetings should take the whole time they are given.

Scrum defines a time box for each meeting. It says what is the maximum amount of time that each meeting should take. However, what most teems fail to understand is that this is just the maximum time, not the required time.

In fact, more advanced teams usually take a lot less time to complete the events. As they already have an established process and work more efficiently. Scrum is designed to deliver more value in less time and the events are no different.

Time Boxes are there to guide your meetings, not requirements to be met exactly

4. It is enough to only discuss changes during Sprint Retrospectives

Sprint Retrospectives are designed as a place to discuss and improve the way teams complete work during the next Sprint. However, as most teams perform this event, many forget to actually implement the solutions.

It should be a rule of thumb for the team to include at least one discussed solution in the next Sprint and, if possible, more. Thus making sure continuous improvement is made not only to the product but to the process as well.

It is not enough to discuss but is also important to implement changes on a regular basis

5. Scrum and Scrum tools are just for software developers

While it has started out as a framework for software development, Scrum has proven to be adaptable in many other fields since. Product development, service providers, automotive industries, and even government offices are using Scrum to be more adaptable and responsive to change.

Scrum is created for any company that wants to be able to react and adapt to the changing market

6. You have to release after each Sprint

The idea of working in Sprints is to have something of value created after each short work cycle. However, this does not mean you have to necessarily release or ship a product to your customers after every Sprint.

Slower teams may take several Sprints to release a product and faster teams could release several times during one Sprint. As long as you have finished an addition of value after each Sprint you do not have to worry about aligning your releases and Sprints.

At the end of each Sprint you have to deliver additional value, not necessarily a full release

Scrum methodologies – Summary

Scrum is a great framework aimed at testing out new ideas and immediately understanding if they are going to work in the long run. Teams can test new things and include new practices as soon as circumstances change. After a few iterations, they already have a measurable result to present to stakeholders and evaluate. Scrum is a great choice for teams in need of managing projects within changing circumstances. And honestly, that is most of us.

Compared to other Agile frameworks, Scrum offers most guidance to its users. Thus, it is the most understandable. However, do not be fooled as mastering Scrum is not as easy, as it may look from the first glance. If you are interested to see how Scrum compares to other Agile frameworks like Kanban or Scrumban – here is Kanban vs Scrum vs Scrumban.  

And for those looking to apply Scrum in a larger company, here is an overview of Scrum of Scrums.