Some signs of an underperforming scrum team are obvious — like failing to complete User Stories within a Sprint. Other examples are harder to see at first glance. In this article, I will explore some common examples of underperformance, find the root cause, and propose remedies that you can use in your own Agile practice.

1. Incomplete User Stories

One glaring example of Scrum team dysfunction is when user stories regularly roll over from sprint to sprint. While it’s normal for this to happen occasionally, if it happens every Sprint you may have a problem. 

(Note: Stories do not automatically rollover to the next sprint. Each sprint backlog should be evaluated in context, and a proactive decision should be made whether to include an incomplete story from a previous sprint into an upcoming sprint.)

When stories are routinely incomplete, several factors could be at play. 

  • Was an impediment not addressed by the team or the Scrum Master?
  • Has the team overestimated their ability to complete work?
  • Is the team using prior sprint velocity to help plan their upcoming sprint capacity?
  • Does the Definition of Ready adequately describe what needs to be true for a story to be taken into a sprint? For example, I’ve seen situations where the Definition of Ready requires test data that is unavailable so the story ends up rollingover into a subsequent sprint.

2. Only the Scrum Master Can Move Stories and Tasks

On several occasions when I have taken over an underperforming scrum team, a team member has asked me to move a story to another state on the board during the daily Scrum. When I asked why they didn’t just do it themselves, they answered, “The previous Scrum Master always did it.”

Whenever I hear this, I think about SAFe Lean-Agile Principal #8: Unlock the Intrinsic Motivation of Knowledge Workers.

If you are doing the work, you are empowered to track progress on whatever tool you are using. 

3. Silo Mentality

When I was a submarine officer, I spent some time in the shipyard. I recall an occasion when there were some paint cans left in a passageway, and I asked a shipyard worker to move them. His reply was, “I can’t do that. Those are paint cans, and I’m an electrician.” Those were union rules, so I got a sailor to move them, but my point is that the silo mentality is much like the union mentality. “It’s not my job.” 

On an empowered scrum team, all team members should be looking for opportunities to complete the sprint, even if that means that they have to do something that is not within their normal job description. 

4. Unempowered Product Owner

“Let me ask.” If that’s the answer you get on a regular basis from your Product Owner, they may not have the authority they need to do their job. 

If you hear this occurring, it’s time to raise that at a Scrum of Scrums or through the leadership team. It’s possible that leadership is unaware of the issue or has not granted permission for the Product Owner to make decisions. In either case, you need to help solve that problem to build a high performing team.

5. Post-Release Defects 

Does your team have “Defect Thursday” after every release to fix the bugs that were introduced the previous week? Is your team backlog made up of so many defects that your Product Owner has trouble adding new stories to the backlog? These are signs of an underperforming team. In my experience, several factors can combine to introduce excessive defects:

  • Pressure to deliver “on schedule” leads to insufficient testing.
  • Pressure to deliver “on schedule” leads to hand off of code for QA before it’s ready.
  • Inadequate story refinement or poorly understood acceptance criteria leads to wasted effort and re-work.

Improving Through the Power of the Retrospective

One method I’ve often used to help teams improve comes from the power of the Retrospective. A retrospective is a tool of empowerment: Teams discover — and solve — the problems themselves. As a Scrum Master, your job is to guide the teams through the retrospective and help them solve the problem on their own. 

To make sure the results of the retrospective stick, I recommend following the Rule of Three. Coming out of a retrospective, your team may come up with a long list of solutions. Rather than trying to tackle all of them at once, ask them to prioritize the Top 3 so they can focus on those before moving on to others. 

Once the team has identified the top areas of improvement, add them to the backlog and make sure they are completed during the upcoming sprint.