What exactly are impediments? Impediments in Scrum are “blockers” that prevent your team from completing the work, which impacts sprint velocity or the business values to be delivered. Anything that prohibits the team from working on the user story is considered to be an impediment and should be tracked. Common examples of impediments in Scrum are dependencies on external parties, stakeholder issues, unavailable Scrum Team members.
All identified impediments should be included in the impediment log. The Scrum Master is responsible to track and ensure that impediments are removed. All members in the Scrum Team are responsible for identifying and flagging these impediments during the Daily Standup. The Sprint Retrospective is the other avenue for impediments to be identified. Even though the Scrum Master owns the impediment log, he/she is not solely responsible for removing all impediments. Instead the Scrum Team, being self-managing, should work together to remove the impediments. The Scrum Master should be there to provide the necessary coaching and assistance that may be needed.
The size of an impediment often depends on when it is surfaced by the Scrum Team. Usually impediments identified during the daily standup are usually small and easy to resolve. This may include replacing a faulty workstation or seeking help from a fellow team member. Larger impediments are usually raised during the Sprint Retrospectives and unable to be addressed quickly. These impediments are added to the Product Backlog to be addressed in later sprints.
There could be a couple of ways that an impediment log exists. I’ll share in this article two ways which I find useful in tracking impediments. Regardless which way you prefer, the rule of thumb is there should only be a single impediment log that the Scrum Master is managing. Simply put, there needs to be a single source of truth.
Google Sheets / Microsoft Excel
Most organisations use either Google Sheets or Microsoft Excel and hence these are free and easily available tools that you can depend on to create your tracker. The list below shows the fields for an impediments log:
- Impediment Description: Describes what the impediment is
- Priority: How urgent (Critical, High, Medium, Low) it is to remove the impediment
- Action Needed: What needs to be done to remove the impediment
- Owner: Who owns removing the impediment
- Create Date: When the impediment was identified
- Due Date: When do we need the impediment to be removed by
For Jira users, the impediments can be tracked as part of the user stories. You can easily do that by creating a subtask in the impacted story to capture the details of the impediments. Then use links such as “blocked by” to indicate that the story is unable to proceed unless this impediment is removed.
To fully benefit from this feature, you would need your Jira administrator to add the “sub task blocking” function to the workflow to disallow a story from closing if any of its subtasks is still open.
For those who prefer a more visual way for the open impediments to be glaring them for attention. To flag a story, simply click on the “Actions” ellipsis at the top right of your ticket and click “Add flag”. The card of a flagged story will be displayed in yellow in the Scrum backlog and Active sprints of your Scrum board.
To search for stories with open impediments, you can use the JQL query “Flagged[Checkboxes]” = Impediment to filter out all flagged stories.
Due to different possible contexts, there is no hard and fast rule on how the Scrum Master’s tracking of impediments have an impact on the Scrum team. It is important for the Scrum Master to closely monitor and remove impediments and blockers for the Scrum Team to be successful.
I hope this article is helpful. If you have other ideas around tracking of impediments, please share them in the comments below!