Agile Risk and Issue management & reporting

I have worked in many places as an agile coach, delivery manager and agile project manager where teams do the maintenance of the product backlog and product delivery effectively, but when it comes to the more “project management” activities there are sometimes tendencies to use more waterfall techniques that are less suitable to agile.

I explain here a simple way of using agile techniques to talk about project delivery risk and to have a common language that both the team and stakeholders can use, and which can be automated easily into a dashboard so that automated management can be supported.

I believe that much of the work of management reporting should be automated, so that like automated testing it can be scaled and accomplished with the minimum of effort – thus creating time for people to solve more difficult problems.

Minimum scope

Start with the agreed scope you need to deliver. The chart below represents the Minimum Viable Product (personally I prefer Minimum Valuable Product). If you were doing DSDM you could have additional lines on top representing the “should” and “could” scope if you wanted. However this line represents what we must deliver.

It starts with zero and during setup, scope gets added to the backlog. As we progress, some additional scope might get added (aka “scope creep”). I’ve shown it being added here for the purposes of the example, however in agile we try to maximise the work not done, so sometimes this line goes down if a different approach is found that has less storypoints.

High estimate of scope

Then we assume a bit of variance. You might have a stakeholders wanting functionality or maybe an early prototype with feedback from users adds some scope to the backlog.

I’ve also assumed that we’re 4 sprints in and trying to forecast when the MVP will be able to deliver business value. The top line shows the scope required if there isn’t much control over the backlog and the lower line shows a more conservative level of scope creep. Remember also that these are simply illustrations! The ideal is that the MVP scope does not go up! I’m using increasing lines to show how it impacts on delivery.

Work done, conservative estimate

Now we bring in our line showing work done. From Sprint 4 onwards, this is a future projection based on past performance and what’s left on the backlog.

Work done, aggressive estimate

Finally there is the work done projected forwards if there is an optimistic delivery velocity, e.g. by removing impediments.

The delivery window

The delivery window is then the time window calculated from the intersection of the four projections as shown below

This gives you a delivery window ranging from optimistic scope and delivery velocity (early delivery) to pessimistic scope and delivery velocity (later delivery).

Using this, you can then report red if your desired delivery date is before the potential delivery window, amber if the desired delivery date is in the potential delivery window and green if the desired delivery date is after the potential delivery window.

This can appear on a dashboard or more creatively I have seen LEDs wired up round the office windows which change colour according to build status or project status to make it more visible and fun.

Knowing the forecast delivery window then lets you forecast operational cost to deliver the project or service and this helps inform high level risk/issue discussions.

Risks and issues at the team level

At the more detailed level of individual risks and issues, I would avoid the defaults preferred in Microsoft environments of a big excel spreadsheet in SharePoint. This is wrong on so many levels. It’s wrong because only one person can update the risks at any one time and so it doesn’t encourage distributing the work – often it ends up that the project manager or scrum master takes this responsibility.

It is more agile to look at risks and issues as problems that are impacting or could impact on velocity and successful delivery. In that way they aren’t much different to technical debt and I would consider technical debt to be a class of issue. Identifying risks and issues should be led by the development team.

For individual risks and issues, it is better to discuss and track these in a similar way to user stories – e.g. post-its on a wall or as individual items in your backlog if you are using a tool. This means they can be worked on and updated individually rather than being all stuck in the same spreadsheet.

If your team is also doing live support then the issue management system for live support issues might be another possibility. The prioritisation of risks and issues is a likely to be led by the Product Owner with the actions treated in the same way as impediments – the Scrum Master has the responsibility for removing the risks and issues in order that the Product Owner’s objectives can be met.

As part of sprint planning the risks and issues can be discussed and prioritised into the sprint for resolution. In order to get a view of total risk/issue exposure then a dashboard of all the risks summed or all the issues summed against a metric may help the team visualise the risk/issue trends. This is mentioned in the Mike Cohn article below.

I hope you have found this useful, comments always welcome.

Further reading

1. Mike Cohn Managing Risk on Agile Projects with the Risk Burndown Chart
2. Managing Agile Risk (Dummies guide)
   

Read more by Craig Cockburn, here

Arrange a Conversation