Release planning is more than just stuffing the highest ranked stories into iteration buckets. To be meaningful the whole team needs to participate. Lightweight risk management techniques are not orthogonal to an agile approach They can help proactively address previously hidden concerns and the planning process benefits all-around from shared dialog on release-impacting risks.

Background
The TrailReady [1] team had introduced Scrum for the June release of their product and throughout the release had observed a much higher degree of collaboration on the team and an ability to deliver value earlier and more frequently. For their November release they were interested in holding a release-planning workshop to better synchronize the team on objectives and give everyone the opportunity to see and think about the big picture. They invited me back to facilitate the session held over two ½ days. 

Easy Release Planning
Release Planning began with a review and retrospective of the previous release. Lessons were learned that resulted in changes to the working agreements for the next release. Next Sam (the Product Owner) described the vision and the business objectives for the release.

The next step was to size [2] the stories and defects targeted for the release. On a previous occasion I introduced TrailReady to Steve Bockman’s Team Estimation game as a technique for sizing the backlog. Sam loved how quickly we could size the backlog but the team decided to stick with Planning Poker as they felt it allowed more time for discussion.

Assigning story points to the backlog went very smoothly due in large part to the diligence of Sam and Robin (the Scrum Master) who keep a well groomed backlog. We next determined the best velocity for forward planning and then discussed with Sam about what stories would characterize the iterations of the release.

The whole process proceeded very smoothly; in a little over 3 hours we had planned the release to the appropriate level of detail. It was tempting to declare victory, finish right there and give the team some extra capacity.

Too Easy
Yet something wasn’t quite right. It was too easy. Although there had been good dialog there had not been enough participation. In the prior release the team had not been hitting 100% story acceptance iteration over iteration and I was not comfortable that they truly understood why and that we had addressed this concern going forward. We needed to spend a little more time so I asked (and got) the team’s permission to continue the following day and we closed the day with a short retrospective.

As I reflected on the day a couple of related threads kept popping up. I wasn’t hearing from some of the voices in the room. Perhaps with 16 members the team was just too large but with no natural way to split the team it did not make sense to add the overhead of two teams. After all, if Menlo Innovations can have a daily stand-up with 85 people why can’t we make a co-located team of 16 work? Secondly, I didn’t feel a strong sense of ownership from the team, I was worried that they were leaning on Sam and Robin too much.

I decided to employ the following tactics on the second day:

1. Rather than work as a large collective during the planning session, break up into smaller teams. Hopefully this would give everyone an opportunity to participate more, minimize group-think and lead to more ideas.
2. Although the team was a long way towards being self-organizing and self-managing they were not owning risks, instead depending on Sam and Robin to worry about what to when, and if, risks manifested themselves. Perhaps it was time to dust-off an old, neglected technique I hadn’t used for a while to try and get the team talking about release risks.

The Best Way To Get A Good Idea Is To Start With A Lot Of Ideas
On my journey into TrailReady the next morning I called Robin and asked her if she could identify four groups for me. Group A would be composed of the four most extroverted members of the team and Group D would be the least extroverted. In my experience it is foolish to only take advice from those that are most eager to give it and I really wanted to hear from the quieter members of the team. I find this especially true when working with today’s teams that often have members who can be hesitant because their mastery of the English language is not on a par with others. I felt that the best way to get participation from the quieter members of the team was to place them in an environment where they would be more easily heard and would not defer to others.

Identifying Risks
After the morning introductions, I broke the team into groups and asked them to identify the four greatest risks that could impact the upcoming release and to write each on a 3x5 sticky note. During the exercise you could sense everybody was more engaged just from the decibel level in the room and there was no shortage of ideas. After the end of the time-box the group presented their risks to team and placed them on the collective risk list. Through this exercise we were able to get better participation, better coverage and a shared understanding of everybody’s concerns.

Collaborative Risk Analysis
Once we had collected all the risks, we spent a few moments doing some affinity grouping to synthesize our risk list. Next we used a technique similar to Steve Bockman’s Team Estimation Game to analyze our risks. It works like this:

• On a wall find a space large enough (wall or table) to hold all the risks and create a Risk Matrix by drawing two axes. Label the Y-axis Probability and X-axis Impact
• Assemble a card deck with all the risks and pass the deck to someone on the team
• The person with the deck pulls the first risk and places it on the risk matrix. The higher up they place the card then the greater the probability that the risk will occur. The further to the right they place the risk card then the greater the impact.
• The deck is passed to the next person who can either:
  
  • Move a risk
  • Place a risk
  • Pass
  • Repeat until no more cards are left and everybody passes.

Once we’re done we have an information radiator that gives a very good visual of identified risks and the team’s collective assessment. The most severe risks will appear high and to the right. Risks low and left are probably not worth worrying about.

Notes for Facilitators

• If there are is a lot of movement it may take a while for the risks to stabilize. Be patient. Let the team feel the divergence in the group and allow them decide when it is time to stop moving risks.
• If you have remote participants divide the matrix up into a 4x4 grid and number each grid and have them tell you in which square to place the risk. It is best if the visual is shared so consider using a web conferencing tool and a tool that can display 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. 

Summary
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,

[1] 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.
[2] I prefer the term size over estimate as it helps the team thinking about how large the story is rather than how long it will take.