Collaborative Risk Analysis for Release Planning

[article]
Summary:
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.

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

Pages

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03