Perhaps you have heard about Scrum but are not exactly sure what it is. Or maybe you know some about it but are not sure how to apply it, especially outside a software development context.
It can be challenging to translate Scrum to a new context. What stays the same? What changes?
This guide will help you navigate both learning and applying Scrum.
We all want to create value amidst challenges of uncertainty and complexity. We all want to do meaningful work that has a positive impact. Scrum is designed to maximize your impact.
The guide we center around the three pillars of Scrum but also cover a wide range of topics like can the Scrum Master and Product Owner be the same person? or can I use Scrum in my personal context?
You can begin working with focus and agility now, before the next unexpected change throws off your team again.
I believe Scrum is best understood through the lens of its 3 pillars and 5 values. I’ll walk through the pillars one at a time and then the values altogether.
But before we go there, let me run quickly through some Scrum terminology so you understand the pieces as we talk about the whole.
The Scrum framework consists of roles, events and elements.
I will not cover them too deeply here because I think it's best to learn Scrum through its essentials (pillars and values). If you want a deeper dive, I’ve included links to posts dedicated to each, and you can also reference the glossary and FAQs.
The Scrum Master is a master of process and an empowerer of people as they focus on maximizing the impact of the development team. They support the team by removing obstacles and representing Scrum to the rest of the organization. Learn about the Scrum Master role.
The Product Owner's primary responsibility is to maximize the value delivered to the product. They take the infinite requests and possibilities and prioritize them for the finite capacity of the team. They serve as the inflection point between the development team and stakeholders. Learn about the Product Owner role.
The Development Team is a self-organizing, cross-functional group that makes up most of the Scrum team. They transform backlog items into new value each sprint. Learn more about the Development Team role.'
Also called the standup, the Daily Scrum is a fifteen-minute meeting where the development team inspects the previous day's work, plans the next day’s work and identifies any barriers to getting things done. Learn to keep your team in sync with a daily standup.
During the backlog refinement session, the Scrum team reviews new product backlog items asking questions to clarify the requirements and the goals. There is flexibility about when during the sprint to have the backlog refinement. Learn how to facilitate a backlog refinement session.
At the beginning of a new sprint, the team meets to discuss how they will reach the sprint goal. They review the work selected for the sprint and make an initial plan they can adapt via the daily scrum. Learn how to do sprint planning in Scrum.
The sprint review occurs at the end of the sprint to inspect the delivered work. Various stakeholders and subject matter experts from across the organization attend to give feedback on the work completed. Learn to run a sprint review.
The retrospective occurs at the end of the sprint, focusing on the whole Scrum team. The tone is positive and productive, focused on improving the team. The team will identify points of growth and action steps to take in the next sprint. Learn how to facilitate a Scrum retrospective.
There are actually two backlogs, the product backlog and the sprint backlog. They each contain the definitive list of work to be done. The product owner keeps the backlog ordered by priority. Learn to use the backlog in Scrum.
Each item in the backlog represents precise work and value to deliver. Often these PBIs are written using both user stories and acceptance criteria. The PBIs are what get refined during the backlog refinement session, and if one is too large, it may be broken down into smaller PBIs.
The definition of done is a list of what must be confirmed to consider a PBI done. Everyone on the team creates and agrees to what is in the definition of done. It is updated as needed for the team to function effectively. Learn to use the definition of done.
User stories are a simple schema to order the PBI requirements around the end user's needs, motivations, and goals. They keep the team focused on the value they create for the end-user. The team evaluates PBIs against their user story during the sprint review. Learn to write your own user stories.
Acceptance Criteria defines the requirements for the product owner to accept the sprint deliverables. It follows a consistent structure of Given that... When... Then... See examples of acceptance criteria.
Story points measure the relative size of a PBI. They aren’t absolute measurements like hours or days but measure the amount of work a PBI takes relative to other PBIs. Learn to use story points.
Velocity measures how many story points a Scrum team completes on average per sprint. This estimation allows the product owner to forecast when future features will be ready. Learn to forecast in Scrum using velocity.
The increment is the new functionality or value delivered at the end of a sprint. The increment should be ready to release to the end-user even if the team chooses to wait.
Now that you’re familiar with some Scrum concepts let's dive into why Scrum works. We’ll start with the three pillar of Scrum.
Scrum is a framework for organizing a team around the work of solving problems. Scrum makes the work more visible, so we can better evaluate and adapt. These three pillars of Scrum are essential to an effective team.
How do we make things more visible?
So much productivity and value are lost when there isn’t clarity, focus or shared understanding. Learn how to increase visibility within your team and across your organization.
Where can we create space to evaluate?
Once things are visible they can be evaluated and we can achieve shared understanding and growth. Learn the tools and habits of effective evaluation.
When do we encourage growth?
Our environment is constantly changing and as leaders, we need to help our people and processes grow and adapt. Learn how to create a culture and cadence of growth.
Leaning Scrum for the first time can be a bit overwhelming. There are many new terms and concepts in Scrum.
Well we’re here to help.