There’s a reason we often say, “Trust but verify.” It's because trust is important — but to build and maintain trust we need transparency. In Scrum, the Sprint Review gives us a way to practice that idea consistently.

When a new Scrum Team first starts working together, they go through some common growing pains. Knowing what to expect for a new Scrum Team can help make things go a little smoother.

Organizations define Product Manager and Product Owner roles differently. Company size, industry, and structure all play a role. Scrum makes the Product Owner accountable for maximizing value, but many companies add a Product Manager alongside—or instead of—a Product Owner. This creates variations in how the roles function.

The purpose of the Scrum Master is to improve the adoption of Scrum. So, it makes sense that the Scrum Master should ask the question What does a high-performing Scrum Team look like

Scrum actually has very few rules. It’s a simple framework with just enough—but not too much—structure to help teams work together. It’s flexible. It’s lightweight. And it gives teams the space to learn, adapt, and improve continuously.

According to the Scrum Guide, a Sprint can be cancelled—but only by the Product Owner, and only if the Sprint Goal becomes obsolete. But what does that even mean?

In Scrum, “Done” means done. Not halfway done, not “almost there,” and certainly not “we’ll get to it next Sprint.” Yet, many teams find themselves with a growing burden of unfinished work. Over time, that burden starts to feel like a monkey on the team’s back—heavy, distracting, and hard to shake off.

One of the biggest mistakes I’ve seen in Agile adoption is the separation of design and development into different teams, each with their own Product Owner and their own Product Backlog.

It isn't just individuals who can suffer from burnout. Sometimes, it's the whole Scrum Team. PST Mary Iqbal explores this serious problem in her latest blog post.

New Scrum Teams aren't perfect, but when you use Scrum to get better, you get better at Scrum. So often, when you first start using Scrum, it can feel like you're just going through the motions. And while that can be frustrating, it's also a part of learning.

Let’s set the record straight: Scrum Master is not a dead-end job. In fact, it might be the best stepping stone to real leadership you could ask for.

It may be tempting to push the team to deliver more by overloading the Sprint with extra work. But don’t do it! One of Scrum’s core values is focus, and that value exists for a reason. A team that focuses on delivering a reasonable amount of work will accomplish more than one that tries to take on everything at once.

Points are not for measuring individual performance. Points are for forecasting future delivery. We don't need to fake the data to make developers look better, because that's not what points are for.

Some teams are obsessed with documenting everything. They create tickets for tracking time, logging meetings, or even planning how to plan. They think they’re being transparent. In reality, they’re just adding layers of clerical work that don’t actually help deliver value.

Scrum Masters can sometimes fall into the trap of managing the process rather than coaching the team. While it might seem helpful to update tickets, close backlog items, or move tasks around, this kind of administrative work actually disempowers the team and takes the Scrum Master away from their real job: helping people grow, removing obstacles, and improving the adoption of Scrum.

Using velocity to measure the success of a Scrum team is like measuring a machine by a single cog in the wheel. The cog may be important, but it’s not the same as the value the machine produces.

At the end of our first Sprint, during the Retrospective, someone pointed out that the Daily Scrum alone would add over 250 meetings a year. It felt excessive. We were already frustrated with too many meetings, so why would we willingly add more? But as we kept going, something changed. We started seeing the benefits—not just in theory, but in practice.

Myth # 39: Technical Debt is the Developer's Problem. They caused it, so they should fix it on their own time.

At Argus, the maintenance team in Edmonton faced a challenge: ensuring consistent, high-quality repairs while dealing with an unpredictable workload.

How can you focus on continuous improvement if you think everything is already perfect? Scrum Masters who become too emotionally attached to their teams can lose the ability to assess improvement opportunities objectively.

In some of my classes, people tell me they are using Scrum—but they can't call it Scrum. Why? Because someone in their organization had a bad experience with it.

Many Scrum Masters see their role as protecting the Scrum Team. But when protection becomes isolation, something is wrong. Shielding a team too much from stakeholders isn't helpful - it hinders collaboration, stifles feedback and erodes trust.

Scrum - when done well - actually promotes even greater accountability than waterfall, because the Scrum team is accountable for value delivery. And great Scrum teams measure - and reflect upon - customer outcomes so that they can adjust course and improve their ability to deliver value.

Management by exception is the idea that we should manage the things that are off track, rather than giving focus to things that are going well. In the context of the Daily Scrum, this could be done by asking open ended questions intended to find out if there are any issues that need to be discussed.

The Scrum framework is simple, with just enough - but not too much - structure to enable teams to collaborate around value delivery in complex environments. The problem is that a lot of teams add unnecessary complexity to the Scrum framework itself, which results in a lot of wasted effort. Here are four strategies to help Scrum teams work smarter, not harder.

Scrum Masters are human. And sometimes - even when they are trying to help - they can unintentionally overstep their authority. In this article, we will discuss the most common ways that Scrum Masters overstep themselves, and why.

In Scrum, the Definition of Done (DoD) is a shared understanding of what it means for a Product Backlog item to be considered complete. For example, for a Scrum team that is developing software, a Definition of Done might include things such as 'Complete code review' or 'all standard Regression scripts have passed' or even 'performance testing complete' or 'page loads in under .1 seconds'.

Adopt one of these New Year's resolutions at your next Sprint Retrospective!

In this article, we will discuss 3 concepts that work better in simple business problems and not so well in an Agile environment.

A common mistake Product Owners (POs) often make is assigning Product Backlog items to specific Scrum Teams or individuals. While this approach may seem efficient - and even helpful - it undermines team dynamics, disempowers Developers, and distracts the PO from their true purpose: maximizing value.

Scrum was designed to be simple—deliberately so. Adding too much too soon can actually slow you down, making it harder to reach the value Scrum is built to deliver.

Many Sprint Review events include a demo, but the Sprint Review is so much more than that.

There is no such thing as pre-refinement. Instead, all work associated with adding order, size and detail to items in the Product Backlog is refinement, whether it takes place in a meeting or whether it's work done by an individual outside of a meeting.

Starting with Scrum can feel overwhelming. It’s a framework with defined events, accountabilities, and artifacts that might seem rigid or even intimidating at first glance. But here’s the truth: it’s okay not to get everything perfect on day one. The real magic of Scrum unfolds as you practice and improve over time.

Have you ever felt like your team spends more time battling over "resources" (a.k.a. people) than strategizing over what is the highest value work? You're not alone. Many organizations struggle with this chaos. Many Product Owners are fighting a constant battle over which work is "actually" the highest priority for the organization, juggling dependencies and scrambling for people to do the work.

There’s a persistent myth out there that a Product Owner should only support one Scrum Team. The idea behind this is that having more than one team will stretch the Product Owner too thin, leading to burnout and unnecessary stress. But that’s actually a huge misconception!

Let me start by saying that I am not demeaning the Scrum Guide in any way. Teams are empowered - with Scrum - to respond and adapt to complex environments in ways that would have been impossible before. That being said, the Scrum framework "just" guides the interactions of the Scrum team itself.

When teams first start adopting Scrum, it seems like they often encounter similar challenges.  In this article, I will address some of the common commons facing new Scrum teams and how to overcome them.

Agile teams often struggle with how to size and forecast upcoming work. Flow metrics offer a simple, effective way to solve that problem without the headaches that come from traditional estimation methods. In fact, flow metrics can provide more accurate planning and forecasting than using points or hours—and they keep things agile, not bogged down in endless debates about estimates.

Efficiency seems like an important word. Other words like productivity, specialization, capacity, utilization and standardization also sound pretty impressive. These words are important words for optimizing (another word!) repetitive processes. The problem is that these words are not as important when it comes to creative work or problem-solving. Read more in this blog post from PST Mary Iqbal.

This article was tough to write, not because I don’t have enough mistakes to share, but because there are so many! Mistakes are where we learn, and that’s exactly what I’ve done. I hope sharing mine will help you avoid making the same ones.

In Scrum, the Definition of Done (DoD) plays a critical role in ensuring quality and transparency. But who defines this important concept? And what does it even mean? Let’s break it down.

Incremental delivery is the superpower behind the Scrum framework. Scrum is based on Empiricism, which requires Transparency, Inspection, and Adaptation. But none of that works without delivering value in increments.

A roadmap is a visualization of the Product Owner’s plan to deliver the Product Goal and fulfill the product vision. But in the real world, especially in complex environments, plans change—and that’s okay.

When you admit that you don’t have all the answers as a Scrum Master, you’re not losing credibility—you’re gaining trust. You’re telling your team, “It’s okay not to know everything. What matters is how we tackle the unknown together.”

The iterative nature of Scrum, with its focus on delivering a Done Increment each Sprint, allows teams to make steady progress toward their goals, even in the face of uncertainty. This process of setting and achieving goals enables teams to adapt to changing conditions, learn from their experiences, and continuously improve.

The short answer is yes, they can. Here's how.

I am often asked, what’s the right amount of information for an item in the Product Backlog. First, there is no “right” amount of information. And second, less is more.

When we say that Scrum is purposely or deliberately incomplete, it's not that they didn't finish writing the Scrum guide or that they have a little more research to do before the Scrum Guide is perfect. What we mean is that Scrum is a framework within which teams work together to deliver value. It's not a rulebook. It's not a set of work instructions. It's not a set of meeting agendas or recommended practices.

To help you identify when your team is deviating from the practice of incremental delivery, here are 4 red flags to watch for.