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.
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 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.
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 scenario and do not blame your teams.
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.
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. As Scrum requires 3 particular roles to be available within each team.
The largest and the most familiar role to the new practitioners. Scrum team 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 team has to be composed out of 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.
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 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.
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 interests.
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.
The Scrum board is one of the most important tools that allows to effectively plan and track the progress that is being made towards the end goal. It is usually composed out of 3 sections that are managed by the Product Owner or the Scrum team.
The first section is the Product Backlog. This is managed by the Product Owner exclusively and 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 section of the board is used during every Sprint Planning to set the Sprint goal and plan tasks.
The second 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 during each Sprint Planning session.
Progress tracking columns are the last section of the Scrum board. This is also managed 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 are a few a few Scrum board examples.
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.
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.
The Events of Scrum
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 the 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.
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, completes 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.
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.
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 share 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 on 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.
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.
The last thing that happens before a new Sprint is holding a 3-hour Sprint Retrospective. 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 that 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.
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 missunderstandings amongst the practitioners. Here are some of the most common ones:
Daily Meetings are just about checking in
While it is often viewed as a progress report, Daily Scrum should be about discussing the further course of action to achieve the Sprint goal. This is just like a sports huddle during the break. Where the team evaluates situation and makes decisions on how to win the game.
Just discussing the progress changes is enough
Sprint Retrospectives are a great way of finding more effective ways to work. The most common problem is that those ideas stay as just that – ideas. Instead, each Sprint Retrospective should end with at least one actionable change that is implemented in the next Sprint.
Scrum is for software development only
It is true this process was first introduced in the software development teams, but it has been a long time since then. Now Scrum is used in many industries from the automotive industry to the government offices. As it is a great way of managing projects with changing circumstances.
Read more on the Scrum misconceptions.
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, here is Scrum vs Kanban vs Scrumban.
And for those looking to apply Scrum in a larger company, here is an overview of Scrum of Scrums.