Summary

• Simple planning and execution governance is sufficient to coordinate, communicate and help keep teams and stakeholders informed and aligned.
• A dedicated role to support for these activities (for example ‘Chief Scrum Master’) is valuable to ensure delivery teams are not distracted from delivery tasks.
• Planning can be accomplished asynchronously.
• With appropriate planning detail, execution progress can be measured, so that timely adaptation can be applied when necessary.

Planning

The Product Backlog intake workflow delivers features to a sufficient level of clarity to enable planning by the delivery teams. Both business and technical requirements are captured on the product backlog – everything needed to achieve the Product Goal.  Backlog items are stack-ranked taking into account business value, time criticality, and development effort. Intake and development systems run concurrently, and the organization continuously seeks opportunities to improve end-to-end flow in order to minimize delivery lead time.

In many organizations the approach to planning at scale is to get an entire business unit, say a dozen teams plus other stakeholders – up to 150 people, into a ‘Big Room’ for 2-3 days and thrash out a plan.  This type of event was probably necessary when resulting the plan looked like this:

The above program board is symptomatic of non-value stream aligned teams, or non cross-functional teams, weighed down with dependencies, and with features shared between multiple teams. In this case, Big Room Planning events for the purpose of working out complex dependencies between teams are likely the only practical way of converging and aligning on development plans. However these organizations can significantly improve their delivery capabilities by addressing the underlying organizational design to remove or at least minimize dependencies. A major focus of transformation work must be to evolve an organizational architecture that enables team-level agility.

Distributed Planning

A major objective for delivery planning is to align an organization on goals and priorities for the next delivery cycle – whether that’s one sprint or one quarter.  A key advantage of the Big Room Planning approach is that we have all the answers available in one place at one time.  It is also a great opportunity for face-to-face collaboration and relationship building. In recent times, mass gatherings of this sort have been out of favor, and organizations have sought to create virtual versions of these events using collaboration and conferencing tools.

Many have substituted Big Room Planning with Big Room Planning on Video in an attempt to replicate the process virtually. This requires complex logistics and orchestration, and the question arises whether there is a simpler alternative that accomplishes the same purpose.  Let’s take the scenario where an organization operates on a quarterly planning and delivery cycle, that is, the delivery cycle time-box is six 2-week sprints. (The model can be generalized for any planning horizon). Let us assume that planning for an upcoming cycle takes place during the last sprint of the prior cycle. The high-level planning flow is as follows:

We want to have a planning framework where teams can plan as independently as possible, and where we do not need to tie the entire organization up in lengthy video conference calls. Ideally teams can plan independently with checkpoints built in to synchronize on progress.  In the example below of a distributed planning framework, steps 1, 3 and 5 are synchronization events where all teams and business stakeholders convene (a 1-2 hour conference call) to align on goals and progress. In steps 2 and 4, teams work independently to create and adjust plans. The input to the entire process is a clear set of business objectives for the next delivery cycle, and at least some initial alignment on team goals (represented by team backlogs). Planning can then proceed via the following steps:

• Break features into stories via story mapping
• Estimate stories and roll estimates up to feature level
• Identify dependencies and work out timelines for resolution
• Get approximate overall scope of what can be delivered
• Review plans, make needed adjustments.

The process steps are as follows:

The first time trying out this process allow around 2 weeks end-to-end. This should take place in the last 2 weeks of a delivery cycle. The process should not consume teams for an entire sprint but their delivery capacity will be reduced while the work of planning is being carried out. The entire process can be accomplished within a one-week timebox with experience.

Step 1: Align on Goals and Priorities. This is an event to kickoff the construction of a baseline plan for the next delivery cycle. This event should happen during the last sprint of the current cycle. Input is a Ready Program Backlog with features defined to a definition of ready (acceptance criteria, and stack-ranked by business value), and aligned with specific delivery teams. The goal for the event is twofold:

• Review accomplishments and lessons learned from the last delivery cycle.
• Confirm scope and priorities for the upcoming cycle.

At this event each team presents their goals and priorities and confirms alignment with  stakeholders. As much discussion should have already happened during the Intake Process, there should not be any major surprises at this point, but some minor adjustments may be in order. This event, with proper preparation, can be covered in a couple of hours with up to 10 teams. Each team would present an initial plan as follows:

Note that teams do not present simply a list of features, but will also articulate a business rationale for each one, and, ideally, an associated KPI so that the impact of the feature is actually measurable. It is important that this step of the planning process is conducted before any effort is invested in detailed planning. This event is also a good opportunity for a presentation on the results and accomplishments from the last delivery cycle, plus any major lessons learned and improvement plans for the next cycle. Keep this part simple, such as:

Step 2: Team Planning. Once the organization is aligned on a set of goals and priorities, teams will need to confirm the scope of what can be delivered by reconciling the required delivery effort with their actual production capacities. This exercise involves doing a more refined estimate for each feature in the plan. Features will need to be mapped into user stories and sized. Equipped with knowledge of their velocities, teams can then estimate the total scope of what can be delivered for the planned time-box. Stack-ranking of the feature list is essential to ensure available capacity is allocated to the most valuable features.

The steps needed to produce such a plan by each team are (steps 1, 2 are handled as part of the Intake Process):

1. Pre-Planning: Features defined with sufficient clarity to support planning.
2. Pre-Planning: Features stack-ranked in order of importance, for example highest business value with least cost/effort.
3. Features elaborated into user stories using a basic Story Mapping exercise. To do this quickly only story titles are identified (‘shell stories’) – enough to communicate the overall intent of the story. These stories will need further refinement for delivery during team backlog refinement.
4. Stories estimated in points, which are then  rolled up into an overall feature estimate. In the absence of detailed story definitions this will be a very coarse-grained estimate:  Small/Medium/Large (where, for example,  S=1-2/M=3-5/L=8-13 points, XL needs to be split further, and XS are free).
5. Total feature effort reconciled with available development capacity to provide an overall scope estimate. In the example below, this team has a velocity of 30 points per sprint. Thus has a total capacity of 180 points  over 6 sprints, which means that only the first 6 features are likely achievable.
6. Optional: estimate which sprint each feature will be completed in. This is really only necessary when we have lots of dependencies between teams. Our goal is to minimize this this by getting the organization structure right.

Team planning results summary:

Each proposed feature has been broken down into user stories, and each story sized in points. The point of this exercise is to get an overall estimate so that the total scope of what can be delivered is reconciled with actual team velocities. In the above example we see that this team only has the capacity to deliver the first 6 of the 8 features requested.

A simple but effective way to orchestrate all of the team planning activities is by using a shared workbook – Microsoft Excel or Google Sheets – where each team has a worksheet (tab in the workbook) for capturing their planning output. For example, each team builds a plan along the following lines:

(Even Better – the latest generation of collaboration tools:  Mural, Miro, and the like).

All of the teams in the program could have a short daily huddle with a Chief Scrum Master to review progress with planning efforts and get help where needed. When all planning has been completed, a final rollup summary can be produced:

In the above example,  if we were embarking on, say,  a 5-sprint delivery cycle, then we would need to be delivering at least 200 points per sprint. This can be tracked with a simple burn-up chart (burning up either story points or a count of done stories will work equally well). During execution, this is a simple but effective way to confirm that the program is largely on track, or if mid-flight adjustments are needed at any point.

Step 3: Review Team Plans. When all teams have completed their planning, a second review with business leadership plus stakeholders is held to review results and to highlight any major disconnects between the goals represented by the program backlog and what teams can actually deliver. This may result in changes to plans (for example feature de-scoping, team capacity adjustments, dependency fixes, or help with specific risks), which are then undertaken before the presentation of a baseline plan.

Step 4: Final Planning Adjustments. Teams will make any final adjustments to their plans factoring in recommended changes in scope, capacity, or dependency fixes. This may only take a day or two, leading into a final event where the consolidated plan is presented to the entire organization.

Step 5: Align on Baseline Delivery Plan. Teams will present their updated plans, and the organization leadership will confirm alignment on a baseline plan for the next delivery cycle.

The above example presents an estimate of what the organization can produce over, say, the next quarter, or next six sprints. This view shows the features aligned with each delivery team in the program. Features highlighted in green are in scope, while those in red represent work beyond the capacity of a team.

Finding Time For Planning Planning takes time and effort and will subtract from a team’s normal production velocity.  If our operating model includes running all primary processes on a synchronous cadence then planning can be accounted for in a straightforward way. For example, many large enterprises like to operate with a quarterly planning model, that is, once a quarter a plan is constructed for the next 6-sprint delivery cycle. The 3 planning steps discussed above can easily be accommodated within a 2-week timebox, which could be organized to coincide with the last sprint of the cycle. Teams could add planning related tasks to their sprint backlog for that sprint, and even connect them to an overall goal of creating a plan for the next cycle. In this way, planning activities are accounted for, and no-one need fret about sudden changes in velocity.

Execution

During execution we need to continuously measure progress in order to confirm that the plan is on track to meet its objectives, or if adjustments need to be made to the plan. Without the ability to adapt we become hostage to events that inevitably emerge in the course of execution. Sound adaptation requires data, and given our planning approach, we now have the basic data to help with this task. This data is simply an extension of the basic worksheet we used in planning with a couple of extra columns to collect data on the number of done stories (and done points) per feature:

The above chart is useful to get a per-feature view of progress, and to identify features at risk or in need of attention. We still need a way to confirm if we are on the right trajectory to complete all of the planned work for the cycle. For this a simple burn-up chart showing points done per sprint versus total planned. (Done stories would serve almost equally well).

This chart suggests that the team is behind plan (done points = 130 vs. an ideal of 160), and heading into the final sprint (where they will be operating with reduced velocity due to planning activities for the next cycle). It would be worth taking a hard look at the list of unfinished features and deciding which ones could be taken to 100% done in the next sprint and which ones should be dropped or deferred. It’s better to finish with 5 completely done features, than with 6 partially done ones. These 2 charts provide all of the information needed to help make the most sound decisions.

At the overall program level, we can roll-up the same team data to get the full picture:

This view also gives a high-level summary of progress for the current delivery cycle. This chart is likely to prompt a deeper dive into feature-level detail. For example,  here’s the overall state of play at the end of Sprint 3:

At the end of Sprint 3 each team should be around 60% done. In the above example (numbers in story points) we can see that teams A, B, and D are roughly on track, while C is behind, and perhaps E needs help setting priorities.  In any case we at least have the starting point for conversations around scope adjustments or review of priorities.

The ability to respond to change is the essence of agility, and at scale this is a very significant challenge. Just as “no plan survives contact with the enemy“,  no delivery plan is likely to survive intact beyond the first iteration. Inspection and Adaptation are more challenging at scale, and  Transparency (clarity based on facts and data) is a prerequisite for navigating a program towards best possible business outcomes.

Execution Governance

The word governance seems out of place in any conversation about agility, and our central thesis all along has been to keep any additional governance to the absolute minimum. Agile delivery programs do need some basic support as opposed to management and control. With multiple delivery teams collaborating on a common set of objectives some level of coordination will be required. Self-organized teams with clear missions and program objectives do not need to be managed in the traditional PMO sense. However, support is needed to coordinate and facilitate planning and execution activities. A program coordinator (or ‘Chief Scrum Master’) role that provides this kind of support is valuable. Basic duties would include: facilitation of planning processes, scrum-of-scrums and delivery cycle reviews, data collection, progress reporting, impediment management, and communication to keep everyone informed and aligned.

Two basic governance events are needed:

• Scrum-Of-Scrums: A daily check-in for teams to raise any issues impacting the program delivery plan, and to escalate issues requiring support beyond the teams.
• Program Reviews: A review for teams and stakeholders to communicate overall progress, to get help with major impediments or risks, and to align on any necessary adjustments in scope or priorities.

A Program Coordinator or, Chief Scrum Master: Coordinates and facilitates all program level events and processes including program planning, program reviews and scrum-of scrums.

Scrum-Of-Scrums	Cycle Program Review
Cadence: Daily Attendees: Chief Scrum Master, Representatives from each Team Agenda: Progress vs. Cycle Backlog Risks/Impediments – help needed Proposed Program Adjustments	Cadence: One per Sprint Attendees: All Teams and Stakeholders Agenda: Feature Completion Progress By Team Team Burn-Up Chart Program Burn-Up Chart Program Risks & Impediments

Organizations should experiment with the frequency and content of these events in order to get maximum benefit while keeping overhead to a minimum.

Scrum-Of-Scrums On a daily basis, Scrum teams meet to understand their progress towards achieving a Sprint Goal, and, if necessary, make adjustments to their plan to maximize the probability of achieving it. This is the purpose of the Daily Scrum. It is a daily event to Inspect and Adapt the sprint plan. During the course of a sprint, a team may discover things that can impede it’s ability to achieve the Sprint Goal. These things are referred to as impediments. They may include things like: Unplanned interruptions (for example, a critical production bug that must be fixed). Unplanned reduction in team capacity/velocity (a team member goes out sick). An unforeseen dependency. Discovery of something that will prevent completion of a planned user story. Discovery of unplanned but necessary work. A story needs a database change that was not factored into the original sprint plan. Realization that the team has underestimated the effort needed to meet the sprint goal. A late bug found in user story acceptance testing causing the story to be carried into the next sprint. The exact format of a Daily Scrum may vary from team to team, but the main talking points should be: progress of items in the Sprint Backlog, and impediments to getting them done. In many cases the team may be able to resolve or mitigate or simply accept most impediments and carry on. However if the impediment is something that cannot be resolved by the team (e.g. recurring outages in a test environment), then the team should escalate for help. At scale, where we have multiple scrum teams servicing a product or program backlog, we may use an equivalent event called the Scaled Daily Scrum. or simply the Scrum Of Scrums. This event serves the same basic purpose, viz, align all teams on progress towards goals, and communicate impediments or potential impediments to achieving them. Like the Daily Scrum, problem solving discussions are taken outside the meeting where they are worked on by a the appropriate set of people, or they are escalated for help. For teams that are part of larger multi-team programs, the overall approach might look like the following. At 0800 am every day each team huddles to conduct their daily scrums. New risks or impediments that cannot be resolved within the teams are recorded. Fifteen minutes later any impediments that need coordination with the larger program are brought into a Scrum Of Scrums, by representatives from each of the scrum teams. This pattern continues until at, say 0900 am, a leadership team with authority for funding and resource allocation, reviews a backlog of the most critical impediments and takes appropriate actions to keep programs on track, or makes adjustments designed to minimize impact to business objectives. In our quest to minimize additional governance at scale, a scrum-of-scrums as described above, when focused on nothing else but supporting the teams with impediment removal, is the one essential event that can actually help preserve flow and ensure that value delivery is continuously optimized.

With a Value Stream aligned organizational structure, it is possible to minimize the amount of additional governance and bureaucracy needed to support multi-team/multi-sprint delivery programs. It may take organizations time to evolve and adjust to this operating model, but the payoff in terms of team productivity and delivery cycle times is well worth the effort.

Sophisticated reporting tools like PowerBI and Tableau might be useful in the long run for automation and visualization of the data needed to navigate through a delivery program, however in the short term they can be a source of delay and distraction. Focus first on identifying the few critical measures necessary to support events like Scrum-of-Scrums and Program Sync reviews – it is important to supply these events with actionable data as soon as possible. The humble spreadsheet can be a good way to start.

Conclusions

Enterprise software delivery requires the capacity of multiple development teams and multi-sprint delivery cycles. Additional governance beyond the basic scrum framework is needed for planning and control of such programs. There is no universal prescription for such governance, and specific approaches to scaling methods will be context-specific to each enterprise and may even vary between  individual businesses within an enterprise. All methods presented here are intended as examples that can be tailored or extended to meet the unique needs of your organization.

Agility at scale is a means to an end, an enabler of superior business performance. Organizations pursue agile transformations in the hopes of achieving outcomes like accelerated delivery cycles, improvements in quality, predictability, and the ability to respond quickly to changing business priorities. Stronger alignment between IT and business organizations is also an increasingly important goal. However, the adoption of complex scaling  frameworks can become a serious distraction that diverts focus from intended business outcomes.

Our central thesis has been about scaling down the problem of organizational, planning and execution complexity. These are the primary impediments to scaled delivery. Organizations are encouraged to add additional governance incrementally, and to measure the benefits and cost at each step. Any additional governance event or artifact that impacts delivery lead time must be scrutinized and weighed against the basic tenets and principles of the Agile Manifesto.