Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
At our standup, I always ask about blockers and impediments and sometimes this results in other members of the team offering help. Sometimes it turns into a rant which isn’t terrible but does encourage a defeatist attitude in the team. Currently we don’t have an impediment log as the team can’t see the value in it and I am not sure what purpose it serves outside of making a list of excuses for stuff being late.
How do others handle impediments and blockers reported at standups?
How do others handle impediments and blockers reported at standups?
If they are simple then the team decides on an approach in the standup.
If they are a little more complex, two or more members of the team may decide to have a separate discussion to go into the problem in more detail and then decide on an approach. This happens outside of the standup.
If they are complex and don't block progress in the current sprint then we bring them to the retrospective and look to find a solution there. If we don't find a solution in the retrospective we may escalate them to management.
The focus is always on finding solutions. By doing this we give the team members a feeling that things are getting better, even if not every problem gets solved immediately.
Keeping track of impediments and/or improvement opportunities is a good idea, but it's also a long-term solution.
At your standup, one of the priorities should be to identify blocked or impeded work and, as a team, make plans on how to get it unblocked and done. Using flow metrics, primarily looking at your SLEs or expected cycle time for work against the work item age is one way to find blocked work. Sometimes, the people on the team doing the work may find they are running into problems and can raise them. Since standups should be short, it's good to avoid ranting or trying to figure out long-term solutions.
I have found that having an improvement backlog is useful, and one thing on this improvement backlog can be impediments. Whenever something impedes work, add it to the list or mark that an impediment has occurred again. Use this list at your retrospectives or schedule frequently occurring impediments for root cause analysis. Decompose those impediments and consider other ideas for improvements and schedule time for the team to understand and make changes to their way of working to address them.
I do think it's important to separate things that are "just go do it" from work that needs to be understood and scheduled. The immediate steps to get blocked work done is "just go do it" work - there's no need to put it on a backlog or impediment list or anything else. But longer term improvements may need consideration to understand their impact or will require work from one or more people on the team to design and implement, so you'll want to plan those with all of the other work being done by the team.
If you don't act on finding and preventing root causes of impediments or considering and enacting improvements, then any impediment or improvement backlog is just waste.
Currently we don’t have an impediment log as the team can’t see the value in it and I am not sure what purpose it serves outside of making a list of excuses for stuff being late.
There's no such thing as an "impediment log" in Scrum. I mean, you could have one if you really want to, but it's not an artifact that's part of the defined framework.
"Blockers and impediments" is really a holdover phrase from legacy versions of the Scrum Guide. The Daily Scrum is meant for the Developers to coordinate their work for the day, so the point is really to call out any required inputs or action items required for the Developers to do something with whatever part of the Sprint Backlog the Developers will be working on that day.
If Alice is planning to embiggen a widget today, but Bob hasn't finished checking the widget embiggener into source control yet, then this will impact the current day's plan. That's something that should be brought up, and either quickly addressed or a follow-up meeting after the Daily Scrum to discuss it should be planned.
Walking a task board, updating the Sprint Backlog in real time, pulling status on the Sprint Plan, or anything other than letting the Developers ask one another "How can we work together today to make progress towards the Sprint Goal?" should be noted for later discussion or action outside the Daily Scrum. As the Scrum Master, you should facilitate the team's focus on the goal of the event. You can even track items that need follow-up after the meeting or noting things worth discussing during the next Sprint Retrospective without interrupting the flow of the Daily Scrum; just remember that you're there in a faciliation/support role, and that the meeting is for the Developers and not for you.
