The release planning event in the Scaled Agile Framework Enterprise (SAFe) is a two-day program-level planning event that focuses the efforts of a group of teams to pursue a common vision and mission. As we have noted, the event includes participation by everyone involved in the Agile release train (ART), participation is in-person (if humanly possible), occurs every 8 – 12 weeks and has a formal structured agenda.   The agenda has five major components:

  1. Synchronization.  This component seeks to get everyone involved in the ART on the same page in terms of:
    1. Business Context
    2. Product Vision
    3. Architectural Vision
    4. Technical Environment and Standards

Each of these subcomponents provide the team with an understanding of what they are being asked to do and the environment they are being asked to operate within. The flow begins by grounding the team the business context for the program increment (the 8 -12 weeks). Each step after the business context increased in technical detail.

  1. Draft Planning. Leveraging the context, vision, architecture and environmental standards, the teams develop a draft plan. We will explore the process in greater detail in a later essay, however this where the team breakdown the stories they will tackle during the program increment, breaks them down, exposes risks and identifies and minimizes dependencies.   Draft planning usually consumes the second half of the day. The Release Train Engineer will gather the scrum masters together periodically during the draft planning process to ensure teams are sharing dependencies and understand the direction each is heading.
  2. Management Review and Problem Solving. At the end of draft planning, any significant problems with the scope of the program increment, staffing or other resource constraints are generally apparent. After the majority of team has completed their work for the day the management team (including RTE and scrum masters) meets to share what was learned and make the decisions needed to adjust to the constraints. This is must be completed before the beginning of day two.
  3. Final Planning. The teams review the adjustments made during the during the management review the previous evening as a whole group and then break out into teams again to continue planning converting the draft plans into final(ish) plans. Plans are finalized when they are accepted by the business owners.
  4. Review, Re-planning and Acceptance. When the teams plans are finalized they are reviewed by the whole team, the risks are ROAMed, the whole team votes on acceptance (a form of peer review and acceptance), any rework is performed on the plan and finally a retrospective is performed and next steps identified.

The release planning meeting operationalizes a program increment. A program increment represents 8 – 12 week planning horizon within a larger Agile Release Train. The large scale planning event helps keep all of the teams involved in the ART synchronized. The release planning meeting might be SAFe’s special sauce.

Your Scrum events might be slightly less well attended!

Your Scrum events might be slightly less well attended!

The list of identified events in the Scrum framework, like the number of roles, is highly constrained. Scrum walks the line between identifying a set of events that each follow a typical pattern and prescribing specific activities and tasks.  As a framework, Scrum leaves the control of specific behaviors to the team. Therefore each team has a customized approach to how they implement the events based on organizational culture and need. The events identified in the framework include:

  1. The Sprint: which is the time box for developing potentially implementable functionality.  The sprint generally ranges from 2 – 4 weeks, with the 2 week increment being the most common I see in the industry.  Once your team agrees on the sprint duration for a particular project, it generally does not change.  The standard duration of the sprint is called cadency. Developing a consistent cadence helps the team become predictable.
  2. Sprint Planning: a meeting for the team to plan the work they will commit to during the sprint.  Sprint planning is a two-step process beginning when the product owner identifies the units of work they want included in the sprint using the prioritized backlog and input from the team for guidance.  After the product owner identifies the work he or she wants in the sprint, the development team (I recommend that the whole team participates) estimates the work based on their velocity (how much work they typically get done in a sprint) and the activities needed to complete the work (completion must meet the teams overall definition of done). The team will either increase or decrease the number of work items based on what they can complete.  What the team WILL NEVER do is to change the definition of what done. The planning activity is complete when the team can commit to completing the work they can do during the sprint.
  3. The Daily Scrum: the daily planning session that generally begins the team’s day.  The daily meeting provides the team with a mechanism to plan the day and to ensure that issues blocking work do not fester. Try to keep the scrum meeting at or near the beginning of the day so that team can use it as tool jump start their day.  Team composition and time zone constraints will dictate when the meeting happens.
  4. The Sprint Review: the meeting at the end of a sprint for the product owner and stakeholders to interact with the functionality and provide feedback and acceptance.  The sprint review provides a platform to gather feedback from a broader constituency than the team itself. The whole core team should be interacting on a daily basis; therefore the review should be leveraged to include a wider range of stakeholders.  The product owner should drive the guest list with advice from the entire team.
  5. The Sprint Retrospective: a meeting for the team to review their performance and identify opportunities for improvement. The team should find at least one process improvement that they can make and then commit to making that change.  The change the team commits to should be captured as a unit of work and be incorporated into the next sprint backlog so that it gets done.  Process improvement is the obligation of the WHOLE team, not just the development team.

The five events identified in Scrum are sometimes explained as four meetings and the sprint, which is an intrinsic part of Agile techniques.  All five are important features that interact providing self-reinforcing discipline and feedback.  I usually worry less about how a team is accomplishing the events, rather I make sure they doing something that meets the intent of the events and are in line with the Agile values and principles.