Scrum is a project management framework that helps small, close-knit teams develop complex products incrementally. Scrum focuses on how people work instead of what they do. Scrum relies agile principles and is the most popular agile methodology out there.
In Scrum, teams develop software in sprints and release what they’ve worked on every two weeks. This way, customers get bug fixes and new features as soon as they’re done, and there’s less risk altogether.
What is Scrum
Scrum is the most popular agile project management framework that’s used in software development organizations. Scrum can also be used in schools, agencies, government, and other types of organizations.
Scrum was first introduced in early 1990s by Jeff Sutherland and Ken Schwaber.
Scrum got its name from rugby. In rugby, scrum is when a team huddles around the ball and tries to move it down the field in order to win. Scrum is a metaphor meant to reflect how everyone needs to work together to complete the project.
How Scrum works
In Scrum, you deliver to your customer new code and functionality every two weeks. Those two weeks represent one sprint and the whole workflow is built around them. To better understand how Scrum works, we’ll talk about what happens before the sprint, during, and after.
Before you can start coding, you first need to plan what you’ll work on. In Scrum, there are no big master plans like in Waterfall where you lock up your resources months in advance. Instead, Scrum lets you work on one thing for two weeks and then reflect on what you’ll work next.
Everything starts with your users/client. First, you get a wish list from your customers in a special format called user story, which looks like this:
As a (role), I want (feature) so that (reason)
eg. As a manager, I want custom time reporting so that I can calculate my employees’ exact salary.
Then, you create a task for each user story, put it in a backlog, and estimate each task (together with the team).
Finally, you decide on what items you will work during the sprint. If some item can’t be done in one sprint, it’s called an epic and you have three options: split it across several sprints, leave it for later, or make a new project and form a separate team to work on it.
You set up a Kanban board to visually track progress, see who works on what, and control bottlenecks. The board is usually split into several task lists (columns):
Backlog - all feature requests and bugs go here first
Next Sprint - tasks you’ll work after the team finishes the current sprint
To-Do - what the team needs to complete during the current sprint
In Progress - tasks that the team is actively working on right now
Testing - finished tasks that need to be tested before marked as complete
Done - finished tasks that are ready to be shipped once the sprint end
Once you’ve decided on what items to work, the team pulls tasks from the To-Do columns and moves them to In Progress as they start working on them. Once they’re finished, the task goes to Testing; if the task needs more work, it goes back to In Progress; once the task meets the Definition-Of-Done criteria, it goes to Done and is ready to be shipped.
Each day before work, the team has a daily standup. The meeting doesn’t take longer than 15 minutes and everyone shares a quick status update:
Things I have done since yesterday’s meeting
Things I am going to get done today
Obstacles I need someone to remove
To measure progress, the team uses a Burndown Chart, which is a graphical representation of work left to do versus time. That chart shows how efficient the team is, if they’re going to ship on time, and if they need to optimize the process.
At the end of the sprint, the team reflects on what they’ve done. They have two reflection sessions:
Sprint review (2h), where they discuss the work they’ve done and the planned work they didn’t do
Sprint retrospective (1h), where they talk about the process (what went well and what could be improved in the next sprint)
After the reflection, the team estimates new user stories and decide on what to work during the next sprint.
Download in High-Quality
Roles in Scrum
There are 3 roles in Scrum:
Product owner is the visionary and represents the voice of the customer/user. If a team member has any questions regarding functionality of some feature, it’s product owner’s job to clarify the purpose of that feature.
Product owner focuses on the business side of product development and spends most of the time talking with stakeholders. Product owner doesn’t care about the technical implementation, only the end result.
Product owner’s main job is to:
Gather and write user stories
Refine and prioritize backlog
Handle clients and demo new features
Scrum master’s role and responsibilities are similair to project manager’s, with an emphasis on team facilitation and making sure the Scrum framework is followed.
Scrum master, as opposed to a traditional project manager, doesn’t manage people because that goes against agile pricnipes.
Scrum master’s main job is to:
Remove impediments for team members
Facilitate team events
Track sprint progress
The team does all the actual work, from analysis and design to coding and testing. They are self-organizing and work without supervision.
Scrum teams are cross-functional, meaning they don’t have clear sub-role and everyone can do anything. Most teams compromise by hiring T-shaped workers so, while everyone can do anything, there is still some specialization and work division.
Scrum work only if the team is small, up to 9 people, max. Any team larger than that changes team dynamics, thus rendering Scrum ineffective.
How to implement Scrum
Scrum is more about about the mindset than some checklist you need to follow to a T. Once you have agile mindset, here’s the most common way companies implement Scrum:
Pick a product owner
Pick up to 9 cross functional team members
Pick a scrum master
Create and prioritize a product backlog
Refine and estimate items in the product backlog
Put up a kanban board
Plan the sprint
Have a daily stand-up
When finished, do sprint review and sprint retrospective
Immediately start the next sprint
Scrum isn’t for everyone and it has the same weaknesses as all agile methodologies. Read more about advantages and disadvantages of Agile.
For more on Scrum, check out Scrum: The Art of Doing Twice the Work in Half the Time (this one does a great work of capturing the spirit of Scrum, but lacks concrete details on how to implement it), and this free online Scrum guide.
If you already do Scrum, test yourself with Kniberg’s Scrum Checklist to see how well you do Scrum.
For statistics on how others use Scrum, check out the The 2015 State of Scrum Report from Scrum Alliance.
Check out 12 books every project manager needs to read.