meeting achieves transparency so these tensions can be resolved by helping both responsible and accountable parties understand, coordinate, and respond to the release plans, along with any changes to the release plans, with the added goal of minimizing additional venues for decisions about a release.
Multiple Product Owners
Large initiatives tend to have several Product Owners. In this case, there must be one Chief Product Owner who reconciles the priorities of the other Product Owners. The Chief Product Owner is responsible for the plan and for conducting the Meta-Scrum meeting. The participants act as (are analogous to) a Board of Directors who review and approve the plan. The participants must have the authority to make decisions. Decisions need to be binding for the people in attendance. If someone is missing, that person must act in agreement with the decisions made in the meeting.
Important Artifacts in the Meta-Scrum
Tension can be identified and resolved when the business executives or Chief Product Owner is prepared with a roadmap that represents the desires of the business. [v] The Release Plan is created during Release Planning sessions conducted with the Scrum Teams and the Product Owner. When these two are not in alignment, the Meta-Scrum becomes the driver to get resolved.
Helpful Tools for the Meta-Scrum
There are two tools I find useful for encouraging the right discussions in a Meta-Scrum. The first one is shown in Figure 1: Example of a modified RACI chart applied to multi-level planning on Scrum projects. Notice the key difference between the Roadmap and the Release Plans. In this example, when release plans need to change and do not impact the roadmap, the Product Owners have the decision-making authority. Conversely, if the roadmap is affected, the Product Owners must get consent from the executives. The chart in this example has helped executives understand the levers they have and allows the decision authority of the Chief Product Owner to remain balanced.
Another tool that has proven valuable is Jim Highsmith's Tradeoff Matrix which is "an agreement among the project team, the customer (product manager), and the executive sponsor that is used to manage change during the project (Figure 2: Trade Off Matrix)." [vi] This helps stage the discussions by highlighting previous decisions about project constraints. For example, expected quality and date of release are often fixed or at least firmly defined. I saw the tradeoff matrix effectively used when the participants in a Meta-Scrum agreed to postpone a release due to a quality issue. The executives acted as a damage control team and decided how to handle their customers. They provided a much better solution than I typically witness without a Meta-Scrum. There was not any finger-pointing or bickering. The meeting ended on time with agreed upon action items and work continued on the product with the revised release target known by all. Everyone in the organization knew that there would be no changes until the next Meta-Scrum in one week, when the executives removed further impediments, re-established consent, or otherwise responded to current release-focused needs.
Conducting a Meta-Scrum
Conducting a Meta-Scrum requires a strong initial launch to set expectations. Responsible and accountable persons must attend this meeting and be prepared to make decisions or defer authority to the attendees of the meeting. This meeting should occur every week. A person who must miss a meeting for legitimate reasons regains influence the next week when he returns. This rule is critical to the success