As I talked about in this earlier video on standups, the work on our board can loosely be grouped into three categories. It’s either active, blocked, or stalled. We tend to spend a lot of time talking about the active and blocked work and have a tendency to forget about the rest, which results in stalled work aging unnecessarily. That in turn will make the overall system less effective and less predictable.
Let’s revisit first, what we considered stalled. This is work that isn’t actually blocked - we could work on if only we had enough time to do that, yet for whatever reason, we aren’t. Our attention is focused on other things and this work just sits there and continues to age.
Let’s look at some reasons why work becomes stalled.
- Failure of teamwork. We aren’t collaborating on work as a group and each person just starts new work as things became blocked, rather than helping someone else. As some things become unblocked on their own, we now have too many things in progress (WIP) and just can’t work on all of them at the same time.
- Failure to effectively prioritize. We started something that really wasn’t the most important thing we could have worked on and now other things are vying for our attention that are more important so we switch our attention to those and ignore the originals.
- Failure to quit1 when the work has been deemed no longer important. Once something is on the board, it should be more important than anything that hasn’t yet started yet. If external priorities have shifted and this work is no longer important then we should cancel it. Instead we struggle with the notion of quitting and want to keep the work on the board, well past the time we should have let go of it.
- Failure to talk about stalled work during standup2, where we talk about what people are doing rather than about the work. When we only talk about the people, we deliberately ignore anything that isn’t being actively worked on and so things quickly become stalled.
- Failure to adhere to pull policies. We are pushing work onto the board, rather than allowing work to be pulled when capacity is available. This can sometimes be caused by classes of service, such as expedited work.
As you can see, a work item becoming stalled indicates some kind of failure in our process so you may be shocked to discover that it’s common to find teams where more than half of all the work on the board is stalled at any given time. I’ve seen teams where more than 90% of the work was regularly stalled.
How do we reduce the amount of stalled work?
We should start with the items above.
- Reduce the overall WIP. Have fewer things in progress.
- Work together as a team and help others with work already started before starting something new.
- Ruthlessly cancel any work that we’ve determined is no longer important and finish everything else.
- Make sure we talk about every piece of work that has started, during standup and not just the items that are active or blocked.
- Eliminate classes of service wherever possible.
- Adhere to pull policies and only start new work as we have capacity.
In addition to that, some teams find it useful to visualize stalled work so that it’s more obvious when we have a problem. The screenshot above is from the JiraMetrics tool that can create reports from Jira3. This can be a way to show how much is stalled and also which ones.
Side note: If you’re building reporting to show stalled then you have to decide exactly how to determine that. My reports consider something stalled if there has been no activity in your ticketing system in five days. That means no comments, no status changes, no updates of any kind.
I’ve helped teams customize their tooling to highlight stalled work in different colours. In Jira3, you would do this from the board configuration, where you can customize the colours by a JQL query as shown in this screenshot. In this case, we’re using the JQL updated <= -5d to mark the ticket orange if there has been no activity in the last five days.
The presence of stalled work is feedback to us that something has gone wrong in our process. Now, we have to take action on that feedback to make the system better.
-
“Quit: The Power of Knowing When to Walk Away” by Annie Duke covers this topic in far greater depth than I can do here. ↩
-
This article walks through how we can improve our standups. ↩
-
Why do I tend to give Jira examples and not other tools? Because it’s what almost every one of my clients uses and so I’m more familiar with it than with other tools. ↩ ↩2