Friday, 29 July 2016

Risks, Assumptions, Issues and Dependencies (RAID)

This post is about a tool that is useful to have when doing Release Planning.

During Sprint or Release Planning it is useful to capture any Risks, Assumptions, Issues and Dependencies that we identify during the planning, that might impact the successful execution of the plan. A RAID diagram is useful for this.

Setup 4 flipcharts on the wall, where the team can capture Risks, Assumptions, Issues and Dependencies.


A risk is something that might happen. Should it happen it will have an adverse impact on the success of our project. Risks should be discussed openly by the team. We need to evaluate how likely they are to happen and what mitigation actions should we put in place to avoid or to counter them.

Here is some good advice for managing risk

Examples: There is a transport strike looming for the next number of weeks, so it will be difficult for people to get to the office. Peter is doing maintenance on an other high priority project; he might get pulled on a regular basis from this project if there are issues for the customer.


An assumption is something that we think is true or likely to be true and we rely on it being true to successfully delivery our project. Assumptions should be tested as early as possible during the execution of the plan.

Examples: To cause least disruption, 21:30 is when we think we have least number of users on line so it's the best time to upgrade our system daily.


An issue is something that is causing us a significant problem today and prevents us from succeeding in our project. The main difference between Issues and Risks, is that Issues are a certainty today. Issues need to be dealt with all the time. It's important that an owner is identified and a strategy for dealing with the issue is agreed. Can we resolve the issue ourselves? Do we need outside help? Can we avoid the issue altogether?

Examples Issues: We have scalability problem after 10, 000 connections to the database. Mary, the principle tester, is going on 2 months extended leave for July and August.


Something that must be delivered before we deliver our project. Dependencies must be managed and monitored. How are we going to make progress while we wait for this dependency? If dependencies run late, how will that effect our delivery? Can we minimise that impact?

For example: We are using a beta version of our platform for development, and it's due to be officially released 6 weeks before we go live.

No comments:

Post a Comment