The Sprint’s Almost Over and the Scrum Team is Sitting on Their Hands (You Think)

Find me on: LinkedIn Twitter

In my experience, Scrum teams are rarely, if ever, “sitting on their hands.”

Lack of visible progress can stem from multiple factors, none of them good when you’re facing deadlines and expectations. Remember that it’s your job as a manager outside the Scrum team to understand the obstacles they might not be able to see or to address themselves…and to help get them out of their way. I covered this topic in depth recently with articles on leadership in Scrum and why managers must be trainers, coaches, mentors, and therapists.

So what do you do when the team is running out of time and you feel like progress has stalled? Here are several reasons why that situation occurs and what you can – and should – do about it.

They’re waiting for a decision or direction

Sometimes progress stalls when the development team needs critical guidance or direction from the business. There are so many things that can impact the team this way: strategic decisions that need to be made, approval of tools or expenditures, and the clarification of unexpected details are just a few of them.

Since the team is responsible for making sure progress continues, they’re likely doing their best to get the information they need to push things forward. But sometimes they face roadblocks they can’t clear themselves, whether it’s due to them being lower in the organizational food chain or some other reason. They may need your help.

Waiting for these responses can create bottlenecks, rendering members of the team idle or adversely affecting the sprint’s schedule. Whatever the reasons for it – travel, workloads, indecision, politics – you can help shield your team from these kinds of delays. If you see the team hitting a brick wall, ask them what you can do to help. Never just jump in and take control, or you take ownership of both the problems and the results away from them. Offer to step in and escalate issues as they arise or obtain answers quickly before they put undue burdens and delays on the team.

They’re stuck on a technical challenge

Sometimes progress stalls when the team is stuck on a technical challenge that proved more difficult than they expected. If not managed properly, everything else can spiral into a holding pattern while that one issue is resolved.

The team will work diligently on the problem, but when you see they’re getting stuck, the first thing you can do is listen in to their next daily standup. Listen to find out if they have an imminent solution or not.

If a solution is not readily apparent, how quickly could you enlist outside expertise to consult with them? Again, you should always ask the team what you can do to help. Offer to line up some expertise. They might be close to a solution and decline the assistance, but knowing they can “phone a friend” if they continue to get stuck can be a big help.

They’re missing an important person or resource

Sometimes progress stalls because the team is short-handed or missing a tool that would make their jobs easier. On the personnel front, a specific set of skills might be lacking within the team. If you keep hearing that the team can’t figure things out or they complain about lack of someone who can “do X,” be sure to listen and engage with the team. Talk to them about the skills they’re missing. Ask the team members to think about what the “perfect” team might look like and discuss how the team makeup could be adjusted.

Adding resources who can provide those missing skills—even if they’re just part-time helpers—can give the team a huge boost. And always encourage the team to consider changing team members as needed between sprints, not during one.

On the physical resource front, are there tools the team was expecting that have not materialized due to a procurement problem? Or tools that would make the work go more smoothly that the team keeps talking about but perhaps they don’t think there’s funding for them? If so, you can escalate and help procure those tools for them.

They’re underestimating the work

Sometimes progress stalls because the team underestimated the work involved. This will happen occasionally, but if you notice it’s a repeating pattern at every sprint review, it may be time to ask some probing questions.

You might need to step up the level to which you hold the team accountable. After all, theyare the ones making the decisions on how to do it and providing the estimates. As long as they are properly empowered to do their own work (and not constrained from doing so by outside influences), they are responsible for their results.

This may take the form of encouraging the team to be a little more conservative during their next sprint planning. And make sure they know that you expect them to not only make a commitment, but also to do their best to stick to it. Sprint review after sprint review with incomplete items is not going to build the team’s confidence – or your trust. They should know that you would like to see them start hitting their commitments.

One way to help a team improve their estimates is to provide additional training. We offer a free webinar, Always Ship On Time, that explores Agile estimating and planning techniques to help the team successfully create their estimated schedules.

They’re not getting their user stories right

Sometimes, progress stalls not because the estimates are wrong, but because the user stories themselves are slightly off. When user stories are not clear enough, for example, your development team could present a completed feature only to have the product owner say, “No… that’s not what I wanted.” This creates a lot of churn as the development team tries to make the product owner happy – especially when the expected solution remains unclear.

Another issue occurs when user stories are too big. Sometimes a team will try to fit too much of one feature into a single sprint. What happens is that some members of the team run out of things to work on because the sprint included too much of one kind of task and not enough of others. We’ve found that planning a minimum of three to four stories per sprint works best, allowing the team to divide and conquer without some members getting “stuck”. For more information on how to get user stories to the right size, check out our free Splitting Epics and User Stories webinar.

Help Get Your Scrum Team Moving

No matter what you determine the underlying problem to be, the most important thing is to help get the team moving again. Whether that means delivering an answer, finding a resource, or fixing a breakdown in your Scrum process doesn’t matter. You need to help get it done.

If you feel like your Scrum team could use some help, whether to get Scrum questions answered or for additional training, please let us know. Our expert Scrum coaches would be more than happy to help. Just contact us to start the conversation.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *