Managing RAID logs with Scrum

Agile project management methodologies such as Scrum go a long way towards reducing risks through frequent releases, and reducing assumptions through learning from these releases. Nevertheless, there are many reasons why a project manager may want to maintain a RAID log.

The good news is that RAID logs and Scrum are not mutually exclusive - the two can work well side by side to meet the needs of your team. As always with agile methods, the processes should be continuously reviewed and refined to work for your specific team and circumstances, but we’ve outlined some suggestions below:

Stand ups

The stand up is a short daily meeting (traditionally run with all team members standing up) for the team to discuss and plan the day's work. As a part of this, typically team members will raise any blockers: impediments or challenges that may prevent them from achieving their goals for the day. Keeping an ear out for these blockers is a great way of identifying dependencies that could be worth recording on your RAID log - sometimes team members won't recognise dependencies until they are actively blocking them.

Retrospectives

Retrospectives are the team's opportunity to reflect the sprint that just finished, and discuss what did and did not go well. Areas for improvement are raised, with the team discussing how these improvements can be implemented in the following sprint. Similar to how stand ups can identify dependencies, retrospectives can help spot risks or issues that are relevant to the wider project context and worth recording on the RAID log.

Using the backlog

The Product Backlog is the list of work needed to be done on the product by the Scrum team, ordered in priority order. The Scrum methodology says that the backlog is the single source of this work, and so when work items arise from the RAID log that need to be carried out by the team, it's a good idea to put these onto the backlog. By keeping integrated with the Scrum processes in this way, the work items can be prioritised alongside other work and carried out in the relevant sprint as a result of its place in the priority order. Examples of backlog items we've seen coming out of RAID logs are:

Work needed to mitigate a risk
Action points to address an ongoing issue
Migration tasks to move away from a dependency that is jeopardising the project

Developing software in an agile way helps to reduce risk, but that doesn't mean it's not worth documenting those risks clearly. It's important to note that the fast paced and changing nature of an agile project, means it's paramount that the RAID log is diligently kept up to date to ensure that entries are still relevant given new information, requirements, or a pivot in approach.