Adding Blockers to Your Backlog? Always Include a Specific Next Step

A pet peeve of mine is when progress on a story is blocked with a reason like: “Need code sample to add live chat feature.” Or: “Don’t have VPN access.” What needs to happen next? Does someone know they need to help unblock this? I’m sure I’m not the only one who would be wondering these same questions.

Including a specific next step and a due date fixes this. Then we have clarity on what’s next.

There are three things I like to include in the text of a blocker.

1. The date it was created.
2. What the next step is, and who is taking it.
3. When the next step is due.

1. Add a date that the story got blocked.

If nothing else, I like to include what date the blocker was added. This information helps others understand if it’s a recent blocker (which might mean it’s a lower risk or being worked on) or something that was blocked a long time ago (and was forgotten or no longer applies).

Some tools may automatically include the date in the blocker. Regardless of this, I prefer to include it in the blocker text itself to keep it in your face.

• “2020-01-23 Need code sample to add live chat feature”
• “2018-12-15 Don’t have VPN access”
• “2019-02-03 No design attached”

In these examples, perhaps one could infer that VPN access was never really required since two years have gone by with no impact.

2. Articulate the specific next step and responsible party.

This is the most important part of the blocker: what comes next, and who is doing it?

• “2020-01-23 Need code sample to add live chat feature. Bob is getting the sample for us.”
• “2018-12-15 Don’t have VPN access. Phil will ask the security team.”
• “2019-02-03 No design attached. Micah will call Brian and check on the design.”

In these examples, it’s clear what needs to happen next and who is following up. Without this, there’s no accountability for anything getting done (unless we get lucky, but we generally prefer not to count on that).

Sometimes it isn’t exactly known what the next step is. In these cases, there’s usually someone who can help. Here I recommend naming who to follow up with, e.g. “2020-01-04 Not sure what is needed to make this compile. Will check with Dan for suggestions on what to try next.”

3. Add a due date to the next step.

The best blockers include a date we can expect an update.

• “2020-01-23 Need code sample to add live chat feature. Bob is getting the sample for us by 2020-01-30.”
• “2018-12-15 Don’t have VPN access. Phil will ask the security team on Dec 19.”
• “2019-02-03 No design attached. Micah will call Brian and check on the design. We should hear more by Feb 10.”

These are well-made blockers. They are clear about what needs to happen next, who’s following up, and when an update is due.

Another benefit is these blockers help us act as players instead of victims. A victim would say, “Well I guess I can’t do anything because I never got VPN access.” But with more information, I can be a player and say, “Hmm, no VPN access yet; looks like I should check with Phil.”

I hope the above format for blockers is helpful. Including a clear next step goes a long way in alleviating frustration and disappointment.