How we used quarterly planning to align and protect teams

Budgeting season sucks so bad can lead to interesting situations. When companies, divisions, business units, or departments negotiate their yearly budgets they sometimes need inputs from the product organization. I was at one point part of one that was, on short notice, asked to provide a yearly plan that would justify the proposed budget. We conducted a week of workshops and produced a rough plan for the upcoming year.

It was stressful but we were happy with the results. Well… a week later we had to throw everything out of the window and create a new plan. I don’t remember the exact reason. Maybe some customer complained, maybe our plan wasn’t ambitious enough, or maybe someone didn’t sleep well that night. Regardless, we were frustrated. And this happened more or less exactly the same one year later. 

Our solution to this back and forth was introducing a quarterly planning process. I think this is useful for many teams. Thus, I want to share our process today. I will also share three things that made it work for us. To start, I want to explain why it makes sense to conduct quarterly planning. 

Why do quarterly planning?

First things first, if you need something like quarterly planning you are likely part of a feature factory. And that’s fine. Most of us are not able to conduct product development in an ideal situation. We often need to deal with dependencies between teams, are subject to changing priorities, and have leadership that wants to be in control. 

Quarterly planning solves many of the issues in this context. It strikes a decent balance between serving the needs of the organization while providing some semblance of an environment for teams to actually do product work. 

To be more specific: 

• Quarterly planning helps avoid teams being blocked due to unforeseen dependencies. 
• Quarterly planning aligns product development teams that often use a two week sprint cycle with other departments that often have the quarterly cadence as a default.
• Quarterly planning provides three months of unchanged priorities. This is sufficient time for teams to actually build something. Yet it is short enough for senior leadership to feel in control. 

How we used quarterly planning to synchronize various teams

Roadmaps are at the center of the quarterly planning process. I get it, the regular time-based roadmaps are not ideal and I try to avoid them wherever I can. In the present context, though, I haven’t found a better communication tool for aligning teams and providing an overview for company leadership. 

Our process of quarterly planning consisted of these 4 steps. 

• Defining priorities
• High level estimations & cross team dependencies
• Roadmap review & refinement
• Public commitment 

We used it to synchronize five product teams within a feature factory. In our situation the main benefits were higher awareness of dependencies and giving the product teams three months where the priorities remained unchanged. 

Defining priorities

The planning process for the next quarter begins halfway through the preceding quarter. The first step in quarterly planning is defining the priorities. These provide the frame of reference for the planning. The list of priorities is also a central artifact that the teams can fall back on during execution in case of conflicts. 

In our case the leadership team provided a ranked list of things they wanted done. This was a mix of outcomes and features and included things such as Launch Italy, Increase conversion rate on website, Create report for government agency, Migrate to new business rule engine. The list was exhaustive including nearly 50 items. 

It didn’t appear out of thin air but was a living document based on the yearly company goals. And we Product Owners (POs) were constantly communicating with our stakeholders in the leadership team. Sometimes, there were still some surprises that came up. But we had an idea upfront of what the list was going to look like.

The senior leadership team created the list amongst themselves in their regular Leadership Meetings, where the head of product took part. He provided the list to the teams. 

High level estimations

The second phase is all about identifying dependencies, understanding the effort, and creating a first roadmap. The means translating the list of priorities into high level epics for which the teams can estimate effort.

To start, each PO and tech lead jointly evaluated the list of priorities. The goal was to first identify which items affected the team and how many of those were achievable in the upcoming quarter. Additionally, we identified those topics that were dependent on other teams. 

Then, it was the POs’ responsibility to sketch out the topics in the form of epics. This always included an overall summary of what was to be achieved and some of the specific goals if applicable. We essentially wrote high level user stories. 

Once that was done, each team individually conducted a high level estimation workshop. The entire team was present. I sometimes invited stakeholders if I thought it would be helpful.

This two hour workshop was simple and similar to story refinement. As PO, I presented each epic, we discussed it, and tried to clarify anything that was unclear. The goal was to make sure we understood the requirements and to come up with potential solutions. The developers then made a rough plan for implementation.  

Then, the team estimated the time needed for each epic. The estimations assumed the team would be focusing on one epic at a time. They were along the lines of “Super small, we can do this in a sprint”, “This is a bit bigger, we are going to need 2-3 sprints”, or “This is a big topic, it’s going to take us all quarter”. The more uncertain the topic the more extra weeks we added – which we later communicated. 

To me it was important to create an atmosphere where the developers could be honest in their assessment. I took their input seriously and didn’t haggle over weeks. I certainly questioned the approach if I thought it didn’t make sense but I never applied pressure to reduce the estimates. This way we ended up with realistic estimates. 

In case we identified dependencies to others we scheduled cross team refinements. These had the same structure as the high level estimates workshop but with multiple teams present. 

Finally, the POs individually created a roadmap. On this roadmap we also tagged the epics with a confidence level – high, medium, low – that showed how certain we were that we would complete each one.  

Roadmap review & refinement

The next step is creating a first draft of one big roadmap for the next quarter, getting feedback from the leadership team, and refining the roadmap based on the feedback. The goal is to create the final plan. 

In our case, the head of product presented the results of our high level estimates in the form of an overall roadmap to the leadership team. (We used Roadmunk and later Productplan to roll the individual roadmaps into one large one.) A discussion followed that sometimes led to changed priorities because of unexpected effort estimates. (“If X takes this long, maybe it’s not worth doing after all. Let’s move Y higher in the priorities list”.)

Sometimes, smallish new topics would suddenly appear. Individual affected teams had to conduct an ad-hoc high level planning and updated their roadmap on short notice. 

All other teams also finalized their roadmap including confidence ratings based on the feedback. The result was the final roadmap. 

Public commitment

Finally – and this was the most important step in our case – a company wide meeting was held where the head of product presented the plan for the upcoming quarter. Leadership publicly committed to it. 

This meeting was great for transparency. It showed everyone in the company what the product teams were going to work on. It also created a hurdle for leadership to change the plan during the quarter. They had, after all, publicly committed to it. 

The things that make quarterly planning work

As you have seen, the quarterly planning process we used is not very complicated. I want to highlight three things that helped make it effective for us. 

• Communicating uncertainty
• Remembering maintenance work
• Ongoing alignment during execution

Communicating uncertainty

A roadmap always suggests certainty. Unfortunately, product development is inherently uncertain. It’s crucial to make sure this is well known by all stakeholders (and also by the team). 

Every time I show a time based roadmap I always start with: “This is our current plan. It is our best guess right now but we have to be aware that reality will likely be different.” There is no way to state this too often. 

Uncertainty should also be documented somewhere during quarterly planning. We tagged the epics directly in the roadmapping tools with our three levels of certainty of completion in the upcoming quarter. I have also used classifications like Must have, Should have, Could have, and Won’t have in the past. It’s important that it is written down in some form.

Remembering maintenance work

When doing the high level estimates It’s important the team estimates under the assumption of “business as usual”. 

This does NOT mean spending 100% of their time on the given Epic. It means completing one topic at a time while “keeping the lights running”. 

There is always maintenance work that needs to be done, bugs that need to be fixed, and that one urgent request that is necessary to close the sale. The team should account for that work when estimating the epics. 

They can do that by assuming a fixed percentage of work reserved for maintenance. I prefer to simply remind the developers to take maintenance into account. They know what “business as usual” means and should be able to estimate the effort keeping this in mind. This is sufficient and keeps the effort low. 

Estimates are inherently subjective and not a scientific measure of effort. Making the estimation process as efficient as possible should be the goal!

Ongoing alignment during execution

I mentioned above that the priorities for the quarters were usually not a surprise to us POs because we were in constant communication with stakeholders. This is absolutely crucial. 

Ideally, you should have a stakeholder management plan. I won’t go too much into detail because I already wrote extensively on how to manage stakeholders in the linked article. Just three things. 

One, you should have a product sync with other product teams to make sure the dependencies identified during high level planning are resolved without any team having to wait. 

Two, you need to set-up one-on-one meetings with the VIPs that are part of the team that shapes the initial list of priorities. This way you can inform on progress and avoid unpleasant surprises. You will also get insights into Leadership’s thinking and have an idea upfront about what the priorities will be. If you build enough trust, you might even be able to shape the list indirectly. 

Three, use the Scrum ceremonies and other standing meetings to update on execution and on the planning process for the upcoming quarter. Transparency is key!

Quarterly planning can greatly help

If it is necessary, quarterly planning is great. It gives teams a fixed focus and room for building while allowing stakeholders to remain in control. We used a very simple four step process that didn’t cause too much extra work and can easily be adapted to many circumstances. 

To me, the most important aspect of quarterly planning is to remind everyone that product development is inherently uncertain. While quarterly planning is great for aligning an organization, remember that “No plan survives contact with reality.” Being aware of this makes dealing with the inevitable delays and unforeseen twists much easier. 

Trust me, we have all been there.