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.

The Sprint timebox helps to foster a sense of urgency that creates a low tolerance for organizational impediments or wasted effort. The Sprint timebox forces the team and the organization to identify the things that have been holding back delivery - so they can solve them.

In recent years though, Scrum adoption has expanded far beyond its original roots in IT and software development. Today, Agile frameworks including Scrum are used in Operations, Marketing, Human Resources and in product development for industries as varied as industrial microscopes, fighter jets, appliances, candies and more.

While there are various ways to write or format items on the Product Backlog, one of the most popular and effective methods is writing them in the user story format. This practice, though beneficial, is not mandatory. Scrum teams may choose to adopt the user story format when it suits their needs and enhances their workflow.

Some teams think that if they skip refinement, they're saving time, but that's not true at all. Teams must understand what is needed before they can deliver value. Refinement will happen. It's just a matter of whether it will be done in Sprint Planning, during the Sprint, or whether you will do it in advance of the Sprint as part of regular, planned refinement activities.

Velocity is a popular tool that many Scrum Teams use to size and forecast work. But so many organizations equate "velocity" to team "performance", and that is not what it's for.

I'm just going to say it. Most so-called 'spikes' do not belong on the Product Backlog. Learn more in this blog post from PST Mary Iqbal.

In this article, we discuss 10 signs that your company may have at least some elements of "Agile in name only". Do you recognize yourself in any of these?

From boardrooms to water coolers, organizations across industries proudly tout their commitment to Agile principles and frameworks. However, for many companies, being "Agile" often masks a deeper reality: a lack of true Agile mindset and practices.

Agile frameworks are used in complex environments where requirements and technology are ever-changing. It seems pretty unrealistic to think that we could envision all of the customer’s requirements upfront. And yet, that’s what many of those using a Waterfall approach to value delivery are trying to do.

I really can’t let this incremental delivery topic go. According to the 2020 Scrum Guide, “Scrum employs an iterative, incremental approach to optimize predictability and to control risk.” This means that Scrum Teams deliver a done, usable increment of working product frequently. This approach has many benefits, including risk mitigation.

There seems to be a lot of confusion about how exactly to use Agile frameworks to deliver projects. Should you have a charter? Should the Project Manager also be the Scrum Master? This article will discuss 10 common FAQs for Project Managers seeking to use Agile frameworks—like Scrum—to deliver projects.

When companies dip their toe in Agile waters, they often start by simply trying out an Agile framework such as Scrum to deliver something relatively small, such as a project. And that's a great way to start. However, with this comes the question: Can a Project Manager be a Scrum Master?

In this blog post PST Mary Iqbal discusses the question - Who Writes Product Backlog items Scrum?

My recent article Debunking ten Common Objections to Incremental Delivery for Software Teams introduced ten of the most common objections to incremental delivery. In this article I introduce and debunk ten more objections to you guessed it, incremental delivery.

When people first start learning about Scrum, it can seem like Scrum requires many meetings. It might even seem like Scrum is a waste of time.

Here's why "cashing in" undone work is not a good idea.

Some of the highest-performing teams I have ever worked with were part of a Product team. A Product team is when multiple Scrum Teams support a single product. Here are some FAQs about Product teams.

Scrum is no excuse not to create a forecast for delivery or to accept a lack of direction for your product.

Self-management doesn’t mean Developers can do whatever they want, and it doesn’t mean leadership should micromanage the Scrum Team, either. The reality is somewhere in the middle.

There are numerous benefits to a Definition of Done, but consider this: The entire purpose of Sprint is to deliver a done, usable increment at least once per Sprint. Shouldn’t we be clear about what done means to us in our context? In this article, we'll discuss 10 benefits of the Definition of Done in Scrum

Instead of asking, “What is everything we need?” the Product Owner should ask a different question.

Each of the five events in Scrum is time boxed. This means that every Scrum event has a maximum (but not a minimum) amount of time the Scrum Team will spend on the event every Sprint. By limiting the time spent in each Event, the Scrum framework pushes Scrum teams to maximize the quality of their time together.

Agile is not a mere indulgence; it is a more innovative and more efficient way to navigate the intricacies of delivering products and services, particularly when the products or services being developed require creativity and complex problem-solving to deliver them.

In this article, we'll explore - and debunk! - ten common objections to incremental delivery.

Oversized Product Backlog items delay value delivery and increase risk.

As organizations strive to quantify the productivity and effectiveness of their agile teams, the adage "you get what you measure" becomes increasingly pertinent. In pursuing metrics, it is crucial to recognize that measuring the wrong things can have detrimental consequences, potentially eroding the principles that make agile successful.

Telling an important customer that “we will get there when we get there” could come across as dismissive, sending the message that the customer’s needs are unimportant to the Scrum Team.  All organizations have deadlines and need to navigate shifting priorities.  Agile approaches can help organizations meet tough deadlines and navigate shifting priorities by making teams more predictable rather than less.

An unusual article featured in the latest edition of the Harvard Business Review titled "Case Study: Should I Pitch a New Project-Management System?" raised several concerns and demonstrated misconceptions about Scrum. The piece created a false dilemma between "Scrum" and a hypothetical "Flow" process, essentially referring to Kanban.