Seven steps to transitioning to the Product Model for your Agile teams to align your organization around value.

There are five events in Scrum.  But just going through the motions and having each of the events on the calendar is not enough.  To get the most out of Scrum, your team needs to understand the purpose behind each of the five events.  

One of the first things that I usually hear after describing the Scrum framework and its five events to someone new to Scrum is, “that’s a lot of meetings!” I get it — at first glance, it seems like a lot. But it really isn't when I get the person to take a closer look. This article provides a description of each event and how you can reduce the need for other meetings by practicing them.

​​​​​​​In my experience, it’s the Sprint Retrospective that teams are most likely to skip, berate, or otherwise bash.  When I hear teams talking about dropping it to “save time,” I want to pull a Darth Vader, shake my fist in the air, and say, “You don’t know the power of the Sprint Retrospective!” and then demand that the team meet anyway.  Alas, I am not Darth Vader.  But hear me out to consider these five reasons for never skipping a Retrospective.  

Once the team has selected a point system, they need to decide which types of items to classify as a 1, 2, and so on. In this article, we will provide an exercise that can help your team create a point system organically no matter what’s in the Product Backlog.

The Scrum Guide doesn't provide a complete list of the skills required for any of the accountabilities on a Scrum Team. For example, it doesn't specify that Developers must use Java or C# code. The Scrum Guide simply states that Developers need all of the skills to deliver a Done increment of product each Sprint. We intuitively know that the skills required depend on the product. 

In Scrum, part of the Product Owner accountability is to provide a forecast that sheds light on possible answers to the when will we get there question. In my last post, we discussed three ways to size Product Backlog items (PBIs). Today, we’ll discuss ways the Product Owner can use this information to create a meaningful forecast.

When will we get there?  It’s not just something you might hear from the back seat of a car on a long road trip.  It’s something that a Scrum Team’s stakeholders, customers, managers and many others want to know.  When will that thing you are working on be done?  How long do I have to wait for you to deliver what I want? Sound familiar? Today, we’re going to discuss three ways to estimate and in my next post, we’ll talk about forecasting.

If you are a Star Wars fan like me, then you know that Star Wars is more than a story; it’s an Epic which holds many important life lessons.  Below are the top five things I learned about Scrum from Star Wars.

​​​​​​​The concept of iterative, incremental Product delivery is included in the Scrum Guide.  But did you know that the Agile Manifesto refers to incremental, iterative delivery in at least 3 of the principles?   

Teams that change the framework are not using Scrum and are missing out on some of its benefits.  The Scrum framework consists of 5 events, 3 accountabilities, 3 artifacts and five values.  Today, we will talk about the order of the events in Scrum. 

Scrum is simple, but that simplicity means that each of its elements is essential.  The values, accountabilities, artifacts and events are all part of the framework for a reason.  Teams that mess with the framework are messing with Scrum.  Teams that make changes to the elements limit Scrum's effectiveness and aren't really using Scrum.  This article discusses some of the things in the Scrum framework teams shouldn't mess with but often do. 

With the rapid increase in the adoption of Scrum and other Agile frameworks over the past several years, I’m not surprised that a few misconceptions and myths about Scrum have surfaced.  While many more organizations embrace Scrum, many individual practitioners have not undertaken formal training.  It’s the perfect environment for misinformation and confusion.

A well-refined Product Backlog is essential for high-performing Scrum Teams.  Without it, teams will likely struggle to deliver a Done increment each Sprint.  But like all things in Scrum, we must have a balance.  So, how far out should the Product Backlog go?  

The Agile Manifesto (penned in 2001) includes four values and 12 principles that describe a new approach to complex work. Agile is an umbrella term comprising a variety of frameworks and approaches to value delivery, including Scrum.  Previously, we discussed the 12 principles included in the Agile Manifesto and how they play out in the real world.  This week, we turn our attention to each of the manifesto’s four values. 

Misconceptions about Refinement—the process of adding detail, order and size to individual Product Backlog items can be highly detrimental to a team's ability to deliver value to the business frequently. In this article, we will discuss some of the most common myths about Refinement in Scrum.

The Scrum framework comes with its own guardrails and values, but it is worth taking a moment to consider the base upon which Scrum is founded by examining the principles and values of the Agile Manifesto.  The Agile Manifesto includes four values and 12 principles that describe a better way to approach complex work.  In this article, we will discuss each of the 12 principles and what they mean in the real world.

Scrum involves a radically different mindset that involves fully embracing Empiricism, or making decisions based upon what is known. Rather than creating project plans, teams rely upon Goals to measure success. The list of the most valuable things to do next is the Product Backlog, and it is the plan, but it is an ever changing plan that evolves as more is learned.

The 2020 Scrum Guide includes five values that are important to every successful implementation of Scrum.  These values are courage, commitment, focus, openness and respect. These values don’t get much attention, but the longer I practice Scrum and coach teams, the more important I find them.  This article will outline each value and provide examples of how they play out in the real world.

Scrum uses an iterative, incremental approach to deliver value to the business through the medium of the Sprint. The purpose of each Sprint is to deliver a Done, usable increment. It sounds straightforward, but it can be tricky to achieve. Here are the three steps to Done in Scrum.

Many well-meaning Scrum practitioners have misconceptions about Scrum, which sometimes leads to creating “rules” that do not exist in the framework. In today's article, we will discuss the five of the most common misconceptions about the Sprint.

A roadmap is a complementary practice that a Scrum Team might use to forecast upcoming deliveries or to translate Product Backlog items into a visual representation. This article includes a few Roadmap templates for Product Owners to use to communicate their forecast to customers and stakeholders. Give them a try and let me know what you think in the comments section!

Last week, we talked about common misconceptions related to the Daily Scrum.  This week we’ll focus more broadly on misconceptions impacting everything from the Product Backlog to the composition of the Scrum Team itself.  

It might surprise you that even those with years of Scrum practice sometimes make statements about the framework that are, well, inaccurate. The Scrum Guide outlines how teams can learn to work together to deliver complex work. It’s not a how-to list of instructions, and perhaps that’s what leads to misinterpretation.  Last week, we discussed some of the most common, if well-meaning, misconceptions about Scrum in general.  Today, we’ll dive further into this topic with a focus on the Daily Scrum event.

​​​​​​​According to the 15th annual State of Agile Report, there has been a tremendous increase in the adoption of agile frameworks this year.  Within software teams, agile adoption grew from 37% in 2020 to 86% in 2021.  This rapid growth undoubtedly means many individuals working within agile frameworks have not undertaken formal training in it.  It’s the perfect environment for misinformation to spread.  Below are a few of the most common misconceptions about Scrum.  

Iterative, incremental delivery is critical to a successful Agile team.  Without it, Agile is really just window dressing.  Here are five examples that attempt to illustrate the concept of iterative, incremental delivery in a single image.  No example is perfect.  Let me know what you think in the comments and if you have another way to explain these concepts.

​​​​​​​As a Professional Scrum Trainer, I love working from home, but engaging with others in a remote environment can be challenging. If you’re using Scrum remotely and need stakeholder feedback to order your Product Backlog, here are a few ideas for how to gather it virtually.

​​​​​​​The Sprint Review meeting is one of the Product Owner’s most important events.  But even the most important events can become a little stale over time.  Here are five ideas to spice up your Sprint Review meeting. 

The Applying Professional Scrum class is frequently overlooked when it comes to public classes.  People tend to go for the Professional Scrum Master class or the Professional Scrum Product Owner class instead.  And those are really great classes.  That is… they’re great for those who already have an understanding of the Scrum framework.

If the Empire had used Scrum, then Darth Vader would surely have been considered the Product Owner for the Death Star.  While Darth Vader does appear to have engaged in some of the traditional activities of a Product Owner, such as stakeholder engagement, his methods and his lack of faith in the Scrum framework are… disturbing.  

Agile isn’t the right fit for every business problem–it’s simply a tool in the toolkit–one of many.

In a recent class, a student asked, “What are the common difficulties teams face when starting with Agile?”  To  answer this question, I refer to the Tuckman Model of group development. Psychologist Bruce Tuckman discussed team performance in his 1965 paper, Developmental Sequence in Small Groups, introducing the four phases of team dynamics.  He labelled these phases "forming, storming, norming, and performing.” For Agile teams, the goal of the Scrum Master or Agile coach is to get teams through the first three phases (Forming, Storming and Norming) as quickly as possible so that the team can get to Performing.  In this article, I will discuss the tools that are used at each phase of the Tuckman model to coach teams towards peak performance.

Have you ever completed a multi-billion-dollar project only to see it blow up in your face?  Twice?  If you answered yes, you’re in good company with the Galactic Empire.  The Rebel Alliance destroyed two Death Stars as well as their successor, the Starkiller Base, using similar tactics.  If the Empire had used Scrum, the Death Star might never have been destroyed at all.  

I have had the opportunity to work with some truly amazing teams that have achieved pretty amazing outcomes. One thing that every team has had in common is that, at one time, they were new to Scrum. When I engage with teams to discuss implementing the Scrum framework, they often raise potential impediments to adopting Scrum. Below are the five most common objections to Scrum and why they don’t hold any weight.

If I were to summarize the purpose of a Sprint, I would say that it’s to deliver a Done, usable increment that meets the Sprint Goal.

According to the 15th annual State of Agile report, there has been a tremendous increase in the adoption of agile frameworks over the last year. Within software teams, agile adoption grew from 37% in 2020 to 86% in 2021.

The Sprint Review is one of the most valuable events for the Product Owner, because it is an opportunity for the Scrum Team as well as stakeholders/customers to inspect what was delivered, discuss what progress has been made towards the Product Goal, and adapt accordingly. 

When I first started practicing Scrum, I thought that delivering a done, usable increment each Sprint was the least important part of the framework (spoiler alert: delivering a done, usable increment at least once per Sprint is critically important for reducing risk, enabling faster delivery of business value, reducing the accumulation of technical debt, and facilitating empiricism.)  At the time, I was the Scrum Master for a team that was building an online application, and the Product Owner did not intend to release the new application to production until it was complete.  What did it matter how we sliced up the work when a certain amount of work had to get done either way? How wrong I was.

When using the Scrum framework, the Retrospective is the final event in a Sprint. In this article, we will discuss ideas to use when planning your next Sprint Retrospective.

A Scrum team consists of three clear accountabilities: one Scrum Master, one Product Owner, and Developers.  Often, when working with a Scrum team struggling with excessive conflict or a lack of trust, I find the culprit is a lack of clarity around each of these accountabilities.  Even with the best intentions, the Product Owner can become too focused on the upcoming Sprint and not focused enough on the bigger picture.  The Scrum Master can become overly protective of the team, and the Developers - wishing only to please - can take on too much work, jeopardizing the Sprint Goal.     

The purpose of the Sprint is to deliver a ‘Done’ increment which meets the Sprint Goal.  At the Sprint Planning event, the Product Owner and the Scrum Team collaborate together to create a Sprint Goal - which describes why the Sprint is valuable - after which the Development team selects Product Backlog Items which describe what will be delivered and creates a plan for how to deliver them.  

If you’ve ever wondered whether Scrum can work for hard deadlines, the answer is – yes!  Not only can Scrum work in these situations, but in my experience, using this agile framework increases the probability of meeting challenging  deadlines.

"We need to bring the IT resource managers along," I said.  "It's important that they understand their role in ensuring the success of the product". 

Agile frameworks such as Scrum have continued to gain traction because of their ability to vastly improve business outcomes and employee engagement. Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.