Why Quarterly Planning is the perfect event to create a Product Goal
The Product Goal received renewed focus in the 2020 Scrum Guide as the commitment of the Product Backlog. It states: “The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against… The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.”
There is no further guidance as to how to define this Product Goal. In the absence of an event, I would like to suggest Quarterly Planning as the perfect event to create a goal with a realistic time horizon, yet ambitious enough to rally the team around. In my experience implementing Scrum at a number of companies of different sizes, from startups like Babylon Health to S&P 500 companies like T.J.Maxx, this has been a critical event for setting a goal and direction for the team.
An often contentious topic in the world of Scrum is long term planning (i.e. planning beyond a month). Scrum is big on planning in the short term. It recommends a Russian doll of plans: planning the day using the Daily Scrum, the Sprint using Sprint Planning, and using backlog refinement and Sprint Review to plan the upcoming Sprint.
But what about a longer planning horizon? Whilst the addition of the Product Goal helps to set this vision, there is no supporting event similar to the shorter term planning events to help agree on this goal. I would like to advocate for Quarterly Planningas a method.
Quarterly planning (in other frameworks also described as ‘big room planning’) is simply an event to plan the next 12 weeks of work. It provides a ‘goldilocks’, medium-term planning horizon that is far enough out to link the work of multiple sprints together with common meaning, but not so far that the direction is too vague and not useful to the team. A goal over 12 weeks helps to galvanise the team, give a sense of direction and help to identify risks and issues early.
What is Quarterly Planning?
Quarterly Planning means different things in different organisations. It is often not particularly well defined as a meeting, even within companies. Here is how I run the meeting at Babylon Health:
- Introduction — Scrum Master introduces the session, the agenda and goals.
- Vision — Product Owner recaps the overall vision and purpose for the product.
- Velocity — collectively review the velocity of the team, and highlight any upcoming weeks in the quarter where this might be reduced (commitments outside the team, holidays, etc.)
- Estimate work — for each feature or epic, determine the rough size using t-shirt sizing (S, M, L, XL). We then map the t-shirt sizes to rough story point amounts based on historical data (e.g. S = 20, M = 40, etc.)
- Document the risks and dependencies for each piece of work, and why delivery might fail.
- Plan when the epics are likely to complete by using the velocity.
- Product goal — set the product goal to be achieved collectively as a team.
How to run an effective Quarterly Planning session
The following will help to run an effective Quarterly Planning session.
- Invite the whole team — the plan is only as good as the input provided to it. Therefore, it's a requirement for the whole scrum team to attend, not just the Product Owner or Scrum Master.
- Invite the stakeholders — it’s important to have a shared understanding of the direction with your customers and stakeholders. Invite them to the meeting and welcome their input.
- Have a clear agenda — at the start of the session have a clear agenda for the day with timings, so people can track if you are on time.
- Purpose — set a clear purpose for the planning session. In general, I set the following as the goals for the day: have a shared understanding of the upcoming priorities for the team, Have a clear goal for the next 12 weeks and document the risks and issues for resolution.
- Uncertainty — encourage the team to work through uncertainty — the estimation of work is likely to be more difficult than backlog refinement as the work will be less defined.
- Commitment — explain that this plan is not a commitment, but the Product Goal is. The plan may change as we learn more, but the act of planning itself is useful. Remind the team of the agile value of embracing change over following a plan, and set this context right at the start of the meeting.
Benefits of Quarterly Planning
I’ve run this session over 20 times with my various teams at my current and previous companies. The feedback has been extremely positive about the event, and participants usually report the following benefits.
- Intermediate goal — whilst Sprint Goals are effective at helping the team focus in the short term, it often is hard to understand the context of why that goal has been set. The quarter plan and the Product Goal helps to set that context and for the team to understand how the sprint goal is building towards a larger Product Goal.
- Vision — the Quarterly Planning meeting offers a specific time for the Product Owner to communicate their vision to the team and help convert it into concrete work. This does not happen as a ceremony within the existing Scrum framework.
- Prioritisation decisions — often the Quarterly Planning drives out important prioritisation decisions between competing initiatives that can help to prevent conflicts of decision making mid-way through initiatives.
- Capacity planning — the capacity planning that occurs if you estimate epics and measure against estimated velocity for the next 12 weeks gives a first indication of whether the plans are realistic and achievable. This can again help the team to make realistic plans for stakeholders and leadership.
- Dependencies — completing the Quarterly Planning exercise will help to identify dependencies in upcoming work early, allowing the team to communicate with other Scrum teams to prevent these becoming blockers.
Costs of Quarter Planning
Whilst there are clear benefits, there are also some downsides to this approach.
- Lengthy meeting — if you are planning capacity, estimating epics, capturing risks and dependencies and discussing prioritisation, Quarterly Planning can turn into a long session. To help mitigate this issue, I think it’s best to timebox the session so that there is a limited commitment made to this activity. Another option is to do this over several sessions.
- Reducing the ability to change — agile is dependent on its ability to change to new information to build a better product. This plan should not become a bible to be followed religiously. Instead, the plan should adjust depending on feedback from customers and new information. The planning exercise itself is what is useful.
- Estimating work — often work, particularly a few sprints out, can be hard to estimate. Despite this, I still think this is a useful exercise because it helps to drive the right conversations around the size, the work required, and the risks associated.
I’ve implemented Quarterly Planning with my teams at Babylon Health, and have seen great improvement in terms of engagement in the vision and understanding the direction of the team, particularly amongst the developers. It’s the perfect tool to help define the Product Goal that the whole team can believe in.