A Real Release-Planning Experience

A Real Release-Planning Experience provides a detailed, behind-the-scenes account of a first Release Planning meeting at Accela during its Agile transformation. The organization was developing Web and mobile applications and was beginning to use Scrum across multiple teams. Kevin Thompson, Ph.D., facilitated the Release Planning session and documents the preparation, activities, decisions, challenges, and outcomes in detail.

The case study follows the meeting from kickoff through completion of the Release Plan. Participants first organized Product Backlog Items among teams, used Affinity Estimation to rapidly estimate a large number of items, established team velocity forecasts, and then placed work into a six-Sprint Release Cycle based on business value and team capacity. The group subsequently identified and visualized dependencies between teams, added missing Product Backlog Items, and adjusted the plan as issues emerged.

One of the most useful aspects of the case study is its level of practical detail. It shows how Release Planning works when preparation is incomplete, team definitions are still evolving, many backlog items remain unestimated, and participants are distributed across locations. Rather than postponing the meeting until everything is perfect, the participants adapted their approach to the circumstances and produced a usable initial plan.

The case study also explains an important principle underlying Agile Release Planning: a Release Plan is a forecast, not a guarantee. The initial plan is expected to change as teams learn more about the work and as business circumstances evolve. The value of Release Planning therefore comes not from creating a fixed long-term commitment, but from establishing the best current understanding of how work can be coordinated and then refining that understanding over time.

Although this case study comes from software development, the detailed mechanics and principles of Release Planning are directly relevant to organizations managing multiple engineering teams, dependencies, and work beyond a single Sprint. It provides a practical example of how collaborative planning can make dependencies visible, coordinate work across teams, and create an adaptive medium-term plan.