What qualifies as a risk in agile? Do we need to differentiate between “classic” risks that we’d expect to log and monitor in a risk register, as opposed to risks that are based on observations of a release backlog or team’s iteration?

Being aware of risk is good project management common sense. There are articles that suggest monitoring risks using a burndown approach, but I think there is one key aspect missing from this strategy: having clear, planned, agreed-upon, communicated responses.

PRINCE2 (an acronym for PRojects IN Controlled Environments) is a process-based method for consistent project management used all over the world. This approach explains how to define and identify risks, but it also provides a useful way to assess risks. Assessing risks generally involves assigning a likelihood, impact, and proximity. PRINCE2 recommends that each risk has a plan with outlined possible responses, such as avoid, reduce, fall back, transfer, and accept.

To avoid a risk means decreasing scope in some way so that the risk is no longer relevant. The reduce option requires some action to lessen the impact of the risk. Fall back is a response to prepare some plan that will be implemented if the risk strikes. Transfer is finding a way to change the focus of the risk, and accept means making a conscious decision to allow the risk to happen.

Depending on the chosen response, you could expect the risk to vary over time in different ways. For example, if the chosen response is to avoid, you should expect the risk to decrease at the point that decision is made. The reduce response will result in the risk being reduced at the cost of some additional work. The fall back tactic probably won’t reduce the risk immediately, but it may add some preparation activity to the backlog. The transfer response may result in a change to your or another team’s backlog in order to shift the risk. And because the accept response is a conscious decision to allow the risk, you wouldn’t expect the risk to reduce until after it’s passed.

Putting Risk Management into Practice

Let’s look at some examples of risks you may encounter while revising a backlog or iteration.

You might spot some unsized stories in the backlog. Is this because they are new and haven’t been assessed? Or were they regarded as trivial and not worth assessing? Or maybe the story is large and complex and too difficult to assign points to? It’s this uncertainty that makes unsized stories a risk in my view.

Another risk we might notice is a team trying to tackle more work than their velocity suggests would be possible, given the iterations. A team with velocity v that is expecting to complete 10v’s worth of stories in five iterations would surely raise some risks.

If we also know that this team is expected to complete d story points of defects where typically this would take a quarter of their velocity (i.e., d = v/4), isn't this also something that we should approach from a risk management perspective?

Let’s look at our possible responses to these examples, using the PRINCE2 approach.

• Unsized stories in the backlog

Avoid: Keep unsized stories low on the backlog. You may view this as a good standard agile practice, and I‘d agree with you!
Reduce: Ensure that unsized stories are reviewed and allocated a ballpark size. This at least allows the big, scary stories to be spotted more easily
Fall back: Plan to allocate a spike to size any unsized stories that are expected to be taken into the next iteration. Again, this could be considered a good general practice
Transfer: Get another team to spike and allocate ballpark sizes

• Teams that have more work to do than their velocity predicts possible

Avoid/Reduce: Alter the scope of the release so that the total payload (or at least the “must have” payload) is lower
Transfer: Get another team to take on some of the workload

• Teams that spend a quarter of their velocity on average on defects

Avoid/Reduce: Make all velocity calculations using a figure of (v – d) = (3/4)v
Fall back: Agree in advance that the work spent on defects can be temporarily halted to restore available velocity back to v
Transfer: Get another team to help with defects

As with any risk, it’s important to have a planned, agreed-upon, and communicated responses. Otherwise, the default position is always accepting the risk.

One team I knew was working on a release but also expected to maintain existing releases. This is certainly not unusual, but setting expectations with the product manager early on helped when we got to the point where either the release payload or the amount of effort spent on maintenance had to change.

We started out by ensuring that we took maintenance into account when doing velocity calculations, thereby avoiding or reducing the risk that this maintenance represented. The total velocity was not used to plan the schedule. Instead, we used a modified velocity (v – d) so that we didn’t fall for the misconception that the team could apply their total velocity to the new release when they clearly couldn’t.The team still struggled in the later stages to maintain older releases while completing work on the new release, so we ended up using our planned fallback response, which was to halt maintenance on earlier releases for the final sprints to allow the team to focus on getting vital features done for the new release.

I hope this article provides some food for thought when you are discussing potential risk with your agile team. Remember, if you have no planned responses, then you are effectively accepting all risks!