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.
Leaders and friends frequently ask about Scrum, and common questions include:
And my answer to these questions has changed some over the years.
By helping individuals, teams and departments implement Scrum, I’ve observed how people learn to practice Scrum.
I use the word “practice” intentionally. Scrum isn’t just a concept to grasp and file away for future use. A solid understanding of Scrum comes from the experience of applying and adapting it over time. When I was first introduced to Scrum, a mentor described it as “easy to learn, but hard master.” I don’t think you can master Scrum without practicing it.
In a complex and uncertain world, Scrum provides habits and processes that allow teams to find focus in the complexity and agility to change when they encounter the unexpected.
So when people ask me how to learn Scrum, I’ve often pointed them to the Scrum guide and encouraged them to pick an area of their life or work where they could apply it. I thought if people learned the basics in a simple context, they could use Scrum in more complex environments.
This approach worked for many people, but there were two common problems:
And this guide is an attempt to bring together both a hands-on and structured approach to learning Scrum. I also wrote it with everyday people in mind because I believe you can apply Scrum across many different contexts.
I’m excited for you to learn Scrum and discover new strategies for designing your work and your everyday life.
You want to do good work that delivers value. But sometimes, it's tough to get good work done. Sure we're all swamped, but at the end of the day, were we able to deliver?
In a complex and uncertain world, Scrum provides habits and processes that allow teams to find focus in the complexity and agility to change when they encounter the unexpected.
So before we dive into the how of Scrum, let's look a little deeper at the why of Scrum.
Who doesn’t live a quick pro and con list?
Pros of adopting Scrum
Cons of adopting Scrum
If you're leading a team where you have to overcome obstacles to reach goals, Scrum can help you get there and deliver results.
Scrum can address three common challenges to enable your team to deliver extraordinary value.
Imagine your boss’s boss comes to you excited about a potential feature for a product assigned to you. You’re uncertain about the value of this feature for the business or client, not to mention you know it will take way more work than they think it will.
It’s easy to imagine because this situation is so common you may feel like I read through your inbox this morning. Let’s look at how Scrum addresses this challenge.
The product owner plays a crucial role in Scrum. They are responsible for defining and prioritizing the work done to deliver value to the business and client. The product owner is the intersection between the team and stakeholders. They continually work with the team to update the prioritization and estimation of work.
Scrum brings simplicity to tackle both complexity and volatility
This prioritized backlog of work to be done is transparent to anyone, creating clarity and visibility about what the team should and shouldn’t spend time on.
We should expect uncertainty; change is inevitable. The past few years have clearly demonstrated this reality. So what do we do? How do we lead? How does the critical work move forward?
Requirements are critical in defining the work to be done. But many times, requirements can be ambiguous or continually changing.
Scrum uses the tools of user stories and acceptance criteria to clarify the requirements and frame them in terms of the end-user. Framing requirements for the user is a game-changer.
Frequent feedback prevents the team from working very long on “what the stakeholder said, but not what they meant.
I’ve had many well-intentioned stakeholders ask for products they would have loved 30 years ago but would be a total miss for our target audience (college students) today. I have to ask, “What do you hope is the impact of this product? What need of the student does it meet, and what action do you hope they will take?”
Scrum has just enough constraints to create clarity around the work to be done, roles and rhythm.
These kinds of questions are core to user stories. As we walk through the process, the light bulb usually comes on, and they are willing to step back from their solution and entrust our team to help creatively solve today’s problem.
Scrum is an iterative process with most of the events commonly occurring on a two-week cycle. These short iterations (sprints) allow the team to receive regular feedback on the work they produce. This frequent feedback prevents the team from working very long on “what the stakeholder said, but not what they meant.”
If the requirements change, work is reprioritized by the next sprint, and the team focuses on what will deliver the most value. The team can adapt quickly to these changes.
I get asked about Scrum a lot. Sometimes, I explain Scrum as a simple framework for tackling complexity by applying a few constraints to empower freedom and creativity. This world is becoming increasingly complex, and so are the projects and products we work on.
It’s tempting to battle complexity with a complex solution, and this becomes more problematic when volatility accompanies the complexity. The complex solution lacks flexibility or resilience and often breaks in an ungraceful way.
Scrum brings simplicity to tackle both complexity and volatility. Scrum doesn’t have a ton of rules and structure, and it has just enough constraints to create clarity around the work to be done, roles and rhythm. These few constraints give the team freedom and flexibility to embrace the complexity and develop solutions.
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 FAQ section.
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.
So much productivity and value are lost when there isn’t clarity, focus or shared understanding. Let’s learn how to increase visibility within your team and across your organization.
You can’t learn, lead, or change what you can’t see. This truth sounds basic, but I frequently see leaders and organizations harmed because of a lack of visibility.
Here are some symptoms of low levels of transparency
As you can see from the list, transparency matters because it highly correlates with clarity and understanding.
When teams or leaders can’t see or don’t understand what others are doing, they don’t have empathy. And without empathy, things break down pretty quickly, even becoming adversarial within the team or organization.
Scrum addresses the lack of visibility through four strategies.
All work in Scrum resides in one of two backlogs.
The product owner is responsible for keeping the product backlog ordered by priority. This backlog is not a secret and is visible to the whole team and organization. The backlog is the one source of truth regarding what’s prioritized.
Transparency matters because it highly correlates with clarity and understanding.
Teams, stakeholders and leaders can see how future work is prioritized. They can come to the product owner if they have questions or concerns.
The sprint backlog includes everything the team selected during sprint planning to focus on during the sprint. So if it’s not in the sprint backlog, it’s not what we’re doing this week.
There is a two-sided commitment with the sprint backlog.
There isn’t ambiguity about what the team should focus on this week. This clear prioritization gives the team a protected space to complete the critical work.
Scrum helps you know where you are through four of its events.
The sprint begins with the product owner sharing the vision for the new sprint and the development team creating an initial plan to reach that vision. The four fundamental questions of sprint planning are:
As the team works through these questions, a sprint goal is set, work is moved from the product backlog to the sprint backlog, and the team verbalizes their initial plan for the sprint.
The Scrum team is self-organizing, which means they have significant freedom to identify how they will solve the problem and deliver the solution.
All these actions create visibility and shared understanding within the team and are transparent to other stakeholders outside the group.
Sometimes called the daily standup, the daily scrum is a brief 15-minute meeting where the whole team checks in. It’s usually structured around each person answering three simple questions.
This simple rhythm of daily check-ins makes the team aware of everyone’s current reality.
But this meeting isn’t just a status update, and it’s not for people outside the team. It is a time for the team to take that shared understanding and further clarify what they need to do next to complete the work they prioritized at the beginning of the week.
When the sprint ends, the team holds a retrospective to evaluate how they are doing as a team. The focus is on the health and functioning of the group.
Here are some questions I like to use:
The retrospective provides clarity regarding how’s our team doing right now. How often have you been on a team where big or small issues went unaddressed for too long.
Imagine being part of a team that keeps short accounts and honestly works through things together to become the best team they can be.
Backlog refinement is a little more about the future, but it provides clarity about what we currently think about the future ;)
This may sound a little silly, but consider how often two people have different ideas about what will be done next or what it will take to do it?
During backlog refinement, the team reviews product backlog items (PBIs) to ensure there is enough shared understanding that the team can take action when they select the PBI in a future sprint.
The backlog is the one source of truth regarding what’s prioritized.
The needed supporting information and resources are identified and visible within the PBI. The team also uses tools like user stories and acceptance criteria to clarify the goal for the PBI and how they will know if it was successful. They will discuss how much work it will take to complete the PBI and measure it using story points.
What’s planned for the next sprint isn’t static, it can still be changed, but the current plan is clear and visible.
Have you ever missed a deadline only to discover nobody noticed? When others don’t see a commitment, it fails to be much of a commitment.
People don't do what you expect but what you inspect.
Louis V. Gerstner, Jr.
There are three factors that Scrum’s approach to commitments increases visibility.
As the sprint ends, the Scrum team gathers with stakeholders to review what they produced.
The product owner will facilitate feedback and accept or reject the work done according to the user story, acceptance criteria and the definition of done. If changes are needed, the product owner can add them to the backlog for the following sprint.
The Scrum team collectively owns their commitments.
Not only are the team's commitments visible at the beginning of the sprint via the sprint backlog, but they are also evaluated with transparency at the end of the sprint.
During backlog refinement, the team works to clarify each PBI to ensure there is clarity regarding what they are committing to if they select the work in a future sprint. When a PBI has been refined, there should be no ambiguity about what it will mean to complete and deliver it.
The Scrum team doesn’t have a “leader.” This reality might be one of the hardest for managers to grasp early in the process. The Scrum team is self-organizing, which means they have significant freedom to identify how they will solve the problem and deliver the solution.
When coaching new teams, we work a lot on moving from I or you to we. It’s no longer I need to get this done, or you made a mistake. It becomes we need to find a way to finish, or we need to correct this.
The Scrum team collectively owns their commitments.
Everything is in a constant state of change, which is why transparency isn’t a one-time event. You need to develop a rhythm and cadence to visibility.
The Scrum events help to create that cadence. Let’s take a closer look at the role each play in transparency.
As you can see, the events in Scrum each play a role in creating transparency. When they occur in sync, they build a cadence of visibility where you can help but evaluate and improve. More on that in a minute.
Whether you’re already practicing Scrum or just considering it, here are three actionable steps to level up transparency.
As we saw earlier, each role in Scrum contributes to creating and maintaining transparency. Do you have people to play these key roles?
Individuals can play multiple positions if needed for a season, but ideally, you work toward having individuals dedicated to a role. The one exception is being both the scrum master and product owner simultaneously. I would not recommend that.
So whether your context is wanting to deliver content consistently or getting home projects done, identify who will play these critical roles.
I’ve provided suggested questions to ask at crucial moments like sprint planning, the daily scrum and the retrospective. You can use them as-is. No need to adapt. But if you want to nuance them a little or add a question, the key is to decide, “these are the questions we’re committing to asking at these times.”
When will this happen? If you want to see an increase in transparency, you must make time for it.
I recommend starting with 1-week sprints because most people's lives already orient around a weekly cadence. So a weekly schedule would look something like this.
Choose your times, create a calendar event, and invite your team.
Now that you’ve taken steps to increase visibility, it’s time to evaluate what you see. From there, you’ll decide what needs to change. This process repeats as you and your team grow in focus and effectiveness.
Now that things are more visible, what do you do with this new transparency?
Just because things are seen doesn’t mean they are understood. Evaluation seems straightforward, but practical evaluation is still a struggle for many teams.
Let’s walk through Scrum’s roles in helping you effectively evaluate.
We often think of evaluation as something we do at the beginning or the end, but it’s more of a continual process.
If you drive to the store, what part of the drive are you evaluating? Is it the beginning, middle or end? It’s the whole time. You are continually observing and assessing the speed and position of other cars, what color the light is, and whether you like the current song on the radio…
All those small evaluations come together to form a responsive and nuanced understanding of your surroundings. For many of us, work is at least as dynamic and complex as driving. Scrum provides a framework that invites the same kind of continual evaluation.
Scrum disarms evaluation by making it so regular
This gives the whole team a much more real-time understanding of what’s happening. This shared and distributed understanding is one of the Scrum team’s superpowers.
The sum of the daily evaluation enables contextualized knowledge that wouldn’t be possible if batched together at a later time. Leading projects or developing products without continuous evaluation is literally like driving with your eyes closed.
Now consider the impact when evaluation cascades across an organization with multiple teams continually evaluating and adjusting. You have the makings of a learning and agile organization.
Just because things are seen doesn’t mean they are understood.
Maybe you’re thinking, “I see how important evaluation is, but it’s not that easy, in fact it can be really difficult.” Let’s take a closer look at how Scrum can help.
Evaluation can be challenging, especially when a team hasn’t developed the habit together. Here are four ways Scrum can help in this area.
If you and I aren’t looking at the same thing, our evaluation will likely be fraught with misunderstandings. As Scrum increases an organization’s transparency making the work more visible, team members begin to see the same things.
Leading projects or developing products without continuous evaluation is literally like driving with your eyes closed.
The increased awareness allows the conversations to move more fluidly, and the shared ownership invites everyone to engage. The subject of evaluation is known to everyone and matters to everyone.
The question shifts from “what should you do about this?” to “what should we do about this?”
Some may disagree with whether or not Scrum over-scripts evaluation. I say it doesn't because while Scrum provides a script, you’re free to change it.
Let’s take the daily standup as an example. Evaluation has a simple script.
Having a script is exceptionally helpful for a team learning the habit. But if, during the retrospective, the team decides to change one of the questions, they are free to do so. Most of the structure Scrum provides is flexible rather than rigid.
What happens the next day if you go to the gym to work out for the first time in a few months or years? You feel it. Muscles you didn’t know you had are sore. Getting out of bed is up for debate, so going back to the gym is out of the question.
But what happens when you push through? How do you feel when you’ve been active and exercising daily for a few weeks? You feel strong, recover quicker, and don’t fear the pain that brings the gain.
Evaluation is never urgent, but it is always essential.
When a team is practicing Scrum, they evaluate every day, usually multiple times a day. At first, this can feel a little overwhelming and teams can resist. But if they push through they begin to strengthen their evaluation muscles.
For many people, evaluation can feel scary because it can be proximate to conflict. But Scrum disarms evaluation by making it so regular. The team's emotional strength and psychological safety increase by practicing evaluation in small and larger batches.
Engaging in evaluation for healthy Scrum teams becomes like a marathoner going out for a light jog.
Allow me to continue the exercise comparison a little longer…
When is the most popular day to work out?
Tomorrow.
It’s always easier to put off running or starting a diet to our well-intentioned future selves. The same is true for evaluation. We think we’ll get to it when we have time, when we’re done.
Evaluation is never urgent, but it is always essential.
Scrum combats this resistance to evaluating by scheduling it for us. The Scrum events make space for the team to assess. It creates moments or even rituals for the team to evaluate without even realizing they're doing it anymore.
Once evaluation becomes a habit, most friction is removed and propels the team forward.
Let’s take a deeper look at how each Scrum event helps to create a cadence of evaluation by looking at the questions they invite the team to answer.
Suddenly evaluation is as habitual as getting coffee in the morning.
And that is the power of Scrum’s rhythm of evaluation. It becomes a habit. Evaluation becomes an automated part of the team’s behavior.
The culture of evaluation on your team won’t change overnight, but taking these three steps, means you won’t wait too long.
When people are doing something new or different, it’s natural to feel unsure if they’re doing it right. That feeling can cause them to hesitate or stop altogether.
Call it out when your team begins practicing evaluation in a new way. It can be as simple as saying something like, “this is really good we’re evaluating _______, this is going to help us continue to grow and get better?”
Naming and affirming new behaviors and gives people the confidence to continue until it becomes a habit.
Practicing something new takes more energy than doing what you’ve always done. Forecast to the team that these new evaluation habits might initially take more time and energy, but they will make us stronger.
Providing a short-term goal or finish line often helps people push through the initial discomfort. You could propose to the team that they commit to these new behaviors for the next 40 days, and at that time, you can evaluate how it’s working.
By the time you get to 40 days, habits will be built, and the team will be able to see the fruit of greater agility.
When you first begin, you’ll probably need to be a little more rigid to build consistency initially. Keep your commitments to evaluation moments and keep the day, time and location the same.
This consistency will allow the team to feel the cadence of evaluation and get in sync with each other. You’ll find them more prepared to evaluate because they know what to expect.
Once things are visible to the team and honestly evaluated, you almost can’t hold back making a change. But there is still both art and science involved in leading people through change.
The world is not static. And change isn’t optional.
What happens when teams or organizations don’t adapt? It’s easy to point to the big ones, looking at you Blockbuster, but the same thing happens on a smaller scale each day in almost every organization.
To thrive, we need to see change as normal, not scary. Keeping things the same really is a phantom.
I stopped seeing mistakes as failures and as discoveries about the world.
A personal experience that drove this home for me was when we moved as a family ten years ago. It was a hard decision to make as we had built great relationships in the community. But we knew it was still the right change to make.
Within two years, most of our close friends also moved for various reasons, and it hit me. If we hadn’t changed, life wouldn’t have stayed the same.
As you increase the frequency of adaptation, be aware of the tendency to glorify change to the point that you end up with instability or change for change's sake.
You can’t change everything at once. It becomes too disruptive, and people begin to feel lost and untethered in the transition. It’s also difficult to measure change's impact when you simultaneously change too many things.
Let’s return to the driving metaphor we have looked at already.
Think about how steering works when you drive. You don’t only steer when making turns. You steer continually, constantly making small adjustments as you adapt to the road and the cars around you.
Continuously steering is like the sum of the daily adaptation that, if taken all at once, would be disruptive or impossible for the team. Imagine waiting and trying to make all your right turns at once.
There are moments where more dramatic change is needed, like taking a u-turn. Maybe your environment around you changes rapidly, or your user-testing tells you a significant pivot is needed.
Perfection is not the standard. If you’re not failing much, you’re probably holding yourself and the team back by playing it too safe.
But there is a compounding impact in making small changes over time. Or said another way, take the 1% improvements but be open the to possibility of 100% changes.
1% feels so small, but what if you could implement a 1% process improvement daily. You would see 100% change in just over two months.
The small changes should still connect to the big picture. You can ask the team, “how is this change taking us where we all want to go?”
You have to teach yourself to see adjustments with a long-term mindset. Run the marathon. Even though Scrum calls it a sprint. 🤷♂️
Regular change on its own can be disruptive and confusing. Scrum’s not-so-secret ingredient is that it first normalizes transparency and inspection. Adaption is then just the natural next step.
Transparency creates shared consciousness, a great concept from the book Team of Teams, and contextual awareness that allow teams to make informed decisions.
Learning is always part of the process. And the process takes time.
Continual inspection keeps teams from making changes based too heavily on a singular data point. Instead, the adaptation is based on a nuanced understanding of many influencing factors.
But Scrum’s biggest advantage in adaptation is self-organizing teams.
It’s their decision.
The change isn’t being pressed down on them by leadership. It’s not disconnected from the reality of everyday work. Nor is it disconnected from the overarching goals and objectives of the organization.
The impact of agency and empowerment combined with clear direction is hard to overstate.
Now, with this backdrop, let’s look at each Scrum event through the lens of adaptation.
Going through that list, it’s hard to miss how closely adaptation ties to the other two pillars in Scrum of transparency and inspection.
Learning is always part of the process.
And the process takes time.
As adults, my wife and I moved around the world to work in a new language and culture. We were adapting in every facet of life, facets I didn’t even know were a thing. An unexpected blessing was having young children during that same season.
As we were learning to live in a new way, they were just learning to live in general. Not long after taking their first step, they would fall. When learning to speak, they would use grammar in a hilariously strange way.
Take the 1% improvements but be open the to possibility of 100% changes.
When we watched this in their lives, we knew it was normal and celebrated the journey. But then in my own life, I would be frustrated by not knowing how to do or say something. One day the light bulb when off that I was on the same journey my kids were.
Mistakes were part of my learning journey. I stopped seeing them as failures and as discoveries about the world. I needed the same grace I was extending to my kids. Your team will need this also as you embark on change.
As I look back on those years, I realize they were instrumental in cultivating the empathy and curiosity that later led me to the worlds of UX and agile development.
Without those “failures,” I wouldn’t have grown into who I am today.
So whether it’s your own personal project or your team has made a change that didn’t work out, seize the opportunity to learn from it.
To thrive, we need to see change as normal, not scary.
Not only does inspection inspire adaptation, but it also acts as its safety net. During the next standup or the retro, evaluate what didn’t work and adapt again.
Perfection is not the standard. If you’re not failing much, you’re probably holding yourself and the team back by playing it too safe.
We each have varied tolerances for change, and the team will likely include members who see it differently.
These differences can create some challenges to leading a team through continuous change. Let’s explore three strategies to help you lead your team amidst change.
Have you ever known you need to make a change, but you felt the weight of how much work you’ve already put in holding you back?
It can be challenging to navigate change when you’ve already invested much in the current plan. But if you don’t do anything and keep moving in the same direction, it will only get worse.
Let’s explore the sunk cost fallacy and see how to understand our emotions' impact in this situation.
The workday is over, and you’re swiping through Netflix to find something to watch. You pick a movie you haven’t seen and start watching. It’s terrible. The acting, the plot and the cinematography all leave much to be desired. But you keep watching because you’ve already invested over an hour, and there are only 35 minutes left. This is the sunk cost fallacy.
It's hard to let go when we’ve invested a lot of work, money, or time into something. Even when our mind knows we should cut our losses and move on, our emotions keep us from moving forward.
We like to think of ourselves as intellectual agents making rational decisions, but research has shown that we’re not that different from mice or rats regarding the sunk cost fallacy.
Scrum's short cycles are a powerful defense against the sunk cost fallacy because it limits how much time you invest before discovering a change is needed.
But if you still find yourself in the face of needed change feeling paralyzed by the time and work already invests, here’s another strategy for you.
Name the past and move to the future.
While you can and should learn from the past, you cannot change it. The effort, time, or money you’ve invested is already spent, and taking ownership of this reality is crucial to moving forward.
Sometimes it’s simply saying aloud to the team, “When we started the project, we looked at factors X and Y and decided to do Z, but now things have changed, and Z is not the right strategy for reaching our goal.”
The world is not static. And change isn’t optional.
So often, bringing the truth out into the light disarms all the lies we’re tempted to believe. All of the “you should’ve…” and “if only…” statements shame us into submission and keep us stuck on the same path.
But when you take ownership of the decisions and the outcomes and call them what they are, you can set them down and turn your attention to what’s ahead.
If a larger change occurs, like a merger or reorganization, your team will need extra help navigating the added uncertainty.
You don’t know the future, but you can be clear about what you do know.
During seasons like this, you may add 5 minutes to the standup and address the following points.
This real-time clarity will provide a level of safety for the team to still do courageous and creative work.
But what if you know the new direction but need help facilitating the change?
Change can be tricky, and it's not always clear how to implement it. The book Switch is an excellent resource for understanding how to bring about change, and it uses a metaphor of a man riding an elephant to illustrate three areas to cultivate change.
I find this framework informative when the team considers changes based on our evaluation during the retrospective.
Change is inevitable, and leading through it can be hard, but you’re not alone.
Even as we covered the pillars one at a time, you can see how they naturally integrate and work together.
They act in concert with each other, and you will often find yourself moving fluidly from one to another.
You can think of Scrum as a three-leg stool, with each pillar being a leg. If you remove any of the legs, the stool no longer functions. In fact, it’s likely to hurt someone. Scrum is similar. If you try to practice it without one of the pillars, you will do more harm than good.
The three pillars of Scrum are also complemented by the Scrum values, which include
You can see these values speak to the posture of those on the Scrum team. They describe the attitudes and behaviors of the team.
I said at the beginning that Scrum is easy to learn but hard to practice. It’s easy to learn because it's not overly complicated. And it’s hard to practice because consistently living out the values and pillars requires commitment and maturity.
To experience success for yourself and your team, you must cultivate these values and pillars as you practice Scrum. They are necessary to see a truly self-organizing team grow.
The biggest challenge I see facing teams today is when the values of Scrum don’t match the organization's values. If you’ve cultivated the values in your team, but they are lacking in your organization and its leaders, it will be like planting a healthy plant on your driveway. It will struggle, then wither and die.
This is often an overlooked aspect of the Scrum Master’s role. They should always be working to explain, teach and cultivate an agile mindset and understanding of Scrum in the organization at large.
Now that you understand the foundation Scrum is built upon let’s take one more trip through the roles, events and elements of Scrum, highlighting the pillars and values.
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 help the team practice Scrum by cultivating openness as they reflect how the team is living out the pillars and values.
The Scrum Master will provide coaching or facilitation when needed. They also 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 are constantly inspecting and adapting the work collected in the backlog and the work produced by the team each sprint.
The Product Owner helps the team to commit and focus by setting the sprint goal. 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 constantly inspect and adapt as they transform backlog items into new value each sprint.
The success of Scrum rests on the development team’s courage as they live out the Scrum values.
Learn more about the Development Team role.
Every day, each team member makes their status visible to the rest of the team during the Daily Scrum, also called the standup. The standup 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. They do this by asking the questions like:
Every day the team is essentially adapting to replan the rest of the sprint based on what they discovered the day before. The daily standup requires openness and transparency but provides focus and commitment.
Learn to keep your team in sync with a daily standup.
Every week, the team refines part of the backlog making the requirements and supporting information more visible. During the backlog refinement session, the Scrum team reviews new product backlog items asking questions to clarify the requirements and the goals.
As the team works to clarify the items in the backlog, the product owner will likely make changes to the prioritized order of the backlog. 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 focus on how they will commit to reaching the sprint goal. The team visible moves work from the product backlog to the sprint backlog. They then ask the questions:
They review the work selected for the sprint and make an initial plan that they can adapt via the daily scrum. The team then communicates their plan back to the product owner.
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.
As the team’s finished work is reviewed, the following evaluative questions are asked:
After receiving feedback from stakeholders, the product owner will adapt what is prioritized for the new sprint. Both the completed sprint work and the work the product owner accepts are made visible to the rest of the organization.
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. Evaluative questions might include:
As the team focuses on how well they work together, they create transparency around how their processes and behaviors impact each other. The sprint retro creates space to inspect and adapt, inviting team members to be courageous and identify changes they will make to work more efficiently.
Learn how to facilitate a Scrum retrospective.
Both the product backlog and the sprint backlog are transparent to the team and the organization, creating clarity and openness about both focus and priority. They each contain the definitive list of work to be done. The sprint backlog helps the team maintain focus on the work to be done in the given sprint.
The backlog is continually inspected to refine PBIs for greater clarity. 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. They make future priorities visible both inside and outside the team.
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. The whole team creates and commits to what is in the definition of done. The team respects each other’s commitment to getting their work done.
The team can inspect the definition of done during a retro. 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 organize a PBI’s requirements. They make the end user's needs, motivations, and goals visible. They use the structure.
They keep the team focused on the value they create for the end-user. PBIs are evaluated against their user story during the sprint review.
Learn to write your own user stories.
Acceptance Criteria defines the requirements which must be met for the sprint deliverables to be accepted by the product owner. Acceptance criteria follows a consistent structure of:
Acceptance criteria makes visible what functionality team members are committing to deliver.
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.
Assigning the proper size to work requires open discussion for the whole team.
Velocity measures how many story points a Scrum team completes on average per sprint. This average allows the product owner to forecast transparently when future features will be ready.
Learn to forecast in Scrum using velocity.
The increment is the new functionality or value the team has committed to delivering at the end of a sprint. It is inspected during the sprint review. The increment should be ready to release to the end-user even if the team chooses to wait.
We’ve laid the foundation of why Scrum is necessary and what Scrum consists of. Next, we’re going to dig deeper into how to practice Scrum by looking at its application across various contexts.
Now that we’ve covered the essentials that make Scrum effective let’s dig into how to really practice Scrum.
Perhaps you have heard about Scrum but still aren’t sure if it will work for you. Much has been written about practicing Scrum in a software development context, but there is so much opportunity to apply Scrum in non-software projects.
It can be challenging to translate Scrum to a new context. What stays the same? What changes? I wrote this guide to help you navigate the art of applying Scrum.
And this is why we began with a focus on the pillars and values of Scrum. Because they don’t change with the environment or context.
If you don’t understand them, you will struggle to apply Scrum in typical situations. But when you have a firm grasp of these essential principles, you can creatively adapt Scrum to an assortment of circumstances.
I’ve used Scrum to lead creative media teams, branding projects, content creation, personal growth, and even homeschooling my kids. These are three reasons I believe Scrum applies broadly.
As we’ve seen, Scrum is a relatively simple framework. Some roles, events, and elements are critical, but there’s a lot of flexibility around implementing them.
Either way, Scrum doesn’t prescribe you a schedule, but it forces you to create one.
Each day, work progress is evaluated, and the next steps are clarified. This rhythm allows the team to shift and adjust as needed.
At the end of every sprint, during the retrospective, the team evaluates how they are working, where they can grow or what might need to change.
You don’t have to get it perfect in the first sprint.
Evaluation is woven into the rhythm of Scrum. This cadence allows new teams to quickly adjust as they discover how Scrum can best serve them in their context.
You should feel a huge relief knowing you don’t have to get it perfect in the first sprint. Getting started is vital. As the team works together, they can adapt as they grow.
While there is flexibility in how you arrange your Scrum schedule, you want to have enough consistency to create a cadence in your practice of Scrum. There is a definite rhythm and cadence to Scrum that most teams find very helpful.
Every kind of work benefits from clarity and focus. The Scrum rhythm provides clear expectations for:
The events of Scrum each have a specific and clear purpose, and there are no meetings just for meeting's sake.
Scrum may not work great on every project, but don’t be afraid to try applying to a new space just because you haven’t heard of someone doing it before.
Let’s look at some specific examples, and then we’ll cover steps and principles for applying Scrum to a new context.
While you probably could try and apply Scrum to any type of work, there are some places is it will thrive and others where it will feel forced or even detrimental.
Scrum takes an incremental and iterative approach, and this approach shines in uncertain or changing environments.
If your work requires everything to be known before you begin, applying Scrum will likely feel forced. Constructing a bridge requires a commitment to finish according to the original plans and not change course halfway across the river, and it’s probably not going to be a good project for Scrum.
However, most projects these days are not this rigid.
If your work involves creating some kind of product or service, it will feel more natural to apply Scrum. Fields like media production or copywriting can be good examples.
But even if your work is less product or service-oriented, remember that Scrum is about maximizing the value delivered.
So if you lead a finance team, you could use Scrum to help your team continually evaluate what work needs to be done each sprint to deliver the most value to the organization and your customers.
Scrum assumes and really requires a collaborative team, as the whole team owns the completion of work in the backlog. There is an intentional shift from I to we as a team learns Scrum.
You will want to evaluate the current level of trust in your team. Adopting Scrum might be more than the current team dynamics could handle if it's shallow.
Even on a healthier team, the shift can be difficult at first but usually results in greater trust and collaboration than there was before.
Here are a couple of other team-related considerations:
I’m continually experimenting to see how Scrum can help me and others get essential work done. Here are examples where I’ve applied Scrum to different kinds of projects.
Are you ready to give it a try and apply Scrum to your work and your team? Remember, you don’t have to try to get it perfect the first time. Each sprint, you will grow and get better.
Let’s look at a few steps to get started
Look back at the previous section to assess how Scrum will fit your team and type of work.
You will also want to consider your leadership and the teams around you. When you begin to work differently, they will notice, and you’ll want them to understand and align with these changes.
The good news is Scrum isn’t overly complicated, but the bad news is most resources were written assuming the context of software development. This is why I created this guide to teach you the transferable essentials of Scrum.
When I took on implementing Scrum across a creative department with four different creative teams, I encountered some resistance to using it for video. One leader came and told me they had googled “Does Scrum work for video production” and read an article saying it doesn’t, so we would need to do something else.
So aside from being wary of “I read this on the internet” advice, I was also pretty confident Scrum could work for video production. But the reality was that I hadn’t done it yet, and I didn’t know anyone personally who had.
So I went to LinkedIn and searched for “Scrum and Video Production” and began reviewing people’s profiles to see if anyone seemed to have the experience I was looking for. I messaged a few of the people I found using the following message.
Hi ______. I’m a Scrum Master in the creative department of a large non-profit. This year is my first time applying Scrum to the work of video production, so I began looking for examples of others who have done this before.
Looking at your profile, it seems like you have experience and expertise in this area. I’d love to connect if you’re willing to give some guidance to someone earlier in the journey of applying agile/scrum in the area of video.
Not everyone responded, but a few did, which was all I needed. It was so helpful connecting with someone who has already been down the road I was on.
Don’t be afraid to reach out. Most people are excited to help.
If starting Scrum still feels like too much, try using a Kanban board to organize your team’s shared work. It will increase awareness of what the team is working on. You could then introduce retros inviting the team to explore how to grow.
You don’t have to have it all figured out before starting. You may need some help getting your team initially oriented but start with the expectation that you’ll learn a lot in the first few sprints and make necessary adjustments.
So you’re interested in Scrum and may be wondering how you get the rest of your team on board.
There are several approaches to take when onboarding others to Scrum.
People learn in different ways, so using a combination of methods is recommended.
Hands-on learning provides quick insights and memorable experiences to help your team onboard to Scrum.
Here are five facilitation exercises you can use to teach Scrum.
This simple exercise tests a team's understanding of the Scrum roles. It’s best used right after teaching about the Scrum basics
Divide a whiteboard or table into three sections based on the roles of Scrum Master, Product Owner and Development Team.
Write the following responsibilities on sticky notes and have the team assign them to the proper role discussing their reasons as they go. Some responsibilities belong to multiple roles, so you will write them on different notes.
You’ll need three sets of battleship for this fun exercise. Divide the group into six teams and spread them across three games of battleship.
Here’s the catch. One team in each pair has to plan ten moves ahead. They can’t change the planned moves; after their 10th turn, they plan an additional 10.
The other team follows normal gameplay selecting a move during each turn.
After the games finish, have the teams debrief the experience.
The purpose of the exercise is to allow the team members to experience the benefits of a more agile approach.
Imagine you are developing a fictitious cooking app and need to size items in the backlog. On this Miro board template, you’ll be able to work through this and the following two exercises.
Explain that your team is building a recipe app. They need to organize the tasks by how much work they will require. Keep all the tasks hidden and reveal them one at a time. Team members will take turns sizing one task at a time. Each person gets 1 minute to size a task.
This process repeats, cycling through team members and tasks.
After about ten tasks, allow team members the option to either pick a new card or move an old card to a new column. If they use their turn to move a card, they must explain it to the group.
If all the cards have been placed, team members can either move a card or pass if they feel all the cards are in the right place. Once everyone passes in a given round, the game ends.
Ask the team for observations about the activity.
The beginning is difficult without a reference story. Work through these questions with the team.
You'll be ready to tackle the same challenges with your real-life projects when you finish.
Just like kids in the back of the van, stakeholders have a habit of asking, “Are we there yet?”
This exercise will teach your team how to quickly and accurately answer that question.
The group is given a list (backlog) of features for a cooking app. The list is prioritized in order, and all tasks have been sized.
In the past three 1-week sprints, assume your team has completed tasks adding up to 12 points, 14 points, and 15 points. We will estimate the team's velocity by averaging those weeks at 14 points a sprint.
Have the group draw lines on the list to group tasks into future sprints based on the current velocity.
The lines will divide the tasks into groups with no group containing more than 14 points.
After completing the exercise, work through these questions:
Things change. And you need to deliver something sooner than planned. How does Scrum allow for that kind of adjustment?
This next exercise allows the team to practice making the kind of adjustments real life demands.
You've learned that Samsung is releasing a smart fridge and wants to promote your app. This is a great marketing opportunity. However, it means the smart fridge integration needs to be available by the end of the 7th sprint rather than the 15th.
To meet this deadline, the backlog needs some pruning.
Have the team move features from the backlog over to the tree.
If the feature must be implemented before releasing the app for Samsung to promote, place it below the red pruning line.
If the feature can wait and be implemented soon after, place it above the pruning line.
The two significant advantages of written materials are:
Because Scrum invites teams to think and act in new ways, it often takes time for people to feel confident with the concepts. Three sources for written material I recommend include
I decided to write this guide after numerous leaders asked me, “Is there something I could read that would help me understand how Scrum works?”
A lot of instruction out there focuses on all the meetings, roles and elements of Scrum to get you practicing quickly.
I focused on the pillars and values of Scrum first because if those are understood and embraced, a team or organization has a good chance of success in implementing Scrum. If there is a mismatch between the values of Scrum and the values of the organization, it really won’t matter how well anyone understands Scrum.
This guide is truly designed to help people understand the core concepts of Scrum and how to apply them in the various contexts of life.
I recommend using this guide with leaders to focus your discussion on how the pillars and values compare with the organizational culture.
For now, this guide is primarily available online, but I’m hoping to publish it digitally (and maybe in print) early next year.
There is something nice about turning the pages back and forth, underlining critical ideas as you learn new concepts. So if you’re looking for a hold-in-your-hand kind of resource, here are two I would recommend.
Both Scrum Alliance and Scrum.org offer extensive resource sections. They can be a little intimidating to navigate through, but there is a lot of information freely available. If you wanted to build your own learning path for team members, you could probably build something using resources from these sites.
Depending on the scale at which you want to role out Scrum, providing formal training and instruction for teams can also be a practical approach.
There is a multitude of organizations that offer training for becoming a Scrum Master or Product Owner. These tend to be rather expensive and overly focused on the details of Scrum rather than the practice of it.
If you’re looking for more of an overview of Scrum, I recommend looking on LinkedIn Learning and Skillshare for options. Both have various options and are subscription based, so if you don’t like one course, you can flip to another. Skillshare will give you a free month, which is plenty of time to knock out a course or two.
I’m currently working on intro courses to both Agile and Everyday Scrum. You can signup to be notified when they launch next year.
While Scrum isn’t overly complicated; it’s not something you implement overnight. It takes time for behavior to change, mental modals to adapt, and culture to shift.
There will be difficult moments along the journey. Moments of truth where the people, the team and the organization must decide if they’re really in. There will also be many decisions and questions, usually regarding if you’re doing it right.
In any new venture, we benefit by learning from those who have gone before us. Scrum is no different.
A coach can help significantly in these moments. They provide experience and perspective to navigate the process.
Maybe you’re wondering, “where do I find a coach?” There are a few places to look when searching for a Scrum coach.
Everyday Design. Ok, a slightly shameless plug here, but I’m offering a handful of free coaching appointments each month.
Leaning Scrum for the first time can be overwhelming. There are many new concepts and terms in Scrum. And you may be thinking:
I have so many questions about Scrum I don’t know where to start.
Well, we’re here to help. Below you will find a list of frequently asked questions about Scrum. Search, browse, go on a rabbit trail…
Wherever this FAQ takes you, I’m excited for you as you begin this journey of learning about Scrum.
There’s a lot. You may even feel like you don’t know what you don’t know. That’s ok. This guide will walk you through learning scrum.
Clicking on any of the questions to take you straight to the answer. Or you can scroll down and see them by category.
Now for all the questions. Each question will link you to more resources. You can dive deeper or keep rolling through the list for more.
Scrum is founded on three essential pillars leading teams to ask the following questions:
Further explore the definition of scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
This is because Scrum’s simplicity makes learning easy, but Scrum truly changes how you work, and that adjustment can be difficult. It changes power dynamics and expectations within the team and between the team and the rest of the organization.
You can explore further is Scrum hard to learn, along with the pros and cons of Scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Scrum was initially used as a term related to project management in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in their paper “New New Product Development Game” In the Harvard Business Review. The first recorded Scrum project came a little later in 1993 from Jeff Sutherland.
You can learn more about Scrum’s backstory. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Learning Scrum for the first time can be overwhelming. There are a lot of new terms and concepts in Scrum. I’ve listed the most common terms in a Scrum glossary.
It forces clarity and prioritization, which provides the focus necessary for teams to be effective. Scrum embraces complexity and change by keeping many things simple and iteratively evaluating and adapting.
You can learn more about why to use Scrum and three challenges Scrum solves. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Scrum isn’t always the best option for teams. Scrum can fail when there is a substantial mismatch between organizational culture and the Scrum values. It also depends on the nature of the work you do. If you work if very linear, predictable and tightly defined, you may not experience many benefits Scrum provides.
Find out more about aligning your organizational values with Scrum or how Scrum might fit in your context. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Scrum functions at its best when you have a dedicated team focused on developing a singular product. Its agility shines when there are time constraints combined with uncertainty.
Explore the pros and cons of Scrum along with expectations vs. realities with Scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Important factors include your team size and the type of work you do. Kanban is very process-oriented, so you should consider how defined, static, or long your process is?
You can explore Scrum and other agile approaches. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Scrum forces clarity and prioritization, which are critical to organizational effectiveness. It provides a competitive edge by allowing teams to adapt as the market or priorities change. Teams operate more effectively because Scrum combines empowerment of the team members with alignment to top priorities.
Learn more about scrum’s impact on organizational culture. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Scrum is more of a framework than a methodology, and it helps teams adhere to Agile principles and get stuff done. Scrum provides basic rules but doesn’t prescribe how to do the work. It provides principles, values, rules, and some core structure but still leaves a lot undefined.
Learn more about scrum as a framework. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
When people say “agile,” they usually refer to it as a mindset. Scrum is a framework for how to organize people and work in an agile way. If you’re practicing Scrum, you’re working in an Agile way.
Learn more about the relationship between scrum and agile. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
The scrum team is made up of the product owner, scrum master and development team. They each play important roles.
Learn more about how a scrum team works together. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Project managers and scrum masters differ in where they focus and what they emphasize.
The project manager is focused first on the work. Does the project have everything it needs to get done? The scrum master is focused first on the people. Are they the best team they can be to get projects done?
Continue learning about the relationship between a scrum master and a project manager. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
This combo is very doable, but it depends on the person. Some people are great team contributors but are not good scrum masters.
Often, people suggest the type A personality to be the Scrum Master because they seem like the typical leader type. Unfortunately, what usually happens here is that person begins to act like the team's boss, which is not the role of the scrum masters.
Learn more about the roles of a scrum team. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
With less than three, you don’t get much of the benefit of collaboration or shared momentum. More than nine, and the logistics of coordination start to eat away at the benefits of coordination.
Learn more about how a scrum team works together. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
There are three roles in Scrum:
Learn more about the scrum roles. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
You really can’t run Scrum without a product owner or scrum master, so someone will likely have to wear multiple hats. Here are some recommended combos:
A combo you want to avoid is being both the Product Owner and Scrum Master at the same time.
Learn more about what to do if you don’t have all the scrum team roles. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
A scrum team has stakeholders on two sides.
Success depends on identifying and serving the goals and motivations of both groups of stakeholders. The product owner is responsible for harmonizing and prioritizing the needs of both.
Learn more about the different scrum roles. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Often an agile coach serves as someone who can come in from the outside to help an organization evaluate their practice of scrum or implement it for the first time.
An agile coach should also have competency around agile practices beyond just scrum.
Learn more about the roles in scrum or the difference between scrum and agile. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
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 more about the roles and responsibilities of a scrum master. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
A servant leader puts others’ needs first. The Scrum Master provides the team with guidance and direction (where and why, but not what and how). This approach allows the team to work with a healthy level of autonomy and agency and ensures they have the mastery and purpose needed to do their work.
Explore what it means to be a scrum master. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
They act as a mirror helping the team see where they are and how things are going. The scrum master protects the team’s health by balancing the product owner’s drive to complete the product with the team's long-term effectiveness.
Learn more about the role of a scrum master. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
A scrum master can definitely be remote, but with a caveat. This situation works best when the whole team is distributed. The scrum master's effectiveness will decrease if the rest of the group is co-located and they are the only remote member.
Explore what it means to be a scrum master. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
This combo is possible, depending on the experience of the teams and the frequency of obstacles you need to help remove. I’ve been the scrum master for two brand new scrum teams simultaneously. It was a bit more work at first because so much teaching was going on, though it eventually leveled out once the teams learned their new rhythm.
Learn more about what to do if you don’t have all the roles for a scrum team. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
If you could look at their calendar, you would probably see things like
Learn more about what it means to be a scrum master. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
The scrum master helps remove obstacles, such as
The Scrum Master advocates for the team's needs and works to resolve the obstacles so the team can focus on producing the highest value possible.
Learn more about how the scrum master removes obstacles. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
The scrum master doesn’t tell the team what to do. Nor do they solve the problems assigned to the Scrum team. But they play a critical role in helping the team identify the problem and create solutions. A scrum master does this through facilitation and practices.
Find out how a scrum master is a coach. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
They act as a mirror helping the team see where they are and how things are going, and they cultivate a space for the team to adjust based on what they see.
They help the team remove obstacles such as unclear requirements, interpersonal conflict, organizational impediments, and dependencies on other teams. This support allows the team to work with a healthy level of autonomy and agency and ensures they have the mastery and purpose needed to do their work.
Learn more about the role of a scrum master. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
The two roles balance each other, thus placing you in tension with yourself. You you hold both roles, you must be mindful of how you communicate with the development team. Holding both positions can also impact how much agency the dev team feels they have.
Learn more about playing both roles of scrum master and product owner. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
They help remove obstacles such as unclear requirements, interpersonal conflict, organizational impediments, and dependencies on other teams.
Find out more about how the roles on a scrum team work together. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
The product owner works with the scrum master to look ahead to future sprints, evaluating significant milestones to ensure they deliver critical features on time. They also check to see if the work needed to get there matches the capacity or velocity of the team.
Find out more about how the roles on a scrum team work together. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
The product owner products the product vision by balancing the needs of both the business and the customer. The scrum master protects the team’s health by balancing the product owner’s drive to complete the product with the team's long-term effectiveness.
Keep exploring the relationship between the product owner and the scrum master or you can look over the role of the product owner and the role of the scrum master.
Then browse the most common terms in a Scrum glossary and learn what is Scrum.
The scrum team includes the following roles
Either the scrum master or the product owner can also be part of the development team. However, it’s not recommended for the scrum master and product owner to be the same person.
Learn more about the roles and responsibilities of a scrum team. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
They serve as the inflection point between the development team and stakeholders. They set the vision for the product and prioritize all product-related work.
Learn more about the roles and responsibilities of a product owner. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
They accomplish this goal through 5 habits:
Learn more about what it looks like to be a product owner. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
They are fully focused on the product, owning the whole together. They collaborate tightly with each other to transform the product vision into reality. The team should contain all the skillsets needed to develop the product. As a self-organizing team, they have significant autonomy to decide how to get their work done.
Learn more about the roles and responsibilities of the development team. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
They don’t report to the scrum master or product owner. The team has significant freedom to identify how to solve the problems and deliver the features which the product owner has prioritized
Learn more about self-organizing teams.
Explore further how a scrum development team works. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Scrum has been applied extensively to software development over the years, but it is not inherently limited to this space. You can apply scrum with a marketing team, a creative media team, a blogger or even homeschoolers.
Learn more about what it means to be part of a scrum development team. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Each day the team meets for a daily standup to share progress, obstacles and plan the current day together. From there, they collaborate to do whatever is necessary to deliver the required value.
Learn more about the roles and responsibilities of the development team. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
The rhythm of scrum consists of various events.
The last on the list is sometimes debated as to whether or not it’s actually a scrum event. I include it because it's critical to creating a cadence of work for the team.
Learn more about the rhythm of scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Most scrum events are timeboxed relative to the length of the sprint:
Just because an event has a timebox doesn’t mean it needs to be that long. The timebox is the maximum time allowed for the event.
Learn more about the different scrum events. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Scrum events are generally held in the following order
The backlog refinement session is unique in that it can be held anytime.
Explore further the events of scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
I included this because it is frequently asked, but the question misunderstands the importance of the scrum events. It’s like asking which of your limbs is most important. You may be able to answer, but they are really all critical.
If pressed for an answer, the daily scrum probably has the greatest impact on the team's effectiveness.
Learn more about the events in scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Here’s a quick agenda
Learn more about how to facilitate sprint planning. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Think of scrum as a relay race, with each sprint being a lap. The scrum team hands off the “baton” of finished work to itself in the next sprint.
Learn more about the role of a sprint in scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
The sprint isn’t always included in the list of scrum events. I include it because it's critical to creating a cadence of work for the team. The sprint serves as a container for all other scrum events.
Learn more about sprints in scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
The sprint backlog is created during sprint planning as PBIs (product backlog items) are moved from the product backlog to the sprint backlog.
Learn more about the sprint planning process and then explore the most common terms in a Scrum glossary.
The Daily standup is a brief 15-minute daily check-in for the Scrum team to do three things:
It’s called a standup because it’s so short you don’t need to sit down.
Learn how to keep your team in sync with a daily standup. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
During the backlog refinement session, the team previews upcoming work to ensure the following:
There is flexibility for when to hold the backlog refinement session.
Learn more about how to run a backlog refinement session. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Various stakeholders and subject matter experts from across the organization attend to give feedback.
Learn how to run a sprint review. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
The tone is positive and productive, focused on improving the team.
Three strategies for a compelling retrospective include
Learn how you can facilitate a scrum retrospective. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Scrum events have a clear purpose and agenda but are still very interactive. Facilitation of scrum events is at its best when everyone is engaged, asking or responding to questions. All events are timeboxed, so the facilitator must ensure the team is always moving toward the goal.
Learn more about team member's responsibilities during scrum events. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Three strategies for increasing participation in scrum meetings are
Learn more about everyone’s roles and responsibilities during the scrum events. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Scrum cultivates shared ownership for all the events, but each still has a facilitator.
Learn more about everyone’s roles and responsibilities during the scrum events. Then explore the most common terms in a Scrum glossary and learn what is Scrum.
The scrum master primarily facilitates two scrum events:
The scrum master can help facilitate other meetings while a new team is beginning to learn scrum.
Learn more about roles during scrum events. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
The product owner is required to attend the following scrum events:
They are not required to attend the daily standup, though it is still highly recommended.
Learn more about who attends each scrum meeting. Then explore the most common terms in a Scrum glossary and learn what is Scrum.
Understand the purpose of the scrum meetings. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Inspection and adaptation (along with transparency) are pillars of scrum, so all events involve them.
Learn more about the role of events in scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Process improvement aligns closely with the scrum pillars of transparency, inspection and adaptation.
Out of all the events, the retrospective is the most focused on process improvement.
Learn more about events in scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
The scrum of scrums is an extra scrum event used when multiple scrum teams are collaborating together on a single product. The session allows the teams to update each other on what has been done, what obstacles have been encountered, and what to do next. The scrum of scrums follows a similar pattern to the daily scrum session.
To learn more explore the most common terms in a Scrum glossary.
Scrum is founded on three essential pillars, and each leads the team to ask a critical question.
Learn how to apply the three pillars of Scrum and then explore the most common terms in a Scrum glossary.
There are five values critical to the practice of Scrum: commitment, courage, focus, openness, and respect.
Learn how to align Scrum values with your organization and then explore the most common terms in a Scrum glossary.
The sprint goal encapsulates the product owner’s vision into a concrete statement for the development team to measure the sprint against. The sprint goal provides a theme for the sprint’s work helping the team see how all the parts come together.
Learn more about the role of the sprint goal in scrum and explore the essential Scrum glossary.
The definition of done is a list of what must be true to consider a PBI done. The whole team creates and agrees to what is in the definition of done and is updated as needed for the team to function effectively.
Learn to use the definition of done and explore acceptance criteria vs definition of done.
It is the next complete piece added to build the product. The increment is complete in the sense that it should be ready to release to the end-user even if the team chooses to wait.
Learn more about incremental and iterative development or explore the essential Scrum glossary.
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 and check out the sprint backlog vs product backlog in Scrum.
The product backlog prioritizes the features needed in the product. It is a singular visible source of requirements for the product.
The sprint backlog represents the work to do in a given sprint. It is a definitive list of all the scrum team is being asked to produce for the sprint.
Learn more about the sprint backlog vs product 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 gets refined during the backlog refinement session, and if one is too large, it may be broken down into smaller PBIs.
Learn more about how backlogs are used in scrum, the sprint backlog vs product backlog in Scrum and explore the essential Scrum glossary.
They aren’t absolute measurements like hours or days but measure the amount of work a PBI takes relative to other PBIs. Typical measurements include using Fibonacci numbers or t-shirt sizes.
Learn to use story points and explore the essential Scrum glossary.
In Scrum, you are not measuring work in absolute terms like hours spent or lines of code to be written. Two reasons for this:
The problem with absolute sizing using hours is you begin to measure the people, not the work. Relative sizing measures the new work against past work shared by the whole team. Instead, the work is sized relative to past work already completed. So when looking at a new user story, the team asks, “Is this user story A most similar to this past user story B or this past user story C?”
Learn other essential Scrum terms.
The Fibonacci sequence is the go-to solution for many Scrum teams because it allows for relative sizing while still being a numeric measurement. It has two key advantages:
Non-numeric options are still possible, and one of the most popular is using t-shirt sizing, like small, medium and large. Lean more about using story points or learn other essential Scrum terms.
This measurement allows the product owner to forecast when future features will be ready. It is calculated by averaging how many points the team has complete over the past few sprints.
Learn to forecast in Scrum using velocity and explore the essential Scrum glossary.
Are you looking for a challenge to motivate yourself to learn scrum better? Are you looking to land a specific job?
If you just want to take the next step in learning, the PSM has a low barrier to entry and should open some doors to allow you more opportunities to practice the scrum master role.
If you’re trying to land a job then it really depends on what that job is looking for certification-wise.
Here is my experience with certifications as a path to growth.
Want to learn the essential Scrum terms.
The most common certifications for a scrum master are:
The CSM is more common than the PSM but also more expensive. Both offer multiple levels of certification.
You are required to take a class by a certified instructor for the CSM, which will cost you around $1,000. The CSM course includes the test cost and is comparable in difficulty with the PSM test.
The PSM recommends but doesn’t require a course. So you can take the self-study route and then take a cheaper test ($200). This level of affordability can make the scrum.org certifications a more attractive first step for people exploring scrum certifications.
Here is my experience with certifications as a path to growth.
Also be sure to check out the essential Scrum glossary.
The best way to learn to be a scrum master is through practice. However, earning a certificate can provide helpful instruction, and some companies list it as a requirement for scrum master roles.
If you're entering the world of scrum or trying to transfer your skills from one domain to another, having a certification like the CSM can help you get in the door.
Here is my experience with certifications as a path to growth.
Want to learn the essential Scrum terms.
Unlike the PMP (Project Management Professional), most scrum certifications don’t require experience. There are pros and cons, though. It makes earning the certifications easier but also makes them a little less valuable.
A typical CSM course will last between 3 and 5 days, depending on how much instruction is done each day. The PSM doesn’t require a course, so if you already have a solid understanding of scrum, you can just take the test today.
To really be a Scrum Master your'e going to need practice.
Here is my experience with certifications as a path to growth.
Want to learn the essential Scrum terms.
Scrum certifications are a great way to both grow and demonstrate your knowledge. The most common certifications for a product owner are:
The CSPO is more common than the PSPO but also more expensive. Both offer multiple levels of certification.
You are required to take a class by a certified instructor for the CSPO, which will cost you around $1,000. There is no test for the CSPO. Completing the class earns you the certification.
The PSPO recommends but doesn’t require a course. So you can take the self-study route and then take a cheaper test ($200). This level of affordability can make the scrum.org certifications a more attractive first step for people exploring scrum certifications.
Here is my experience with certifications as a path to growth.
Also be sure to check out the essential Scrum glossary.
Like becoming a scrum master, the best way to grow as a product owner is through practice. The CSPO class is helpful as it provides several practical facilitation techniques.
I’ve seen it listed as a requirement for various product owner or product manager roles. It can be beneficial if all other things are equal, but I don’t think it’s a game-changer for landing a PO job.
Here is my experience with certifications as a path to growth.
Want to learn the essential Scrum terms.
If you’re looking for your first scrum certification, the CSM and CSPO are the most common. Both require you to take a class by a certified instructor and cost around $1,000.
Here is my experience with certifications as a path to growth.
Want to learn the essential Scrum terms.
The CSM and PSM are the two most common certifications for a scrum master:
The CSM is more common than the PSM but also more expensive. Both offer multiple levels of certification.
You are required to take a class by a certified instructor for the CSM, which will cost you around $1,000. The CSM class includes the test cost and is comparable in difficulty with the PSM test.
The PSM recommends but doesn’t require a course. So you can take the self-study route and then take a cheaper test ($200). This level of affordability can make the scrum.org certifications a more attractive first step for people exploring scrum certifications.
Here is my experience with certifications as a path to growth.
Want to learn the essential Scrum terms.
The PMI-ACP is in its own class regarding scrum certifications. It requires both documented experience as well as knowledge across multiple agile domains.
The test is long and comprehensive. I would place it as similar difficulty to the PMP as compared to the CSM or PSM.
This certification certainly demonstrates much higher agile and scrum competency. However, I don’t see it listed often on job requirements.
Here is my experience with certifications as a path to growth.
Want to learn the essential Scrum terms.
The PMP is kind of the grandfather of project management certifications. It’s a beast of a test and requires memorizing a ton of information. However, it’s rooted primarily in waterfall rather than agile approaches.
Unless you plan to work in a domain where waterfall is dominant, the PMP probably isn’t the best certification option for those getting started in project management, and certainly not for those getting started with scrum.
Here is my experience with certifications as a path to growth.
Want to learn the essential Scrum terms.
They keep the team focused on the value they create for the end-user and are written using the following format:
See examples of user stories to learn to write your own and explore the essential Scrum glossary.
Acceptance criteria is written using the following structure:
Learn more about how acceptance criteria is used in Scrum and explore the essential Scrum glossary.
I started using acceptance criteria in Scrum, but it’s an effective tool in any project management framework. For any task assigned to a team or individual, acceptance criteria can clarify what new functionality will exist when the task is completed.
See examples of acceptance criteria or learn other essential scrum terms.
A user story focuses on the identity, goals and motivations of the user you’re designing for. It emphasizes the why of the new functionality.
Acceptance criteria focuses on the action taken by the user to meet their goal. It highlights the what of the new functionality.
See more acceptance criteria examples and learn to write acceptance criteria or learn other essential scrum terms.
Acceptance criteria is structured using the template
Here are 3 examples:
Checkout process functionality
Advertising campaign
Marketing campaign (Did you know you could use Scrum for marketing)
See more acceptance criteria examples and learn to write how to create your own or learn other essential scrum terms.
Acceptance criteria is written using the following structure:
Learn more about how acceptance criteria is used in Scrum and explore the essential Scrum glossary.
Acceptance criteria is broken down into three parts.
Learn more about templates for writing acceptance criteria or learn other essential scrum terms.
A user story focuses on the identity, goals and motivations of the user you’re designing for. It emphasizes the why of the new functionality.
Acceptance criteria focuses on the action taken by the user to meet their goal. It highlights the what of the new functionality.
See more acceptance criteria examples and learn to write acceptance criteria or learn other essential scrum terms.
Acceptance criteria is specific to an individual task, but the definition of done applies to all work done by a team. Acceptance criteria answers the question, “What will be true when this task is completed.” The definition of done answers the question, “What are we committing to do every time we complete a task?”
See more examples and learn to write acceptance criteria or learn other essential scrum terms.
Strengths-based growth doesn’t encourage you to ignore your weaknesses but not to spend too much time trying to turn them into strengths. Instead, you may need to find team members or systems to fill in your gaps.
For some people, their strengths ranked 5, 6 or 7 are almost even. You could also be misattributing a skill or behavior to a specific strength.
Seeing your other 29 strengths can help give you a fuller picture. But initially, someone should focus on further developing those top 5 strengths rather than trying to give attention across the list. Once you have a good grasp on what it looks like to lead from your top 5, it can be helpful to explore the rest of the list.
A talent is your natural way of thinking or behaving. A strength is a talent developed over time through knowledge, skills and practice.
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.
“Getting Started with Scrum” is a content project exploring and explaining the key elements of Scrum. It will launch in summer 2022.
Sign up now, to be the first to get the guide and learn how Scrum works.
stay updated on new guides, designs and courses
