Quarterly Planning Workshop

Overview

Quarterly planning focuses on goal-setting initiatives for three months, often focusing on shorter-term goals that can be achieved in less time.

Goal

To translate aspirational strategic plans into realistic execution plans.

Purpose

· To create a connected D&T roadmap – focus on the next quarter

· Cross-Domain dependencies

· Capacity planning

· Funding planning

· Deep dive into D&T performance and architectural topics

Accountabilities

· 'Heads of' to take the lead for their Platform

· 'Delivery Lead' to record actions and decisions

· Actions are owned by Platform, Domain, All of D&T

· The final decision sits with CIDO

· Prioritisation decisions remain with domain Steerco

Delegations

· Allocation of D&T Budget

Out of Scope

· Funding

Outputs

A successful quarterly planning event delivers two primary outputs:

· Committed Objectives

o Each team creates a set of objectives with the business value assigned by the stakeholders.

· The Plan

o Highlight the new delivery dates, team dependencies, and relevant milestones.

o Key initiative sequence & approach.

o Key resource contention (where a resource is not just limited to People).

· Continuous Improvement Items

o Operating model adjustments based on performance feedback.

o Retrospective actions

Principles

1) Teams over Individuals

The first principle calls for planning using teams instead of individuals, roles, and skill sets. This principle is grounded in research quantifiably proving that stable teams increase productivity. It also reflects the lean principle of "Follow the work, not the workers."

2) "Roughly Right" over "Precisely Wrong"

We tend to over-plan and overthink. Aiming for "roughly right" is about finding a balance of accuracy and adaptability. It accounts for the fact that realistic planning horizons should match the number of unknowns that exist a few weeks from now, a few months from now, and a year from now. It is about accepting that the only constant is change and getting comfortable with uncertainty.

3) Continuous Planning Cadence

A continuous planning cadence is about planning to replan and defer decisions until you have the information to make better decisions. Managing uncertainty becomes much more tolerable because you can inspect and adapt more frequently.

4) Tolerate Incomplete Information

You will not have all the information you need to plan, yet you still must plan. The cost of delay can be so high that you have no choice but to get comfortable with operating on good-enough data. For example, detailing work that will not be scheduled for six months is a waste. Instead, delay detailing work to near-term timeframes when information is much more specific.

5) Balance Demand and Supply

This principle is about matching your mostly fixed development capacity (supply) to meet an ever-growing and changing business demand. Balancing demand with supply is a disciplined approach to handling the surplus of demand in an inelastic supply environment. The key lies in ruthless prioritisation. First, understand where you generate value for your customers (its value streams), then (loudly!) declare business priorities for each value stream. Then, and only then, match your fixed supply capacity to meet these business priorities. Supply gaps in your short to mid-term supply can feed into hiring plans to increase supply capacity in the longer term.

Commitment

We are committed to the following:

Arriving Prepared	We achieve this by ensuring intra-domain/platform planning occurs before the session.
Taking Actions	We achieve this by assigning actions to individuals during the session.
Creating Awareness	We achieve this by capturing dependencies within the session and scheduling future catchups with those we require to succeed including cross-domain understanding of dependencies, sequencing, risks, and resourcing.
Focusing on Outcomes	We achieve this by conversing about outcomes (delivering value) and the team, not activities and individuals.
Setting up for Success	We achieve this by capturing RAIDS during the session and listening to other teams' RAIDS in readiness for future Steerco sessions.

Before the Session

What

A pre-quarterly planning event is required to orient cross-functional teams to business, platform, and delivery goals. During a pre-quarterly planning event, the team works to align on the context of the work and team capabilities, dependencies, and risks. The team outlines tasks, target milestones, and delivery dates. Once the work scope is understood, each team can kick things into high gear - the quarterly planning roadmap.

Why

· To answer questions regarding:

o Organisational readiness, which focuses on strategic alignment and teams and release setup

o Content readiness regarding management and development preparedness

o Logistics readiness considerations for running a successful event

Who

· Facilitator

· Leaders

Questions

Organisational Readiness

· Do all teams know they need to bring:

o Product/Platform Vision

o Roadmap and iteration plan

o Supporting artefacts, such as wireframes

· Do leaders know they need to bring:

o Organisational vision

o Goals for the broader product approach and discipline

· Has the planning process's scope (product, system, technology domain) been identified?

· Do we know which teams need to plan together?

· Do all the teams have dedicated team members?

Content Readiness

· Has a common understanding of the priorities among the Brands?

· Do the leaders know they need to give a briefing that establishes the current business context?

· Has the Architect Lead briefed the new enablers, features, and non-functional requirements (NFRs)?

· Have we agreed on who will share and update everyone on the program vision?

· Have we agreed on who will demonstrate the current state of the solution and the overall architecture?

· Are all product backlog features are prioritised & ranked with reasonable agreement?

· Has a business review of each feature been completed?

· Has a technical analysis establishing feasibility, architecture and solution and identifying enabler features been conducted?

· Have features been sufficiently defined to support release planning and estimation?

· After talking to the stakeholders, and make sure that you get the right people in the room. You want sufficient knowledge and mandate present at your quarterly planning.

Logistic Readiness

· How many planning locations do we need to maintain?

· What tools do we need to support distributed planning or remote attendees?

· Do we have all the helpers we need? Do they know what to do?

· Do we have enough stationery, planning poker decks, post-its, markers, a red string for dependencies, tags, etc?

During the Session

Day 1

Agenda Item	Remarks	Presented/ Facilitated By	Timing
Purpose	We are here to plan the next three months where the program wants to achieve XYZ.	VM Lead	15m
Review Last Quarter	Achievements and what happened, was there any customer and stakeholder feedback?	Facilitator	30m
Last Quarter's Retro	What actions were taken to improve it from last time?	VM Lead	10m
For Each Platform
	Vision & Strategy	Present/remind people about the Platform vision	Business Stakeholder
Solution & Architecture	How far are we with the solution? What foundational work is required to build the solution?	Architecture Lead
Release Plan	Present the release plan (next three months)	Facilitator
Releases	Present when major releases will occur
Dependencies	Which teams have stakes in the work	Facilitator
Team Breakout Intro	Explaining the specifics of the teams breaking down epics into features and estimating and prioritising them	Facilitator
Team Breakouts	People are working in their teams	Team Lead
Program Board	Teams post their initial plans on the program board and start coordinating with other teams	Facilitator
Repeat	Team breakout and program board discussions are repeated – typically 1-2 times before the final program board gathering
End of Day		Facilitator

Questions

Review Last Quarter

· What are the things that were achieved last quarter?

· What lessons were learnt?

· Was there any customer or stakeholder feedback?

Vision & Strategy

· What is the platform vision, objectives, and the vision for the upcoming quarter?

· Are the quarterly objectives SMART: Specific, Measurable, Achievable, Realistic, Time-Bound?

Dependencies

· Are there dependencies regarding

o People

o Product

o Time

o Funds

o Tools

Solution & Architecture

· How far along is the solution?

· What foundational work is required to build the solution?

· What are the architectural implications of upcoming features?

· Do teams understand the underlying architectural approach and system constraints they must work within?

· What are the systems and architecture vision for improvements to the infrastructure that will help to improve the time to market and may impact development during the coming work?

Releases

· What are the planned major releases during the quarter?

· Who will the releases impact?

Team Breakouts

· Can teams present their draft plans so that business owners, product owners, stakeholders and other teams can give feedback?

· If there are issues with architecture, scope, and people and resource constraints, can these be solved by management renegotiating scope and possible features? What else is required?

· Does each team have a draft plan that include 3 basic things: a feature delivery timeline, a set of quarterly objectives, and a risk assessment?

· Is every feature and epic estimated using relative size: XS, S, M, L?

· Have teams validated with stakeholders that they have clearly understood the intent and priorities for the quarter in terms of business value?

End of Day

· What have we learned so far?

· Where do we need to adjust: Vision, Scope, People?

· Where are the bottlenecks?

· What features must be de-scoped or deferred?

· What are the decisions that are needed before tomorrow?

Day 2

Agenda Item	Remarks	Presented/ Facilitated By	Timing
Team Breakouts	Continued from day 1, while teams are encouraged to coordinate with other teams and stakeholders	Facilitators
Roadmap Adjustments	Finalising the collective roadmap with all teams features and dependencies	Facilitator
Risks	Teams are bringing up risks, and they are discussed and mitigated in the plenum	Program leader
Objectives	Teams formulate their essential business objectives, and then the program objectives for the 3 months are agreed upon.	Product owners and business stakeholders
Confidence Vote	On a scale from 1-5 – how much does each team believe in their plans	Scrum masters and facilitators
Next steps	Usually, the next step is for the teams to make a sprint planning and then get going on the work	Program leader
Keep & Try	Reflecting over the quarterly planning session	Facilitator

Questions

Roadmap

· Program Adjustments – The day begins with any adjustments or decisions made by management and stakeholders in the problem-solving meeting.

· Team Breakouts 2 – Plan Adjustments to incorporate changes in priorities, scope, and people move into their plans. This will include any scope changes and feature delivery timelines, updating the team's list of risks, and potentially revising the team's list of program objectives. Identify any 'stretch objectives' and add them to their list of program objectives.

· Program Wall Board Update

· The Program Wall Board represents the consolidated feature delivery timeline from all teams. It is used to provide a consolidated summary of feature completion dates, enabler items, dependencies, and major program milestones.

Risks

· Identify Risks and Dependencies: Dependencies constitute a risk because they represent items over which the team has no direct control.

· The leadership team will announce any required changes to feature priorities and team changes.

· Program adjustments from leadership review – priorities, scope changes, people movements.

· Teams adjust & finalise plans

· ROAM'ing exercise on their list of risks

o R: Resolved. The team has resolved (or knows how to resolve) the risk.

o O: Owned. The teams decide to 'own' the risk. That is, they will take responsibility to work to resolve the risk on their own without needing to escalate for help.

o A: Accepted: The team accepts the risk as something that is 'p of life', or p of the cost of doing business.

o M: Mitigated: The team believes they can take specific actions to reduce the impact of the risk.

Objectives

· Stretch objectives setting

· Teams identify remaining issues needing help from an outside team

· Business stakeholders circulate to review plans and score quarterly Objectives

· Scoring quarterly objectives – Business value is assigned to each objective (scored 1-10). Formulate objectives by thinking about the problems that are being solved for the user (Better, Faster, Cheaper, and so on). Think of features as being the solutions to those problems. Features have specific benefits for the user, and these are usually traceable back to an epic 'value statement' and from there back to at least one of the strategic themes identified for the business.

Confidence

· Team-level confidence votes.

· Program wallboard: Feature delivery timelines by the team.

· Team plans collected to the front of the room, risks, and program confidence vote.

· It is a Fist-of-Five vote from all team members. Any vote less than 3 should be explored and commitments potentially re-worked until all team members vote at least a 3.

Keep & Try

· Event retrospective.

· Quarterly planning event retrospective

· It can be as simple as a 2-column table drawn on a whiteboard or flipchart with a column for 'what went well' and another for 'needs improving'. A Dot Voting exercise can be done to identify the issues most important to the gathered teams.

After the Session

· Release scope defined for next time-box

· The team better comprehends the objectives for the whole PI.

· A shared understanding of what it takes to release

· Program risks reviewed and actions identified to solidify the plan

· Release objectives reviewed and scored by business stakeholders

· Team and program confidence vote on the plan

· Collective ownership of the plan

· Risks and issues

· Planning retrospective and moving forward – Finally, the leads a brief retrospective of the pre-and post-quarterly planning sessions to capture what went well, what did not, and what could be done better next time. Then, subsequent steps are discussed, including capturing objectives, use of agile project management tooling, and finalising the schedule of upcoming Solution Train activities and events.

FAQs

· Why bother creating a plan in a world where change happens so fast and often? Should we stop doing what feels like a wasteful exercise?

· How can we make the process more valuable, less time-consuming, and less frustrating?