Quarterly Delivery Planning

You already know a version of this play already by another name - release planning, big-room planning, PI planning, quarter planning, and others. In this issue I want to talk about how this is useful for those leading product, regardless of your methodology, and how I approach it from the product side (vs, say, from the CTO side).

The photo shows my first experience with multi-team mid-range planning back in 2006. Jean Tabaka was lead facilitator, and Dean Leffingwell was in the room as an observer. He would later popularize the activity as a core part of his Scaled Agile Framework.

But you don't have to adopt any particular framework to benefit from this play.

Context

Use this play when the roadmap is full of dates with unknown origins. Engineering is complaining about shifting priorities. PMs are surprised by and complaining about dependencies. PMs are barely keeping up with sprint planning and not providing their teams with a mid- or long-term view.

When we are planning continuously, ad-hoc, there is simultaneously a lot of pressure (because everyone is nervous and lacks confidence) and no pressure (because everything can always be dragged out a little longer). Most companies keep people busy with a large amount of work in process, and deliver very slowly.

Play

Hold a 1- or 2-day event with everyone on the teams to make a high-confidence, bottom-up plan and commit together. Invite the whole team, even if this is 150 people.

Commonly called Release Planning or Program Increment(PI) planning, I prefer the more neutral term Delivery Planning. This method pre-dates the Scaled Agile framework by many years - the origins come from The Planning Game in eXtreme Programming way back around 2001. But Jean was the first person I saw facilitate this activity with many teams at once.

When we plan for a timebox of 8 or 13 weeks, we have to make tradeoffs about what fits and what doesn't fit. We have to ask questions about risks and dependencies in order to feel ready to commit to the plan. And when we invite everyone in the room, including all the developers, designers, QA people, and technical writers, we allow them to make a strong, personal commitment to the plan. If our planning is healthy, people feel they own the plan. This is when you unlock discretionary effort which allows you do do hard things.

On the flip side, if your planning meeting is unhealthy, if the PMs are unprepared, if you shove a fixed scope down everyone's throat, and don't take the feedback seriously, you can severely disempower everyone with an event like this.

It's up to you which way you do it. If you want the positive outcome, bring in a professional facilitator who's done this before. It's a fraction of the overall cost of the event.

Collocated companies can plan 8-13 weeks in a single, intense day, in a big room. When we are meeting online, I always book it over two days - at least start on Tuesday afternoon and finish Wednesday. That way people have some 'stretch' time in between the days to compensate for the slower collaboration online.

Nowadays, I almost always do delivery planning online, because my teams are spread across many countries. It is not quite as good as face-to-face, but it is hard to justify the carbon emissions that come from putting everyone on a plane. And I don't want to risk losing the travel budget in a tough quarter–this organizational habit is too important to me. So I save my travel budget for other kinds of gatherings.

There's a lot to think about in designing and preparing for delivery planning:

1. How to prepare facilitation and logistics
2. How to prepare PMs and priorities
3. How to explain the event to people
4. Standard format
5. Team breakouts
6. Efficient readouts
7. Reaching commitment

You'll find a lot of this detail in my book, Remotely Productive, which is free for paid subscribers. In the book, I walk through how to design this kind of meeting in detail (Part II). I also supply a sample agenda (Chapter 21), and explain how David Granaada, Anna Gough and I led this as a hybrid workshop. If you don't have a lot of experience leading online workshops at scale, you'll want to check it out.

For the playbook, though, I want to talk about some product-specific elements.

Preparing PMs

If you're leading Product, preparing the PMs is your responsibility. If the PMs arrive with well-prepared backlogs, the whole event is dramatically easier. I start the preparation about a month before the event itself:

1. Quarterly priorities. You want some kind of strategic input to set direction for the quarter, about a month ahead of planning. Depending on your steering mechanism, this could be any of a number of things:
   1. OKRs. If you use OKRs for planning, some draft objectives for the quarter aligned between top product and engineering leadership are a good start. You do not necessarily need to define the key results before you start planning - sometimes it's better to let the key results emerge from the delivery planning process.
   2. Rocks. Many companies struggle to use the OKR framework. If yours tends to overcomplicate things, consider simply agreeing on 3 'rocks' - that is, the 3 big projects that you must deliver in the quarter, that get served before everything else. (This is another idea that comes from Verne Harnish's Scaling Up, and a play I'll elaborate in more detail later). If you get 3-8 senior leaders together, you can brainstorm the list, dot vote, and select your top 3 in 1-2 hours.
   3. A ranked backlog. Depending on how many teams you have, you may be able to rank your features/epics/MBIs in a list, 1-20. You can do this with one of the prioritization plays (yet to come in the Playbook)
2. Roadmap Alignment. More on this play to come, but about 2-3 weeks ahead of delivery planning, gather all the PMs and tech leads in a 2-hour workshop to share their high-level backlogs with each other and identify dependencies.
3. Backlog Breakdown. Once each PM knows the 5-10 features/epics/capabilities they plan to bring to planning, they should do an initial story breakdown BEFORE planning, splitting each one into 5-15 stories. That means most PMs should have about 50 stories ready for planning. They don't need acceptance criteria or estimates, but they do need a list of one-liners.
4. Pre-flight check. I book a one-hour meeting with the PMs on the Thursday or Friday before planning. In this call I'll open Jira and look at their backlogs to see who is struggling to get ready. We have some informal discussions and the PMs use the time for last minute prep. I'm also checking whether they have success criteria for the higher-level features or epics, and whether they have story backlogs ready. If not, they still have a few days to wrap things up.
5. Rock Presentations. For the 3 rocks or objectives, I ask the PMs or tech leads who are leading them to speak at delivery planning, give them a slide template, and check in on them to make sure they're comfortable doing some public speaking.

Cautions and Caveats

If you are at a very early-stage company (pre-revenue or pre-product-market-fit) you may need to pivot faster than 8-13 weeks. In one company I worked with, we launched our product in December and then set goals for Q1, only to find that our initial great trial conversion rate was a fluke. This meant that by the mid-January, we had to replan. In this context we should have used a 1-month timebox, which could have been planned in a shorter event.

That said, many companies have unnecessary strategic churn because the strategy is weak or the leaders are indecisive. In these cases, they might want to pivot after 3 weeks. Having everyone committed to a mid-range delivery plan makes it much easier to push back on meaningless pivots driven by the latest big customer call.

A good delivery planning event requires all the PMs show up well-prepared. As head of product, you'll need to do a series of steps (workshops, 1:1s, etc) to get them ready, and these steps will consume at least 30-40 hours of your personal time in the weeks leading up to the planning. If you can't clear that much time, consider solving that problem first.