- the risk matrix – Powerpoint works quite well.
- Conversation during plays will slow the game down. I usually allow conversation, as most feel compelled to think out loud as they place risks, but I don’t allow challenges.
- Some in your organization may be tempted to quantify the risks. Obviously this is possible however quantification would add a lot more ceremony. I recommend keeping it simple.
Addressing Risks Through Release Planning
Once risks have been identified and ranked for severity, the next step is to decide how to respond to the highest severity risks (in this instance there was a clean separation between the highest severity risks and the rest). Once again we took advantage of the intimacy of the smaller groups to have breakout sessions on how we would respond to those risks. I asked the groups to think about how to respond to the risks and to consider one of the following strategies:
Avoid - Re-plan the release so the risk never occurs
Transfer - Outsource the risk to someone better able to address it
Accept - Recognize that we have done as much as we can do to address the risk
Mitigate-Re-plan the release to reduce the impact and/or probability of the risk
Additionally where they recommended mitigation I asked the group to describe what their approach would be.
As we debriefed it was soon clear that there was consensus on the biggest risks and through the conversation, mitigation strategies emerged that affected the original release plan.
One of the highest risks was that the first iteration contained a lot of stories with completely new feature functionality - as opposed to incremental improvements. It was proposed that the team spread the stories across the iterations and pull some incremental work into the earlier iterations. A second risk was that the final iteration contained too many story points and there was not enough margin for error. The team discussed this with the Product Owner and it was agreed that some of the stories in the final iteration be pushed back to the Release Backlog and pulled into an iteration if the team were ahead of plan. Similar discussions occurred for the other two high severity risks resulting in further revisions to the Release Plan.
Once the high severity risks had been addressed it was time to revisit the Risk Matrix and it was rewarding to note that the impact and probability of all the team’s high severity risks had been reduced through collaborative release planning. Within a span of two hours the team had arrived at a Release Plan that they owned and which addressed their concerns.
Lack of full planning participation is one of the more common causes of failure on an agile team. As the team becomes larger it is a challenge to ensure that the whole team is engaged in the dialog yet there may be other options to splitting the team.
Are teams truly self-organizing and self-managing if they miss expectations and delegate risk mitigation to the Scrum Master and/or the Product Owner? Introducing a lightweight risk management technique into release planning can help teams own their risks and work together on mitigation strategies.
Extending the techniques of the Team Estimation Game to risk analysis is a fun and effective way increase participation, drive consensus and build shared understanding,
 This is a story about a real team. TrailReady is not however the team’s real name. I am not aware of any team now or ever with that name.
 I prefer the term size over estimate as it helps the