Tracking Impediments during Sprint

I read that a valid output of a Daily Scrum is a list of impediments for the Scrum Master to work on. So, how are those impediments tracked for resolution?

If they are impeding the team's progress towards the Sprint Goal, might it be worth visualizing them in the Sprint Backlog?

If longer term impediments are not accounted for in the Product Backlog, would this artifact then reflect the amount of work that is truly thought to remain?

I don't see a one-size-fits-all approach for this; but one possible way of visualizing impediments would be to visualize them on the Sprint Backlog, such as by marking a particular item on the Sprint Backlog as being impeded.

If this impediment is recorded in such a way, one advantage would be it enables the Development Team to inspect the impact impediments are having on their ability to produce a releasable increment or achieve the Sprint Goal, and on certain metrics, such as the cycle time, or flow efficiency.

Would you ever expect a Development Team to not be responsible for the Sprint Backlog? If a Scrum Master is helping the Development Team to remove an impediment, when is it helpful for the Development Team to delegate the way this is achieved?

Thanks Ian and Simon.

Have you ever experienced or heard a Scrum Master using "Impediment Logs" or something similar to track impediments? I don't think every team is using Scrum the same way. It's tailored to suit the business need or product being developed.

So, would you say it should be okay if there are additional artifacts used apart from what the guide defines?

Scrum guides states team can have additional ad-hoc meetings if required. Could the same be inferred for artifacts?

We are using an Impediment Log.

In my opinion the Sprint Backlog is owned by the Development Team. I as Scrum Master am not part of the Development Team and the impediments do not have to follow the Definition of Done. Therefore in my opinion they do not belong on the Sprint Backlog.

The Impediment Backlog we are using is a small Kanban Board. Whole Scrum Team can put impediments on the board and everyone has a good overview on the status of our impediments, without having to go through the Sprint Backlog.

Most of my effort seems to be towards addressing long-term impediments, based on empirical observations of trends, rather than specific items that have been raised during the current sprint.

Tim Moeker I'm curious about your approach. Can you provide an example of the kind of impediment that would appear on the Impediment Backlog?

For impediments that would emerge at the Daily Scrum, I generally try to find ways to keep them visualized on the Sprint Backlog, and encourage Development Teams to remove or workaround such impediments themselves, and ask for specific help when it is needed.

I am careful to avoid taking sole responsibility for removal of an impediment in a way that makes the Development Team dependent on me. They need to remain responsible for measuring their own progress towards the Sprint Goal, and continuing to inspect & adapt as it is needed.

Furthermore, by having impediments visualized on the Sprint Backlog (by virtue of flagging – and adding a note to – the impeded item), the Development Team will later be in a position to identify its most severe ongoing impediments, and the impact they're having.

Tim Moeker I'm curious about your approach. Can you provide an example of the kind of impediment that would appear on the Impediment Backlog?

@Simon Mayer: You name impediments the Dev Team can solve themselves. Those will stay with the Dev Team within the sprint. Those are mainly brought up in the Daily and in most cases another member of the DevTeam can support.

But in some cases, and yes, the number is quite small, we have impediments where single team members are blocked and I jump in to help. For example if they do not get access to one of the tools we are using from another organization within our company. Or if we discuss during a daily or in the Retro that one of the templates could be enhanced.

I know, the DevTeam shall be self-organizing, but I also understand my role as SM to remove impediments to their progress. Therefore I took over the ownership of our templates and I take care about access and so on, so that the DevTeam can concentrate on making progress towards the Sprint Goal and do not need to spend time with such things.