Scrum is great at handling immediate issues or in this case, they’re more commonly referred to as ‘Impediments’.  The delivery team raises issues daily via the Daily Scrum. After the daily Scrum, the team (supported by the Scrum Master) runs around clearing impediments so to give them team the best chance of delivering their sprint objectives.

Some teams like to keep track of all of these impediments by using an Issues Snake or an Issues Calendar.  These two approaches aren’t dissimilar, however an Issues Calendar introduces the concept of ‘time’ into the equation.

This works as follows: Every time an issue is raised at the Daily Scrum, you write it on a post-it and place it somewhere visible.

If the same issue is raised more than once, you add another post-it-note to the board. This helps to keep track of blockages and disruptions and can be used to drive conversation at the end-of-sprint Retrospective or at the end-of-sprint Review.  This approach also helps you to quickly identify re-occuring issues/blockages.

In more traditional working environments, there is a tendancy to hide issues from stakeholders – we want them to think everything is perfect. This is different in an Agile environment. Stakeholders should know if the team has gone above and beyond to deliver a sprint – highlight this in the end-of-sprint Review. Also, it may be that the stakeholders can help to manage impediments by either actively removing them or by highlighting ways to mitigate the impact.

Issues Calendars are particularly useful as you can compare them to the team burndown to better understand velocity variances e.g. ‘the team burndown suffered on that day as they were dealing with a particularly hefty impediment.’

Unlike the traditional approach, the severity of an issue is not captured in writing – unless someone wants to add an ‘!’ or a personal note to stress the urgency/impact – this does happen sometimes ;o).  Fact is that communication is really strong in a Scrum environment, so if there’s a problem – we know about it.

Issues Snake

The only other piece of information that I’ve ever collected (since ‘going Agile’) is the length of time that teams are being actively ‘blocked’ by an issue. The Scrum Master made a note of the time the issue was logged and recorded the time the issue was closed – all of this data plus the issue itself was stored electronically as well as on the whiteboard. This really works for some people – they use it as Retrospective fodder. With that said, we don’t do this anymore as we’re happy just using an Issues Calendar.

As I mentioned earlier, Scrum is great at handling immediate issues. By this I mean issues that are affecting the active Sprint. Scrum does not offer a way to manage portfolio-level or programme-level issues which exist beyond the active sprint.

We manage programme-level issues using an Epic Board. All major deliverables are up on the board. If there’s an issue or a risk associated with a distant deliverable or with a particular sprint/date, we just add a post-it-note to the board e.g. stick it to a story card.  We also add post-it-notes to represent decision points/mitigating actions that need to be taken at a particular date in the future.

The key differences between Agile and Traditional issue management techniques are:

• Agile Issue Management is built into the delivery process- e.g. Daily Scrum
• The Team works together to raise and clear issues
• Documentation is kept to a minimum – all energy is put into clearing the issue
• The team regularly reviews their issue managment approach in hopes to improve their handling techniques

Subscribe to the Agile101 RSS to be notified when I upload new Articles, Videos, Templates and Tips!

Related Articles:

• Agile Risk Management – The difference between Risks and Issues (agile101)
• Agile Risk Management for Projects and Programmes (agile101)