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.  

Some ideas stand the test of time, such as the value of cross-functional teams in new product development.

Some well-intentioned practices sound reasonable, but a closer examination reveals potential pitfalls that can compromise the Agile manifesto principles or the Scrum guide's underlying Empiricism. By understanding the rationale behind these practices and exploring their drawbacks, teams can foster a more nuanced and practical approach to achieve true agility and continuous improvement.

Focus on improving your Scrum game in 2024 with one of these five resolutions to enhance collaboration within your team and deliver value sooner to your customers.

When Product Owners craft roadmaps in isolation - without consulting the Developers -  the result can be a 'pie in the sky' or unrealistic plan that jeopardizes the very essence of Scrum.

Myths can hold us back from our highest potential by creating confusion and misdirection. In this article, we will debunk 10 common myths about Scrum. Now, I'm not saying that chaos dragons are real, but I am saying that Scrum is not chaos.

The Scrum framework is deliberately incomplete, so when teams start to fall for Scrum myths, frequently these myths are actually holding the team back from embracing the true flexibility of Scrum. Teams should find out what works best for them, not works best for other people.

It is important for Scrum practitioners to understand that there are a lot of myths and misconceptions about Scrum that they should be wary of when they are applying Scrum to their unique environment. In this article, we will debunk four common Scrum myths.

Many teams who have adopted Scrum adopt practices which are intended to be ‘helpful’ but which actually hinder teams from delivering value.  These practices sound like a good idea, but they are actually ‘traps’ which may hold back organizations from getting the most out of the Scrum framework.

Teams solving complex problems need creativity to figure out how to deliver value.  Traditional “command and control’ techniques are less impactful in this environment and can even harm the team’s ability to deliver value. 

This article explores the art of Agile leadership, delving into the challenges of finding the right equilibrium between allowing teams to self-organize and providing enough guidance and structure for seamless Agile execution.

When we uncover the truth, we arm ourselves with valuable insights, and that's truly empowering. In this article, we will dispel 3 Scrum myths.

A dependency refers to a situation where one task, Product Backlog item, user story, or feature relies on another for completion or integration. In this article, we will discuss the impacts of high dependencies on value delivery.

Refinement is an important activity for the Scrum team. So, why isn't Refinement considered a formal Scrum event?