A simple Agile release plan

A simple Agile release plan

Agile release plans are powerful tools to communicate direction to the organization AND the team.  There is a natural tendency to think that power and complexity are directly related. In other words, a powerful tool must be complex and require a significant level of effort to develop and maintain however Agile release plans can be simple and easy to deploy. The complexity of a release plan is driven by two major factors: the complexity of the project and the level of process fluff required by the organization.

An Agile release plan for a single team can be as simple as a sheet of paper with sprints marked off.  The team would then list the stories in the appropriate.  In the case above, the team did not develop a release plan until just before the second iteration.  They used a simple process of matching a sized (with story points) and prioritized (value) backlog to iterations based on their velocity (the average amount of work they were completing per iteration).  The release plan was taped to the wall in their team room so it was available to the team every morning during stand up. Note that at the end of iteration one the team realized that story number 29 was an epic and broke it down for completion in the next iteration. The release plan that the team used was very simple, but it served as a planning platform for the team and as a tool to communicate their approach for delivering value. The long-term usability of this very simple model could be improved by writing the stories on sticky notes rather than on the paper so that changes to the  plan would not require crossing stories out or rewriting the plan as changes occur.

I observed a more complex approach to Agile release planning that addressed a two team, two release project.  The project was funded for six sprints. The product owner anticipated releasing functionality twice during the project. Both teams were responsible for delivering architectural stories and functional stories in a coordinated fashion. The stories for the project were drawn for a larger application backlog that both teams used.  The following picture is a representation of the solution the team used (they actually used brown butcher paper, painters tape, sticky notes and yarn).


The two teams opted for a simple graphical approach. The plan was placed on the wall of their team room where the entire team could see the chart. As the teams kicked off, they held a joint meeting with their product owner and built the initial plan.  The first plan was viewed as even more notional than normal, as neither of the teams had established their velocity. The plan was to be updated as part of the sprint planning process. An interesting touch that this team used was the inclusion of dependencies between stories, which were marked by yarn. These teams were still working on developing independent user stories, which is sometimes difficult.

There are lots of ways to generate an Agile release plan. The complexity of the project and the process needs of the organization will guide how teams address and communicate release plans. Agile release plans do not have to be the outputs of highly complex tools, represented by highly polished charts to communicate direction. Simplicity in release plans makes it easy for the team to create, maintain and use Agile release plans.