With ceremonies and artifacts, it’s easy to think the Scrum Guide is some kind of religious scripture.
But you can learn the Scrum framework without feeling like you’re at a Sunday sermon. It’s less overwhelming when you get past all the jargon.
This is a guide to the guide — created to help you better understand and implement Scrum to boost your team’s productivity. We’ve translated the Scrum Guide to plain English, highlighted the most important elements in order, and assembled links to helpful videos, articles, and more.
What is the Scrum Guide?
The official Scrum Guide is a guide to the Scrum framework, written and maintained by Ken Schwaber and Jeff Sutherland, the original creators of Scrum.
Scrum is a framework for implementing the Agile methodology for project management. It divides projects into shorter sprints and breaks larger teams down into Scrum teams of 3–9 people.
The first version of the guide was released in 2010 and the latest update in November 2017, but a newer update is planned for release before the end of 2020.
The pillars and values of the Scrum Guide
Before you think about implementing Scrum, your whole team should learn the pillars of Scrum. Internalizing these core values is the first step in making the switch.
The 3 pillars of Scrum
Back in 2010, these pillars were all there was — the foundation of the Scrum mindset — until Scrum values were added in 2017.
- Transparency: Make sure everyone on the team has access to and understands the goals and current status of the project.
- Inspection: Continually inspect all team outputs including the product backlog (list of requirements) and product increments (versions).
- Adaptation: Adapt to changing priorities by continually refining your high-level goals and immediate backlog (by collaborating with customers).
The 5 core values of Scrum
The Scrum values are designed to help your team make the mindset shift needed to implement the Scrum pillars.
- Commitment: All team members must commit to finishing the user stories (work) they own. The team must also be careful with the scope of each sprint they commit to.
- Courage: Your team must have the courage to ask hard questions of stakeholders. No blind following allowed.
- Focus: Focus unapologetically on the most important user stories during each sprint.
- Openness: All team members must be open to new ideas and changing their approach, rather than being loyal to the original plan.
- Respect: Respect is the foundation of self-organizing teams.
We explain them more in-depth, including how to internalize and implement them, in our guide to Scrum values.
Scrum team structure: What are the 3 Scrum roles?
A Scrum team typically has a product owner, a Scrum master, and “regular” development team members. These are the three main roles in Scrum.
The development team must have all the skills necessary to finish a product increment without outsourcing any part of the project.
Product owner
A product owner controls the high-level scope of the project. It must be someone with a clear understanding of what your customers need and want.
It could be someone from sales or marketing, an internal user of the product, production manager, or even a business analyst.
Scrum master
A Scrum master is a team member who “enforces” Scrum during meetings. They aren’t a traditional top-down leader. Instead, they should lead by example and focus on facilitation and problem-solving.
Not all teams who implement Scrum use a Scrum master to oversee meetings and outputs. For example, here at staging-mondaycomblog.kinsta.cloud, our R&D team uses Scrum without a master. They share the responsibility of maintaining Scrum principles between team members.The focus on self-organization boosts team buy-in and makes team members take ownership seriously.
Team member
All the other members are equal within the Scrum framework, regardless of their job description or technical skills.
Learn more about Agile roles, including helpful additions like technical experts or testing teams.
How large is the average Scrum team?
A Scrum team should be made up of 3–9 members, excluding the product owner and Scrum master. The average Scrum team size is 7.4 members, with 78% of teams in the range between 5 and 9.
Main Scrum workflow: What are the 3 artifacts of Scrum?
The Scrum workflow focused on three specific “artifacts” or outputs specific to Scrum. These guide your sprints and overall project workflow.
Product backlog
A product backlog is a list of features and requirements that your product needs to be complete or to meet your customer’s needs and expectations.
In Scrum, rather than focusing on features from the developer’s perspective, you should focus on user stories. A user story is a feature or functionality as seen from the user’s point of view.
For example, “a user can copy and paste design elements into another template.”
Sprint backlog
The sprint backlog is the list of user stories your product owner and team decide to focus on in the next (or current) sprint.
During sprint planning, the Scrum team will move items they’re going to tackle in the sprint from the product backlog to the sprint backlog.
Product increment (iteration)
A product increment or iteration is a usable version of the product you produce at the end of each sprint. It should meet your team’s “definition of done.”
That could mean delivering complete, reviewed, tested code, or finishing a physical product design for review.
Keep in mind that Scrum and the Agile mindset advise against focusing on outputs. You should always focus on outcomes from the user’s perspective.
Don’t get bogged down with internal documentation.
The sprint: The main event of Scrum
The Scrum sprint is a time-boxed event where the Scrum team focuses only on completing the sprint backlog and delivering a product increment. It is the main event of the Scrum framework.
While sprints can last between 1–4 weeks, most split the difference at 2-week sprints (including here at staging-mondaycomblog.kinsta.cloud).
The average sprint is 2.4 weeks long and the average project lasts about 11.6 weeks or almost 5 sprints.
The sprint goal
The sprint goal is an objective you can complete by implementing the sprint backlog. It’s a combination of user stories that lead to a tangible change in user experience.
For example, the ability to both open, read, edit, and save a file in the mobile app.
Read our dedicated guide to learn more about the sprint goal, the stages of the Scrum sprint, and how to implement it in your company.
The 5 Scrum meetings (ceremonies)
Scrum uses 5 main meetings, called ceremonies, to guide your sprint process through each stage.
The first often happens before you even consider starting a new sprint.
1. Product backlog refinement
In the product backlog refinement meeting, you review potential user stories for upcoming sprints. The product owner, main client, and other stakeholders should participate.
If you maintain a digital backlog, you can separate these into another table of prioritized items.
Then you can expand the individual product backlog item with estimated effort, potential impact, and more.
2. Sprint planning meeting
Your sprint planning meeting is all about selecting the right backlog items for your sprint. The product owner, Scrum master, and all team members attend.
It’s important to let your team members lead the conversations, and select user stories themselves. It’s often split into two parts, first figuring out what to do, and then how to do it.
Using a digital Scrum board can be helpful during the how-to stage. You can expand each user story with work items, assign ownership with notifications, attach docs, and more.
3. Daily Scrum meetings
Daily Scrum meetings, often called daily standups, are daily meetings where you evaluate yesterday’s progress and list your tasks for the day as well as any potential roadblocks.
They only last for 15 minutes, with around 90 seconds per person.
We recommend that even remote teams have them to boost accountability and productivity. The staging-mondaycomblog.kinsta.cloud R&D team uses Zoom to set up meetings every morning during a sprint.
It’s important to follow up based on any roadblocks mentioned in the meeting, and make sure you solve it. The team member who owns the work item should handle this directly.
4. Sprint review
The sprint review meeting is where your customers and other stakeholders actually put your product increment to the test.
Instead of creating a Powerpoint and presenting the changes, the increment should be tested in action by actual users.
What they think of the increment will determine if you can check off the sprint backlog items as done.
5. Sprint retrospective
The sprint retrospective is where your Scrum team takes the time to look back at your sprint and evaluate how it all went.
With our Work OS, you can use the activity log to assess how each user story progressed and identify whether any stage of your process needs improvement.
Read our dedicated guide to learn more about how to use Agile meetings to better manage your projects.
Conclusion
The Sprint Guide is a good introduction to the Scrum framework, but just reading it once isn’t enough.
You need to explore videos and posts and learn from people who have put it into action. Learn from their experiences.
Of course, the best way to learn is to actually create your own Scrum sprint.
With our Scrum sprint planning template, it’s easier than ever to get started.
Get started