Update the Board!

Todd recently received this email from a former student:

Hi,

I’m new to being a Scrum master and I notice that our developers are typically not updating their sprint tasks. Oftentimes, I badger them to update their tickets, but they won’t. So when we get to the sprint review, at first glance, it looks like they haven’t completed any work, even if that isn’t true. Do you have any advice on how to motivate people to update their tickets?

Can you relate to this Scrum master? Have you ever felt like you were the Scrum police, chasing after developers, begging them to update Jira? We certainly have. But is the development team the problem in this scenario, or are we?

Remember that the development team owns the sprint backlog. As we discussed in the last section, there can be a lot of volatility in the sprint backlog as the Scrum team learns about the product, and because the developers may find unexpected work as the project is underway. It’s up to the development team to find ways to make that volatility transparent.

Joe asks:

Who updates the sprint backlog?

Anyone on the development team can update the sprint backlog. No one outside of the dev team should update the sprint backlog—not even you, the Scrum master.

You can help the development team by emphasizing the importance of creating transparency in the sprint backlog. Here are some reasons why it’s important that the dev team make the sprint backlog transparent to the entire Scrum team:

• During the daily scrum, a transparent sprint backlog helps the development team see how much progress they’ve made toward achieving the sprint goal.

• It lets everyone on the Scrum team knows where things stand.

• It provides a way to identify potential impediments to completing the sprint goal.

• It’s a useful way for dev team members with different skill sets to coordinate work.

• It helps keep dev team members from getting interrupted by status questions from other developers and folks outside the Scrum team.

• It builds trust between the Scrum team and the rest of the organization.

As Scrum masters, we’ve made the mistake of harassing dev team members to update the sprint backlog more than we care to admit. We’ve even taken it upon ourselves to do the updating. But doing that actually makes the sprint backlog less transparent: It becomes a status board that’s owned by the Scrum master rather than the development team. This negatively impacts the dev team’s ability to self-organize because they have less ownership of their work.

Ryan used to update the sprint backlog for one of his teams but, after seeing some of the negative impacts we just described, he quit cold turkey. At first, the development team didn’t seem to care, but they gradually started having problems with forecasting and answering basic questions that were coming up during Scrum events (specifically, the daily scrum and sprint review). With time and practice, the development team learned how to own and manage the work in their sprint backlog and started to communicate better with the product owner and stakeholders.

Here’s the big takeaway from this scenario: We make an implicit deal in Scrum. The product owner agrees that the development team can focus during a sprint and not get pulled into countless status meetings—as long as the development team keeps their work and progress transparent. Ultimately, it’s a win-win for everyone.

When you’re faced with a development team that isn’t updating their sprint backlog, ask yourself these questions:

• Are you asking the dev team to update the sprint backlog just for the sake of updating it?

• Is the development team gelling and working well as a team?

• Are you asking them to update the sprint backlog because stakeholders are demanding info from you about the dev team’s work?

• Does the dev team understand the importance of creating transparency in the sprint backlog?

• Is the development team afraid of what could happen if their work is made transparent for everyone to see?

Why this self-reflection? When we’ve gotten irritated about our team not updating the product backlog, we’ve often found that it’s driven by us wanting to feel as though we’re appropriately serving the dev team. Although we had good intentions, by acting as the Scrum police, we ended up inhibiting the dev team’s progress. In some instances, stakeholders were pestering us to provide status reports because they were still used to the old, pre-Scrum way of doing things. We realized that we were harassing the dev team for updates because we were worried about our own jobs, not about the well-being of the dev team.

Figure out what’s driving your behavior and bring it up in the next retrospective. Be open (a Scrum value!) and explain to the Scrum team what’s causing you to feel this way. Facilitate a broader discussion about the importance of creating transparency in the sprint backlog, and talk about the importance of the dev team owning the sprint backlog. Solicit feedback from the Scrum team and find a new approach that you can try during the next sprint. Although this conversation may not be easy, you’ll likely be pleasantly surprised at the positive impact it has.

If you’re a Scrum master who’s currently struggling to get your development team to keep their sprint backlog up to date, ask the team two key questions, either at the end of or immediately following the daily scrum:

• What did we learn over the last 24 hours that could change our current plan?

• How can we update the plan with that new knowledge while keeping the sprint goal intact?

By reframing the task of “keeping the board updated” as an opportunity to reflect on what we’ve learned and how it impacts the Scrum team’s progress toward the sprint goal, you can help shift the dev team’s behavior toward more transparency.