QUARTERLY PLANNING EXERCISE
Nikhil Bhardwaj
Pharma Advertising & Analytics | Empowering Pharma Clients with High-Impact Advertising and Data-Driven Insights
One of the most effective quarterly planning techniques I’ve ever experienced came from a tech company I worked for in North Carolina’s Research Triangle. This wasn’t your typical planning session—it was what I’d call “AGILE quarterly planning” with an emphasis on speed, time-boxing, and integrating QA and team dependencies as key parts of the planning process.?
Here’s something I’ve learned after more than a decade of studying Agile and development: Success and dysfunction can coexist in tech. It’s entirely possible for a company to post 30% YOY growth and still have a chaotic environment. Conversely, a high-functioning Agile team might still struggle financially. The truth is, the two aren’t always connected. Still, this planning approach creates a collaborative and dynamic environment that can be a real game-changer for some organizations. Here’s a step-by-step guide to help you apply this powerful planning process to your own team!
PRE-GAME
Before you dive in, you need a clear vision of what you want to build. Prioritization, strategic alignment, OKRs, and socialization are essential, but those topics deserve their own guide. A quick review of these concepts could’t hurt.
BUILD CROSS-FUNCTIONAL TEAMS
This planning approach shines when teams are empowered to handle most of the product release independently. Of course, dependencies and prerequisites from other teams will still exist. These are addressed during this process, ensuring smooth collaboration and execution.
DAY 1: TEAM INTRODUCTION
Our planning session included teams from multiple offices, including Raleigh and Austin, all connected through Zoom and large conference rooms for the kick-off. After everyone grabbed some coffee, the facilitator kicked things off by introducing the participants and setting the stage for what’s ahead.?
This first day is all about getting everyone engaged right from the start by building energy and enthusiasm. Depending on the group, consider an icebreaker or a fun introduction activity to keep spirits high and set a collaborative tone for the rest of the session.
DAY 1:PLANNING & ESTIMATION
After the kick-off,? team goes into their own conference rooms or Zoom calls and starts the process of breaking the new features or tools down into smaller, manageable tasks. This is sometimes called ‘refinement,’ but it’s accomplished through a group conversation amongst all the people on the team.?
Going through each feature one by one, engineers will ask questions of the group (including the product manager) to uncover steps involved to implement the feature.? Consider these high-level questions for getting started:
People can struggle with this because although knowing a lot about your technical area helps, you need to lean on other skill sets including having a comfort-level with communication and asking questions.? It’s good to be open and curious,? draw on what you don’t know, and use those gaps to fuel the questions you ask.?
Estimate the Features
If planning gets derailed , it’s often during the estimation process. Estimation within AGILE or SCRUM often garners strong disagreement, dismissiveness, and all manner of other negative reactions. A surefire way for someone to stop the process in its tracks is to say:
“I don’t have all the details so I can’t give you an estimate”. Or “It could be 3 weeks or 3 months depending on the requirements, I just can’t tell you how long it’s gonna take.”?
A cross functional team makes this process much easier. Teams can engage in all sorts of group estimation techniques, fibonacci, T-shirt sizes, etc.?
The goal of an estimation activity is to uncover the conversation that originates from wildly different estimates. So if someone estimates Large vs. Small, a conversation can ensue, and the group learns more about the work ahead. This ultimately leads to better estimates.???
After each estimation, you can adjust the board, moving tasks across the weeks and months of the quarter.? Don’t let anyone tell you that planning cannot be done this way. It can work;? the only difference between success and failure is whether or not people choose to embrace the process.?
The goal at the end of the day is to have a white board, with each swim lane looking like this:
During this process, remember that this is not about defining the how. If teams get bogged down in the how, remind them to keep it high level as a way to maintain momentum. Derailment is a risk at this stage, so be aware.?
Another thing to keep in mind is dependencies. If a team needs something from another team (e.g., data science or analytics) to validate or serve as an initial input, record this dependency within your swimlane. The team providing the input should also have a story in their swimlane.
END OF DAY 1: READOUT
After the first day, planning meetings, nominate a member of each team to provide a high-level summary of what the team accomplished.? This should be a general overview of the team’s work, including any technologies involved. The purpose here is to socialize the work across the larger group and highlight the accomplishments of the team. The readout should only be 5 minutes or so.?
DAY 2: FOLLOW UP
Day 2 is about continuing the process from Day 1.? There may be some unfinished? conversations from Day 1 so make sure you try to clarify as much as possible. This could include identifying dependencies from other teams and ensuring that stories are added to their swimlanes and yours as needed.???
MAP DEPENDENCIES
A really effective way to understand dependencies in a process like this is to draw connecting lines from your sticky notes in your swim lane to dependency stories in other swim lanes. The final product in Figma or on a physical board can look a bit like a mess with spaghetti lines everywhere. Even so, it can be an effective way of? understanding the complexity of a particular project,? and it can provide a better? estimate of what can actually get done in a quarter.?
FINAL READOUT
To cap off what has been accomplished, the final readout highlights the accomplishments the team has made over the last 2 days.? Teams are encouraged to talk about the things they learned during the process or simply go over the features and systems.