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?

The purpose of the Sprint is to deliver a done increment of valuable, usable product. In order to get there, it is important that higher ordered Product Backlog items are sized so that they are small enough to be completed within a single Sprint. The purpose of estimation in Scrum is to size higher ordered Product Backlog items so they can be completed within a single Sprint.

Here is why developing in one Sprint and testing in the next actually causes more problems than it solves.

Nexus is the simplest, most lightweight framework available. Nexus can be considered an extension of Scrum because it preserves the simplicity that makes Scrum great.

What are the 5 events in Scrum? Can you name them? Chances are that you said something like “Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, and…. umm…..”

The Scrum Master accountability extends far beyond guiding the Scrum team through Scrum events and facilitating meetings as requested or needed. Scrum Masters are change agents who transform not just the team, but also the entire organization.

In this article, we'll explore some popular tools and apps, including Jira, Team Foundation Server, Rally, and others, that Scrum Masters can leverage to help teams visualize their work, increase Transparency and increase team efficiency.

Determining whether a Scrum Master is effective can be challenging, as their impact is often indirect and not always easy to measure quantitatively. In this article, we will explore key indicators that can help you evaluate the effectiveness of a Scrum Master.

Incremental delivery - or delivering value frequently - is a core concept of Scrum and yet it is so often misunderstood. Some might argue that it's wasteful to not make a few additional small changes or updates when you're already deep in the code. However, this perception is often rooted in a misconception. In reality, not using incremental delivery can be far more wasteful and inefficient.

Scrum is utilized in various industries, and as a result, leaders from diverse backgrounds are tasked with guiding Scrum Teams. While technical expertise can be an asset, it's not always a prerequisite for effective leadership in an Agile environment.

One question that often arises in the context of Scrum is whether individuals can be part of more than one Scrum Team. While there is no explicit rule against this in Scrum, it's essential to explore the implications of such arrangements on productivity and adherence to Scrum values.

In a world marked by constant change and complexity, effective facilitation has become a critical skill for individuals and organizations alike. Whether you're leading a Sprint Planning event, a brainstorming session, or a strategic planning workshop, the ability to guide conversations, foster inclusivity, and elicit valuable insights is paramount. Facilitation is not just about orchestrating discussions; it's about creating an environment where everyone's voices are heard, ideas are explored, and decisions are made collaboratively. This is where Liberating Structures come into play, offering a toolkit of powerful facilitation techniques that can transform the way groups work together.

The Product Owner is the bridge between corporate strategy and the Scrum Team. The Product Owner must balance the demands of users against the need to ensure that the product remains up to date from a technical perspective. This often means that the Product Owner may need to choose between developing new features to satisfy customer requests and fixes for technical debt.

In this article, we will explore some complimentary practices which the Product Owner might use to as an input when deciding how to order the Product Backlog.

Coaching plays a pivotal role in guiding teams toward greater efficiency, collaboration, and overall success. It’s important to remember that you can't coach people out of every bad practice all at once. This article explores the wisdom behind focusing on the highest impact opportunities rather than attempting to create a perfect team overnight.

At the heart of Scrum lies the Retrospective, a crucial event where teams reflect on their work and identify areas for improvement. One often overlooked opportunity at the Retrospective is measuring employee satisfaction. This article highlights the opportunity of incorporating employee satisfaction measurement into Retrospectives and how it can contribute to team success.

Defining requirements up front is not compatible with Scrum, because Scrum teams don’t deliver value in one “big bang”.  Scrum teams deliver value incrementally.  In this article, we will explore how defining requirements up front limits the Scrum team’s ability to learn, inhibits incremental delivery, and ultimately clashes with Scrum.

The concept of limiting work in progress revolves around the principle that focusing on fewer tasks at a time leads to better outcomes. In a Scrum context, this involves setting a cap on the number of user stories, features, or tasks that the development team is actively working on during a sprint. By doing so, teams prevent themselves from spreading thin and promote a concentrated effort on a select number of items.

How do you uphold Scrum without becoming a Scrum dictator? How do you lead the Scrum Team to ever greater adoption of Scrum within the organization… without direct authority? This article explores the challenges faced by Scrum Masters in their balancing act and how they navigate through it to ensure effective team performance and continuous improvement.

At the heart of Scrum is a unique and indispensable accountability: the Scrum Master. This enigmatic figure may not possess the traditional authority associated with managers, nor do they hold executive powers. Yet, they play a vital and indispensable accountability in the success of the Scrum Team and the organization as a whole.

In this article, we have crafted interview questions to help identify the best Product Owner for your Scrum team.

The purpose of the Scrum Master is to enhance the efficiency and productivity of the Scrum team. It’s an important accountability for the success of the Scrum team, and yet, it is surprising that many people are uncertain about the qualities they should seek when hiring a Scrum Master. In this article, we will present ten interview questions that will aid you in selecting the perfect Scrum Master for your team.

The purpose of the Scrum Master is to improve the effectiveness of the Scrum Team. And yet, so many people don’t know what to look for in a Scrum Master or how to evaluate the Scrum Master’s performance. A great Scrum Master possesses a unique blend of technical expertise, leadership skills, and interpersonal qualities. In this article, we will explore the ten characteristics that define a remarkable Scrum Master.

According to the 2020 Scrum guide, “Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.” But what does that mean, exactly?

There are certain misconceptions and patterns that can hinder the effectiveness of the Product Owner and lead to conflicts within the Scrum team. In this article, we will explore three common anti-patterns related to the Product Owner's accountability in Scrum and discuss strategies to overcome them.

Escape the Rinse and Repeat Cycle with 5 Sprint Retrospective Ideas

Nexus is a scaling framework that can be used to scale Scrum when there are three or more Scrum teams working together on the same Product. Teams using Nexus create a Sprint goal not only for each Scrum team, but also for all teams working together in the Nexus. This shared Sprint goal is called the Nexus Sprint Goal, and it should not be skipped.