Most engineering teams have some ritual sitting between "here's our strategy for the year" and "here's what's in this sprint." That middle layer — quarterly planning — is where a lot of teams quietly waste time: long meetings, unclear priorities, and decisions that end up shaped more by who spoke loudest than by what actually made sense.
After enough iterations to lose count, one team landed on a version of quarterly planning that avoids most of that. It's built on four steps, simple enough that nobody dreads participating, and structured enough to actually produce good decisions. Here's the whole thing, end to end.
A quick note on timing: the quarter in question is six to seven two-week sprints, but the entire planning cycle only eats up three of them — kicking off in the second-to-last sprint and wrapping in the first sprint of the next quarter.
The framework in one glance
- Write first, talk later — everyone drafts ideas independently, async, using a Why/What/How template.
- Vote twice — a blind vote sets the agenda, then a live session ranks everything with MoSCoW.
- Scope it for real — Must/Should ideas get requirements and a rough design, defended live.
- Turn decisions into artefacts — OKRs, Gantt timelines, and backlog, built by team leads.
Step 1: Ditching brainstorming for "brainwriting"
Brainstorming has an obvious appeal: gather the right people, define the problem, generate solutions fast, converge, assign owners. It's efficient — but it has one persistent flaw. In any room, the most confident or senior voice tends to win, regardless of whether their idea is actually the best one. Quieter people, newer team members, or anyone who needs a bit more time to think gets drowned out.
The fix is to front-load the thinking. The problem space gets shared in advance, and everyone writes their proposal independently before any group discussion happens — a method sometimes called brainwriting. It's slower, and it needs more coordination. But it buys more even participation, deeper proposals (because people actually had time to think), and less groupthink.
To keep write-ups comparable, everyone uses one shared template:
- Why — the problem this solves
- What — the actual proposal
- How — a rough path to implementation
It's a small constraint, but it does a lot of work — it's surprisingly hard to keep pushing an idea if you can't answer all three questions convincingly.
Step 2: A vote that happens twice, not once
Once ideas are in, a 24-hour blind vote comes first — not to decide anything, just to set the order of discussion so the live session doesn't spiral. Everyone gets votes equal to half the number of submitted ideas, and can spend up to half of those on their own proposals.
The real decision happens next: a live 60–90 minute session where ideas — now with names attached — get pitched and ranked using MoSCoW (Must / Should / Could / Won't). A few guardrails keep it fair:
- Discussion order follows the blind-vote results; ties are broken randomly.
- If there are too many ideas, the group can agree beforehand to only cover the top slice, cutting the bottom 20%.
- Authors get a short window to defend their Why/What/How.
- The Team Lead and Stream Lead each get one extra vote to break deadlocks, and the Stream Lead holds one veto, usable once.
The MoSCoW split itself is worth watching too — if everything lands as "Must have," the team has quietly over-committed. A good target is something like a 60/20/20 spread, sometimes reserving 10% explicitly for "Won't."
Step 3: Just enough design to know it's real
The last sprint of the quarter is reserved entirely for turning "what's wanted" into "what can actually be built." It's kept deliberately lightweight — gather functional and non-functional requirements, then sketch a first-pass modular design. Not a final architecture, just enough to know the shape of the solution.
Only Must and Should ideas get this treatment, and every one needs a named owner — if nobody claims it, it quietly slides down to Could have. This stage ends with a short defense session, and the real question being answered isn't "is this design perfect," it's "is this understood well enough to commit to it for the quarter."
Step 4: Turning decisions into a plan
In the first week of the new quarter, leads compile everything into three layers:
- OKRs — the quarter's top-level commitment.
- Gantt timelines — milestones, sequencing, cross-team dependencies.
- Backlog and sprints — the granular, constantly-refreshed layer.
This lets anyone — engineer or lead — track progress at whatever level of detail suits them, staying at the OKR/Gantt altitude without drifting into micromanaging sprint work.
The takeaway
A planning process doesn't need to be heavy to be effective — it just needs every rule in it to have earned its place. This is what survived after a lot of cutting, and it's already evolved since being written down, which is probably a good sign.
Teams running quarterly planning differently might have kept or dropped different things — and that's usually where the more interesting lessons surface.