Everyday Scrum

A Guide for Everyday People to Learn Scrum

Everyday people practicing ScrumDesigned by pch.vector / Freepik

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.

Asking about Scrum

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:

  1. Many people prefer a more structured approach to learning and practicing.
  2. Like most literature about Scrum, the Scrum Guide is written with the context of software development in the backdrop.

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.

Why Learn to Practice Scrum?

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.

What are the pros & cons of scrum?

Who doesn’t live a quick pro and con list?

Pros of adopting Scrum

  • Early Progress. Teams can make meaningful progress even when requirements are still being discovered.
  • Flexibility. Because Scrum iteratively organizes the work into sprints, the team can change as needed.
  • Focus. Work only gets added at the beginning of each sprint, allowing the team to focus on what’s a priority.
  • Delivery. The team quickly delivers functional features with the most value by working off a prioritized backlog.
  • User-Centered. The team receives feedback from both internal and external stakeholders by reviewing regularly delivered value.
  • Visibility. Transparency is built into the process allowing high visibility into the work being done. 

Cons of adopting Scrum

  • Scope Creep. Without a clear end to the project, sometimes more gets added than should be later in the project.
  • Scaling. Adopting Scrum across multiple teams can be difficult at first.
  • Fit. Some projects by nature are sequential, and Scrum isn’t best for every type of project.
  • New Meetings. Some people don’t like the idea of daily meetings at first, though this usually changes with time.
  • Team-Driven. This one isn’t a con (it’s actually a strength) unless the team becomes unhealthy. Team health has a high impact on the successful delivery of the product.‍
  • Experience Required. For the team to produce quality work requires a team of experienced professionals.

Why is Scrum essential?

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.

  1. Prioritization: Scrum forces prioritization to happen.
  2. Clarity: Scrum handles unclear or changing requirements.
  3. Complexity: Scrum embraces complexity.

Scrum forces prioritization to happen.

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.

Scrum handles Unclear or changing requirements.

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?

Framing the problem creates clarity.

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.

Working iteratively allows for changes.

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.”

Scrum brings simplicity to tackle both complexity and volatility.

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.

Scrum embraces complexity.

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.

What is Scrum?

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. 

A Brief Overview

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.

What are the Scrum roles?

Scrum Master

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.

Product Owner

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.

Development Team

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.'

What are the Scrum events?

Daily Scrum

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

Backlog Refinement

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.

Sprint Planning

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.

Sprint Review

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.

Retrospective

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.

What are the elements (or artifacts) of Scrum?

The Backlog

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.

Product Backlog Items (PBIs)

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.

Definition of Done

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

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

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

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

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.

Increment

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.

Three pillars 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.

Transparency

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.

inspection

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.

adaptation

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.

How Scrum Makes Things Visible.

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.

Why is transparency essential?

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

  • The overall direction and goals are unclear to most of the team or organization.
  • Two teams are working on the same thing without knowing it or communicating.
  • Team members don’t understand how their work impacts others’ work.
  • Leaders don’t understand what the doers do. 
  • Leaders aren’t aware of the implications of the decisions they make.
  • Teams building products don’t know what the customer thinks about them.
  • Teams building products don’t know what the stakeholders think about them.

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.

How does Scrum make things visible?

Scrum addresses the lack of visibility through four strategies.

  1. Prioritization of value.
  2. Clarity about current reality.
  3. Commitment regarding deliverables.
  4. Cadence of visibility

Scrum helps you prioritize value.

All work in Scrum resides in one of two backlogs.

  1. The product backlog contains all future work for a given product.
  2. The sprint backlog contains all work a team is committed to within a sprint.

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.

  1. A commitment to complete what was selected by the end of the sprint.
  2. A commitment not to add additional work during the sprint.

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 provides clarity about the current reality.

Scrum helps you know where you are through four of its events.

  • Sprint planning
  • Daily Scrum.
  • Sprint retrospective.
  • Backlog refinement.
Sprint planning.

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:

  1. What is the goal for this sprint?
  2. How does that goal make the product better?
  3. What work are we committing to complete during this sprint?
  4. How will we use this week to complete the work?

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.

The daily scrum.

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.

  1. What did I complete yesterday?
  2. What will I focus on completing today?
  3. Where am I stuck?

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.

Sprint retrospective.

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:

  • What did you like?
  • What did you learn?
  • What was lacking as a team?
  • What do you long for on the team?

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.

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. 

Scrum requires a commitment to deliver. 

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.

  1. Sprint review.
  2. Backlog refinement.
  3. Self-organizing teams.
Sprint review.

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. 

Backlog refinement.

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.

Self-organizing teams.

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.

Scrum creates a cadence of visibility.

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.

  • Sprint planning. The team visible moves work from the product backlog to the sprint backlog. The product owner communicates the sprint goal, and the development team responds by communicating their plan for reaching that goal. 
  • Daily scrum. Every day each team member makes their status visible to the rest of the team.
  • Backlog refinement. Every week the team refines part of the backlog making the requirements and supporting information more visible.
  • Sprint review. The work completed during the sprint is visible to any and all stakeholders. What is being accepted by the product owner is also being made visible. 
  • Retrospective. As the team focuses on how well they work together, they create transparency around how their processes and behaviors impact each other. 

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.

3 strategies you can level up transparency and make things more visible.

Whether you’re already practicing Scrum or just considering it, here are three actionable steps to level up transparency. 

  1. Identify the people.
  2. Craft the questions.
  3. Place them on the calendar.

Identify the people.

As we saw earlier, each role in Scrum contributes to creating and maintaining transparency. Do you have people to play these key roles?

  • Product owner.
  • Scrum master.
  • Development team.

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.

Craft the questions.

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.”

Place it on the calendar.

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.

Scrum schedule

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.

How Scrum Helps You Evaluate Effectively

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.

The compounding impact of evaluation. 

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. 

How Scrum enables regular evaluation.

Evaluation can be challenging, especially when a team hasn’t developed the habit together. Here are four ways Scrum can help in this area.

  1. Bringing shared visibility.
  2. Providing structure without over-scripting it.
  3. Strengthening the team’s evaluation muscles.
  4. Creating moments for evaluation

Shared visibility leads to effective evaluation.

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?”

Scrum provides structure without over-scripting it.

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.

  1. What did I complete yesterday?
  2. What will I commit to completing today?
  3. Where am I stuck?

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

Scrum strengthens the team’s evaluation muscles.

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.

Scrum creates moments for evaluation.

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.

The importance of Rhythm in Evaluation.

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.

Sprint Planning

  • What is the purpose of the sprint?
  • How will we get the work done?

Backlog Refinement

  • What value will this feature provide?
  • How much work will it take?
  • What resources or information is needed?

Daily Standup

  • How are we doing? 
  • What progress are we making?
  • What issues are we facing?

Sprint Review

  • Is this useful to the end-user?
  • Does this meet the business needs?

Retrospective

  • How are we doing as a team?
  • Where are we doing well?
  • What do we need to be better?

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.

Three actions you can take to cultivate evaluation on your team.

The culture of evaluation on your team won’t change overnight, but taking these three steps, means you won’t wait too long. 

  1. Make evaluation visible.
  2. Press through the soreness.
  3. Stay in rhythm.

Make evaluation visible.

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. 

Press through the soreness. 

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.

Stay in rhythm. 

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.

How Scrum Helps You Adapt.

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 necessity of adaptation. 

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.

Adaptation is a long-term game of focus.

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. 🤷‍♂️

How does Scrum support teams to adapt?

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. 

  • Sprint planning. The team may have had an idea of how to do the PBIs when they last saw them during backlog refinement. But now, when they have the context of the sprint goal and other work to be done, they may decide to adapt their approach.
  • Daily scrum. Every day the team is essentially adapting to replan the rest of the sprint based on what they discovered the day before. 
  • Backlog refinement. 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.
  • Sprint review. After receiving feedback from stakeholders, the product owner will adapt what is prioritized for the new sprint.
  • Retrospective. The team identifies changes they will make to work more efficiently together. 

Going through that list, it’s hard to miss how closely adaptation ties to the other two pillars in Scrum of transparency and inspection. 

What to do when an adaptation doesn’t work?

Learning is always part of the process. 

And the process takes time.

Learn from the kids

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. 

Live with a growth mindset.

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. 

3 Strategies for guiding your team through change.

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.

  1. Avoid the sunk cost fallacy.
  2. Maintaining current clarity.
  3. Engage the whole person.

Avoid the sunk cost fallacy.

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. 

Maintaining current clarity.

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 is what we know today.
  • This is how it affects our team.
  • This is what we’re going to do.

This real-time clarity will provide a level of safety for the team to still do courageous and creative work.

Engage the whole person.

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.

  • Directing the Rider. The rider represents the rational, logical mind of people. Appealing to the rider is usually the default approach but will have a limited effect on its own.
  • Motivate the Elephant. The elephant represents our emotions; if not properly engaged, it will steamroll our rational plans every time.
  • Shape the Path. How can you change the environment in which the change is being made? Can you make the new behavior extraordinarily easy and the old one difficult or impossible?

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.

Applying all three pillars of Scrum along with the Scrum values.

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 5 Scrum values are critical to the health of Scrum.

The three pillars of Scrum are also complemented by the Scrum values, which include 

  • Commit to achieving the goals of the Scrum Team.
  • Courage to do the right thing and work on challenging problems.
  • Focus on the Sprint's work and the Scrum Team's goals.
  • Open about all the work and the challenges with performing the work.
  • Respect each other to be capable, independent people.

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.

The Scrum pillars and values in practice.

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.

Scrum Roles

Scrum Master

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.

Product Owner

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.

Development Team

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.

Scrum events

Daily Scrum

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:

  • How are we doing? 
  • What progress are we making?
  • What issues are we facing?

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

Backlog Refinement

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.  

  • What value will this feature provide?
  • How much work will it take?
  • What resources or information is needed?

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.

Sprint Planning

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:

  • What is the purpose of the sprint?
  • How will we get the work done?

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.

Sprint Review

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:

  • Is this useful to the end-user?
  • Does this meet the business needs?

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.

Learn to run a sprint review.

Retrospective

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:

  • How are we doing as a team?
  • Where are we doing well?
  • What do we need to be better?

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.

What are the elements (or artifacts) of Scrum?

The Backlog

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.

Product Backlog Items (PBIs)

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.

Definition of Done

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

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.

  • As a…
  • I want to…
  • So that…

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

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: 

  • Given that... 
  • When... 
  • Then... 

Acceptance criteria makes visible what functionality team members are committing to deliver.

See examples of acceptance criteria.

Story Points

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.

Learn to use story points.

Velocity

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.

Increment

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.

What’s Next?

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.

Applying Scrum to Different Kinds of Work.

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.

Why Scrum works for non-software projects.

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.

  1. Scrum doesn’t prescribe much.
  2. Scrum invites evaluation and adaptation.
  3. Scrum creates a rhythm of work.

Scrum doesn’t prescribe much.

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.

  • If your team is small or just you, you can combine roles
  • If the environment around the work is volatile, you can have short one-week sprints
  • If the environment is more stable and the work progresses slowly, you could choose a two or three-week sprint. 

Either way, Scrum doesn’t prescribe you a schedule, but it forces you to create one.

Scrum invites evaluation and adaptation.

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.

Scrum creates a rhythm of work.

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:

  • what the team delivers.
  • who does what.
  • how progress is made. 

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.

Agile creative studio
Agile marketing at their desk
Writer using scrum to create content.
Two people in the middle of a home remodel project
a desk for working on Scrum professional development
Scrum Education - pencils

Establishing agile ways of working.

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. 

Work considerations for applying Scrum.

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.

Team considerations for applying Scrum.

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:

  • Distributed teams. A lot of Scrum literature will talk about teams needing to be co-located, but it doesn’t have to be. Scheduling and collaboration become more complicated if the team spans over four time zones. I’ve led Scrum across multiple distributed teams, and the level of communication and collaboration significantly strengthened the community. 
  • Part-time teams. Scrum teams are usually full-time teams, and that setup is ideal. I have led Scrum on teams where no one was assigned full-time to the project. The primary adjustment was to the cadence of the Scrum events. Over time, as we evaluated and adapted, we found a rhythm that fit.
  • No team at all. I’ve used Scrum on a team of one for many years, and I’ve applied it to my professional development and home renovation projects. In both cases, it helped me prioritize among the possible options. 

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.

How to use Scrum in your context.

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

  • Assess your context.
  • Learn the essentials.
  • Phone a friend.
  • Start simple and lightweight.
  • Leverage the retros.
Assess your context.

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. 

Learn the essentials.

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.

Phone a friend. 

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.

Start simple and lightweight.

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.

Leverage the retros.

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.

How to teach Scrum?

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.

Facilitation exercises

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.

  1. Matching Scrum roles and responsibilities.
  2. Battleship: Agile vs. Waterfall
  3. Relative Sizing
  4. Capacity and Forecasting
  5. Accelerating Delivery. 

Matching Scrum roles and responsibilities.

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.

  • Ensure Quality
  • Attend Sprint Planning x3
  • Attend Sprint Review x3
  • Attend Daily Standup x2
  • Attend Sprint Retrospective x2
  • Attend Backlog Grooming x3
  • Design
  • Build
  • Test
  • Integrate software
  • Deploy
  • Improve process
  • Improve technical practices
  • Prioritize Product backlog
  • Talk to stakeholders
  • Track the progress of the sprint
  • Make Product Backlog visible to all
  • Create Product backlog items
  • Resolve Technical impediments
  • Resolve organizational impediments
  • Facilitate Scrum events
  • Ensure Scrum rules are followed
  • Coach team
  • Track progress of the release

Battleship: Agile vs. Waterfall

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. 

  • How did the two teams experience the game differently?
  • Which team typically won? Why?
  • Which approach more accurately represents our current approach to managing work?
  • What would a more agile approach look like in our context?

The purpose of the exercise is to allow the team members to experience the benefits of a more agile approach.

Relative Sizing

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. 

How to Play

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.

  • Read the task out loud and assign it a size
  • Explain to the rest of the team your reasoning.

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.

Key Learning

The beginning is difficult without a reference story. Work through these questions with the team.

  • What's the size difference between an S and an M?
  • Explain to a team that an XS represents the smallest type of task, and an S is about two XSs. Ask if they need to adjust any cards.
  • Explain that an M is about the size of an S and an XS combined. Ask if they need to adjust any cards.
  • Explain that an L is about the size of an S and an M combined. Ask if they need to adjust any cards.
  • Explain that an XL is about the size of an M and an L combined. Ask if they need to adjust any cards.
Apply What They Learned.
  • Add a new card and ask the team to size it.
  • Discuss how this was different than before? Are there still any challenges to sizing this way?
  • Explain planning poker for the final three cards.
  • Discuss advantages of planning poker approach.

You'll be ready to tackle the same challenges with your real-life projects when you finish.

Capacity and Forecasting.

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. 

Facilitator Notes

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.

Finding the finish lines.

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.

Discussion

After completing the exercise, work through these questions:

  • How many sprints until a customer can share a recipe with someone else?
  • When will the app begin to generate revenue?
  • How many sprints until the app works on Android?
  • If you begin to get requests for launching a Spanish version of the app, what would you communicate about availability?
  • You just learned that Samsung is releasing a new smart fridge and wants to feature your app. What is your current forecast for this functionality?
  • If the backlog was re-ordered, how far up could you move the smart fridge integration feature?

Accelerating Delivery. 

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. 

Facilitator Notes.

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.

Written materials.

The two significant advantages of written materials are: 

  1. It can be read over time, allowing people to absorb the information slowly. 
  2. You can refer back whenever there are questions.

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

  1. This guide
  2. Books
  3. Scrum organization

This guide :)

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.

Books

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.

  1. Scrum. The art of doing twice the work in half the time by Jeff Sutherland.
    This book focuses on the concepts of Scrum answering questions around why and what.
  2. The Scrum Fieldbook by J. J. Sutherland.
    This book focuses more on the practical application of Scrum, addressing questions of how.

Scrum Organizations

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.

Formal instruction

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. 

Personal coaching

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.

  • Your organization. If you work in a large organization and some parts of the organization have already implemented Scrum successfully, check in to see if they can suggest someone as a coach. 
  • Scrum organizations. Scrum Alliance allows you to search from their database of Certified Team Coaches.
  • LinkedIn. A quick search for “Scrum Coach” on LinkedIn returned over a million results. But you can further narrow it down by location and other criteria.

Everyday Design. Ok, a slightly shameless plug here, but I’m offering a handful of free coaching appointments each month.

Scrum FAQs

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.

What is Scrum?

What is the definition of scrum?

Scrum is a team-based framework to increase work visibility allowing for regular evaluation and timely adjustments.

Scrum is founded on three essential pillars leading teams to ask the following questions:

  1. How does this make things more visible? (Transparency)
  2. Where does this create space to evaluate? (Inspection)
  3. When does this encourage growth? (Adaptation)

Further explore the definition of scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

Take me back to the top of the FAQs.

Is Scrum hard to learn?

The typical response is Scrum is easy to understand but hard to practice.

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.

Take me back to the top of the FAQs.

When did Scrum start?

The term was first used in project management in 1986 but the first Scrum project wasn't until 1993.

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.

Take me back to the top of the FAQs.

What do all the scrum words mean?

There are many, check the glossary.

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.

Take me back to the top of the FAQs.

How to use Scrum

Why use Scrum?

Scrum is vital for teams to deliver value amidst changing circumstances.

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.

Take me back to the top of the FAQs.

When does Scrum not work well?

Scrum can fail when there is a substantial mismatch between organizational culture and the Scrum values.

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.

Take me back to the top of the FAQs.

How do I know when to use Scrum?

When you have a dedicated team, a singular product and are facing uncertainty.

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.

Take me back to the top of the FAQs.

Learning to apply Scrum

How to choose between Scrum and Kanban?

Scrum and Kanban have many similarities, and which one is right for you will depend on your context.

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.

Take me back to the top of the FAQs.

How does scrum help an organization?

Scrum forces clarity and prioritization.

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.

Take me back to the top of the FAQs.

Is scrum a methodology or a framework?

Scrum is more of a framework than a methodology.

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.

Take me back to the top of the FAQs.

What’s the difference between scrum and agile?

If you’re practicing Scrum, you’re working in an Agile way.

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.

Take me back to the top of the FAQs.

Scrum team

How does a scrum team work?

The product owner, scrum master and development team all have a role in the Scrum team.

The scrum team is made up of the product owner, scrum master and development team. They each play important roles.

  • The product owner maximizes the value delivered by the product.
  • The scrum master maximizes the impact of the development team.
  • The development team transforms the product vision into reality.

Learn more about how a scrum team works together. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

Take me back to the top of the FAQs.

Is a Scrum Master a project manager?

The project manager is focused first on the work. The scrum master is focused first on the people.

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.

Take me back to the top of the FAQs.

Can a scrum master be a developer?

Yes. But a dedicated full time Scrum Master is best.

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.

Take me back to the top of the FAQs.

What’s the right scrum team size?

The ideal development team size is between three and nine people.

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.

Take me back to the top of the FAQs.

Scrum roles

What are the roles in scrum?

Scrum Master, Product Owner, and Development Team.

There are three roles in Scrum:

  1. Scrum Master 
  2. Product Owner
  3. Development Team

Learn more about the scrum roles. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

Take me back to the top of the FAQs.

What if I don’t have all the scrum roles on my team?

Someone on the team can play more than one role.

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:

  • One Scrum Master for multiple teams
  • Scrum Master + Development Team member
  • Product Owner + Development Team member

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.

Take me back to the top of the FAQs.

Who are the stakeholders in scrum?

Leaders & Customers

A scrum team has stakeholders on two sides.

  1. Organizational leaders.
  2. Customers or end-users.

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.

Take me back to the top of the FAQs.

Is an agile coach a scrum role?

An agile coach is not a traditional role on a scrum team.

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.

Take me back to the top of the FAQs.

Scrum master role

What is a scrum master?

A Scrum Master is a master of process and an empowerer of people.

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.

Take me back to the top of the FAQs.

Why is a scrum master called a servant leader?

They put the needs of the team first.

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.

Take me back to the top of the FAQs.

Why is a scrum master important?

The scrum master focuses on maximizing the impact of the development team.

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.

Take me back to the top of the FAQs.

Can scrum masters work remotely?

Yes, if the rest of the team is also remote.

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.

Take me back to the top of the FAQs.

Can one person be the Scrum Master for multiple teams?

Yes, but not ideal for a new Scrum Master.

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.

Take me back to the top of the FAQs.

Scrum master responsibilities

What does a scrum master do each day?

The Scrum master’s day involves whatever is necessary to help the scrum team thrive.

If you could look at their calendar, you would probably see things like

  • The daily standup, maybe more than one.
  • Meeting with other leaders to explain scrum.

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.

Take me back to the top of the FAQs.

How does a scrum master remove impediments?

The Scrum Master advocates for the team's needs and works with other to resolve the obstacles so the team can focus on producing the highest value possible.

The scrum master helps remove obstacles, such as

  • The team does not have the tools or resources to do the necessary work.
  • Functional managers are trying to assign extra responsibilities.
  • Mix messages or a lack of clarity about a user story in the backlog.
  • A lack of responsiveness from the Product Owner.
  • Unrealistic expectations about how long the required work takes.

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.

Take me back to the top of the FAQs.

How does a scrum master coach the team?

They facilitate so the team identifies the problem and creates solutions.

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.

Take me back to the top of the FAQs.

How does a scrum master motivate the team?

The Scrum Master focuses on maximizing the impact of the development team.

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.

Take me back to the top of the FAQs.

Scrum master and product owner

Can the scrum master also be the product owner?

Technically, yes, but not recommended.

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.

Take me back to the top of the FAQs.

How does the scrum master help the product owner?

The scrum master balances the product owner’s drive to complete the product with the team's long-term effectiveness.

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.

Take me back to the top of the FAQs.

How does the product owner help the scrum master?

The product owner provide current and future direction for the team.

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.

Take me back to the top of the FAQs.

How is the product owner different from the scrum master?

The product owner is product-focused and team-mindful, while the scrum master is team-focused and product-mindful.

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.

Take me back to the top of the FAQs.

Are the scrum master and the product owner part of the scrum team?

Yes, they are key members of the Scrum team.

The scrum team includes the following roles

  • scrum master 
  • product owner
  • development team

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.

Take me back to the top of the FAQs.

Product owner

What is a product owner?

The Scrum Product Owner's primary responsibility is to maximize the value delivered to the product.

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.

Take me back to the top of the FAQs.

What does a product owner do each day?

The Scrum Product Owner's primary responsibility is to maximize the team's value to the product.

They accomplish this goal through 5 habits:

  1. Stakeholder Relationships and Synthesis
  2. Backlog Refinement
  3. Road Mapping
  4. Sprint Vision and Goals
  5. Inspection

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.

Take me back to the top of the FAQs.

Development team

What is the development team?

The development team is a cross-functional, self-organizing team.

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.

Take me back to the top of the FAQs.

What does self-organizing mean?

A self-organizing team shares leadership and accountability within the team.

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.

Take me back to the top of the FAQs.

Does a Scrum development team have to be programmers?

No. Scrum is not just for programmers.

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.

Take me back to the top of the FAQs.

What does a scrum development team do each day?

The dev team is transforming the sprint vision into reality.

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.

Take me back to the top of the FAQs.

Scrum events overview

What are the Scrum events?

Sprint planning, daily standup, backlog refinement, sprint review, sprint retrospective.

The rhythm of scrum consists of various events.

  • Sprint planning
  • Daily standup 
  • Backlog refinement
  • Sprint review
  • Sprint retrospective
  • The sprint

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.

Take me back to the top of the FAQs.

What scrum events are timeboxed?

Every Scrum event is timeboxed.

Most scrum events are timeboxed relative to the length of the sprint:

  • Sprint planning: 2 hours / sprint week.
  • Daily standup: 15 minutes.
  • Backlog refinement: 2 hours / sprint week.
  • Sprint review: 1 hour / sprint week.
  • Retrospective: 45 minutes / sprint week.

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.

Take me back to the top of the FAQs.

When should scrum events be held?

The Scrum team has freedom to adapt when some of the Scrum events are held.

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.

Take me back to the top of the FAQs.

Which scrum event is most important?

Trick question...

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.

Take me back to the top of the FAQs.

Beginning a sprint

What is sprint planning in scrum?

Sprint planning is the first event of the sprint and provides clarity for the team to reach the sprint goal.

Here’s a quick agenda

  • Product owner sets the sprint direction.
  • PBIs move from the product backlog to the sprint backlog.
  • Team plans how they will complete the selected work.
  • Team communicates their plan back to the product owner and scrum master.

Learn more about how to facilitate sprint planning. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

Take me back to the top of the FAQs.

What is a sprint in scrum?

A sprint is the basic unit of time in scrum, serving as a boundary for what the team focuses on.

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.

Take me back to the top of the FAQs.

Is the sprint a scrum event?

The sprint contains all the Scrum events.

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.

Take me back to the top of the FAQs.

At which scrum event is the sprint backlog created?

Sprint planning.

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.

Take me back to the top of the FAQs.

Middle of a sprint

What is a daily standup?

15-minute daily meeting to set the team's focus.

The Daily standup is a brief 15-minute daily check-in for the Scrum team to do three things:

  1. Inspects the previous day's work.
  2. Plans the current day’s work. 
  3. Identifies any barriers to getting things done. 

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.

Take me back to the top of the FAQs.

What is scrum backlog refinement?

Previewing and defining future work.

During the backlog refinement session, the team previews upcoming work to ensure the following:

  • Outcomes are clearly defined.
  • Supporting information is visible.
  • Resources are accessible.

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.

Take me back to the top of the FAQs.

Ending a sprint

What is a sprint review 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.

Learn how to run a sprint review. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

Take me back to the top of the FAQs.

How to run a scrum retrospective?

The retrospective occurs at the end of the sprint for the scrum team to focus on self-improvement.

The tone is positive and productive, focused on improving the team. 

Three strategies for a compelling retrospective include

  1. Provide pre-work for the scrum team to reflect on the sprint experience.
  2. Set ground rules for healthy, productive communication.
  3. Use activities to facilitate the conversation.

Learn how you can facilitate a scrum retrospective. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

Take me back to the top of the FAQs.

Facilitating scrum events

How to facilitate scrum events?

Facilitation is customized to the event and the needs of the team.

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.

Take me back to the top of the FAQs.

How to improve scrum events?

Scrum events improve as participation increases.

Three strategies for increasing participation in scrum meetings are

  1. Clearly state the goal. Sometimes people don’t engage because they are unsure about the purpose.
  2. Use facilitation games. There are many facilitation exercises available for the scrum events.
  3. Invite feedback. Inspection is a pillar of scrum. Ask the team for feedback on what went well and how to improve.

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.

Take me back to the top of the FAQs.

Who facilitates (or owns) scrum events?

Different members of the Scrum team facilitate the various Scrum events.

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.

Take me back to the top of the FAQs.

Does the scrum master facilitate all the scrum events?

The Scrum Master primarily facilitates sprint planning and the retro.

The scrum master primarily facilitates two scrum events:

  1. Sprint planning
  2. The retrospective

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.

Take me back to the top of the FAQs.

Scrum events responsibilities

In which scrum event(s) is the product owner mandatory?

The product owner must attend sprint planning, backlog refinement, sprint review, and the retrospective.

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.

Take me back to the top of the FAQs.

Scrum events purpose

What is the goal of each Scrum event?

Each event has a clear purpose.
  • ‍Sprint planning: Clarify the direction and goal for the sprint. 
  • Daily standup: Everyone on the team gains updated visibility into everyone’s work. 
  • Backlog refinement: Understand upcoming work.
  • Sprint review: Present finished work to stakeholders for feedback.‍
  • Sprint retrospective: Review how the team works and make necessary adjustments.

Understand the purpose of the scrum meetings. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

Take me back to the top of the FAQs.

Which scrum events facilitate inspection and adaptation?

Every event includes inspection and adaptation.

Inspection and adaptation (along with transparency) are pillars of scrum, so all events involve them.

  • Sprint planning: the purpose and work of the sprint are inspected.
  • Daily standup: progress toward the sprint goal is inspected, and adjustments are made.
  • Backlog refinement: upcoming work is inspected, and PBIs are adapted.
  • Sprint review: delivered work is inspected, and upcoming work is adapted
  • Retrospective: team health and interactions are inspected, and norms or plans are adapted.

Learn more about the role of events in scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

Take me back to the top of the FAQs.

Which scrum event is for process improvement?

Each Scrum event plays a role in process improvement.

Process improvement aligns closely with the scrum pillars of transparency, inspection and adaptation.

  • Sprint planning: How do we improve the product?
  • Daily standup: How do we improve our approach to the sprint goal?
  • Backlog refinement: How do we improve the quality of the product backlog?
  • Sprint review: How do we improve the functionality being delivered?
  • Retrospective: How do we improve how our team works together?

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.

Take me back to the top of the FAQs.

What is the goal of the scrum of scrum event?

Coordinating between multiple Scrum teams focused on the same product.

The scrum of scrums is an extra scrum event used when multiple scrum teams are collaborating together on a single product.

The scrum of scrums follows a similar pattern to the daily scrum session. 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 allows those team to stay in sync and account for dependencies that bridge across teams. When facilitated well with healthy teams the scrum of scrum can even create collective ownership you see in self organizing teams.

If multiple scrum teams are collaborating on a single product then ideally both teams care more about it the product as a whole succeeds versus just caring if they did their part. The transparency, evaluation and adaptation from the scrum or scrums can make this possible.

To learn more explore the most common terms in a Scrum glossary.

Take me back to the top of the FAQs.

Scrum design

What are the three pillars of Scrum?

Transparency, Inspection and Adaptation.

Scrum is founded on three essential pillars, and each leads the team to ask a critical question.

  1. Transparency. How does this make things more visible?
  2. Inspection. Where does this create space to evaluate?
  3. Adaptation. When does this encourage growth?

Learn how to apply the three pillars of Scrum and then explore the most common terms in a Scrum glossary.

Take me back to the top of the FAQs.

What are the values of Scrum?

Commitment, courage, focus, openness and respect.

There are five values critical to the practice of Scrum: commitment, courage, focus, openness, and respect.

  1. Commit to achieving the goals of the Scrum Team.
  2. Courage to do the right thing and work on challenging problems.
  3. Focus on the Sprint's work and the Scrum Team's goals.
  4. Open about all the work and the challenges with performing the work.
  5. Respect each other to be capable, independent people

Learn how to align Scrum values with your organization and then explore the most common terms in a Scrum glossary.

Take me back to the top of the FAQs.

What is the sprint goal in scrum?

A vision and theme to guide the sprint.

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.

Take me back to the top of the FAQs.

Scrum elements

What is the definition of done?

Criteria shared by a Scrum team for what constitutes done.

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.

Take me back to the top of the FAQs.

What is the increment in scrum?

The increment is the new functionality or value delivered at the end of a sprint.

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.

Take me back to the top of the FAQs.

Scrum backlog

What is the backlog in Scrum?

A prioritized list of work to be done by the Scrum team.

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.

Take me back to the top of the FAQs.

How are the product backlog and sprint backlog different?

Product backlog contains work for the product and sprint backlog contains work for the sprint.

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.

Take me back to the top of the FAQs.

What is a PBI (product backlog item)?

The container for work organized in the backlog.

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.

Take me back to the top of the FAQs.

Agile story points

What are story points?

Story points measure the relative size of a PBI (Product Backlog Item).

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.

Take me back to the top of the FAQs.

Are Scrum story points measured in hours?

Story points measure the relative (not absolute) size of work.

In Scrum, you are not measuring work in absolute terms like hours spent or lines of code to be written. Two reasons for this:

  1. Not everyone works at the same pace or has the same set of expertise and experience.
  2. Until you do the job, these are unknown and, at best just guesses.

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.

Take me back to the top of the FAQs.

Do story points in Scrum always use the Fibonacci sequence?

No. But Fibonacci offers some distinct benefits.

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:

  1. Keeping story points measured in numbers is advantageous because it is then easier to calculate a team's velocity.
  2. The numbers have distinct relationship with each other making relative sizing more intuitive. The Fibonacci sequence increases such that each number is the sum of the previous two number.

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.

Take me back to the top of the FAQs.

What is velocity in Scrum?

Velocity measures how many story points a Scrum team completes on average per sprint.

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.

Take me back to the top of the FAQs.

Scrum certifications

Where should I start with scrum certifications?

Your best path and starting point really depends on your goals.

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.

Take me back to the top of the FAQs.

Scrum master certifications

How to get certified as a scrum master?

CSM vs. PSM

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.

Take me back to the top of the FAQs.

Why become a Certified Scrum Master (CSM)?

Knowledge + Job Requirement

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.

Take me back to the top of the FAQs.

How quickly can I become a scrum master?

2 days to certification. Much longer to Mastery.

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.

Take me back to the top of the FAQs.

Product owner certifications

How to get certified as a product owner?

CSPO vs. PSPO

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.

Take me back to the top of the FAQs.

Why become a Certified Scrum Product Owner (CSPO)?

Make a difference by creating great products

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.

Take me back to the top of the FAQs.

Comparing certification

CSM vs. CSPO, how do they compare?

CSM (Certified Scrum Master) vs. CSPO (Certified Scrum Product Owner)

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.

Take me back to the top of the FAQs.

CSM vs. PSM, how do they compare?

CSM (Certified Scrum Master) vs. PSM (Professional Scrum Master)

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.

Take me back to the top of the FAQs.

How does the PMI-ACP compare to other scrum certifications?

The PMI-ACP requires experience and a great breadth of knowledge.

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.

Take me back to the top of the FAQs.

How does the PMP compare to other scrum certifications?

PMP (Project Management Professional)

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.

Take me back to the top of the FAQs.

Scrum user stories

What is a user story?

User stories are a simple schema to organize 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 and are written using the following format:

  • As a… [user]
  • I want to… [goal]
  • So that I can… [motivation] 

See examples of user stories to learn to write your own and explore the essential Scrum glossary.

Take me back to the top of the FAQs.

What is acceptance criteria in scrum?

Acceptance Criteria defines the requirements which must be met for the sprint deliverables to be accepted by the product owner.

Acceptance criteria is written using the following structure:

  • Given that [context allowing me to take an action]
  • When [I take the action]
  • Then [a result occurs indicating success or failure]

Learn more about how acceptance criteria is used in Scrum and explore the essential Scrum glossary.

Take me back to the top of the FAQs.

How to use acceptance criteria in project management?

You can apply acceptance criteria to individual tasks or groups of task that have a common outcome.

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.

Take me back to the top of the FAQs.

How are acceptance criteria and user stories different?

User stories and acceptance criteria. Two sides of the same coin.

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.

Take me back to the top of the FAQs.

Acceptance criteria

What's an example of acceptance criteria?

Given that... When... Then...

Acceptance criteria is structured using the template

  • Given that [context allowing me to take an action]
  • When [I take the action]
  • Then [a result occurs indicating success or failure]

Here are 3 examples:

Checkout process functionality

  • Given that I’ve added all the items to my cart and I’m logged in,
  • When I click the check out button,
  • Then the checkout page loads with all my payment and shipping information preloaded.

Advertising campaign

  • Given that someone fits our ideal customer persona,
  • When they search for keywords we’re targeting,
  • Then a link to a compelling offer is displayed above the fold.

Marketing campaign (Did you know you could use Scrum for marketing)

  • Given that a customer is already receiving email communications,
  • When they visit the site and engage content related to a specific product,
  • Then they will be automatically subscribed to nurturing campaign highlighting that product. Or

See more acceptance criteria examples and learn to write how to create your own or learn other essential scrum terms.

Take me back to the top of the FAQs.

What is acceptance criteria in scrum?

Acceptance Criteria defines the requirements which must be met for the sprint deliverables to be accepted by the product owner.

Acceptance criteria is written using the following structure:

  • Given that [context allowing me to take an action]
  • When [I take the action]
  • Then [a result occurs indicating success or failure]

Learn more about how acceptance criteria is used in Scrum and explore the essential Scrum glossary.

Take me back to the top of the FAQs.

How to write an acceptance criteria statement?

Follow the pattern Given that... When... Then...

Acceptance criteria is broken down into three parts.

  • Given that [context allowing me to take an action]
  • When [I take the action]
  • Then [a result occurs indicating success or failure]

Learn more about templates for writing acceptance criteria or learn other essential scrum terms.

Take me back to the top of the FAQs.

How are acceptance criteria and user stories different?

User stories and acceptance criteria. Two sides of the same coin.

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.

Take me back to the top of the FAQs.

How are acceptance criteria and the definition of done different?

They different in scope.

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.

Take me back to the top of the FAQs.

StrengthsFinder

So do I totally ignore my weaknesses and just focus on my strengths?

Ignoring your weaknesses will likely get you into trouble.

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.

Take me back to the top of the FAQs.

There are strengths I think I have; why didn’t they didn’t show up in my top 5?

They could be somewhere in your list between 6-10.

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.

Take me back to the top of the FAQs.

Should I pay to see all 34 strengths?

Start out staying focused on your top 5.

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.

Take me back to the top of the FAQs.

What’s the difference between a talent and a strength?

Talents can become strengths.

A talent is your natural way of thinking or behaving. A strength is a talent developed over time through knowledge, skills and practice.

Take me back to the top of the FAQs.

Do you want to learn about Scrum?

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.

articles On Scrum
A product owner and scrum master in a meeting
Agile marketing at their desk
Writer using scrum to create content.
Two people in the middle of a home remodel project
Scrum FAQ Sign
a desk for working on Scrum professional development
Scrum Education - pencils
Sticky-notes arranged
two people learning Scrum together
A woman using Scrum
person stretching at sunrise
picture with contrast
Two members of a Scrum team working on acceptance criteria examples at a whiteboard
Scrum development team at a table during a meeting
A soccer goal
team working together
Team members at a table together
Sticky notes on a window
sprinters in a race
Lego bricks
Scrum Team together
Scrum Meeting
Woman typing on a computer
Speed blur
3 people in discussion
As a... I want to... So the I can...
Two people leaping for joy
Business woman looking out the window
Woman laughing
people using computers at the same table
a project manager at a desk next to a Scrum Master at a desk
A Scrum team of 4 people
3 people in a Scrum meeting
Team viewing a whiteboad
Sticky notes
Team looking at a whiteboard
Team standing for a meeting
Team Retro Session
?? Scrum???
Team meeting
Two people pointing at a whiteboard
Woman with sticky notes
Woman writing on whiteboard