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.
The TrailReady  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  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.
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:
- 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.
- 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