A Developer’s Guide to the Magical Mystery Tour That Is Quarterly Planning 😂
At my company in Ireland, we plan our Engineering team work every quarter.
Honestly, it’s a massive improvement on a few years ago when we built yearly roadmaps. Those roadmaps were usually out of date about 5 minutes after we finished them and, unsurprisingly, were rarely delivered exactly as planned.
Now we plan quarterly, which makes much more sense.
As a Eng. Lead, I’m expected to help shape the plan, working with Product and Directors.
Simple, right?
Well… apparently we don’t all use the same calendar. 😂
A quarter has 3 months.
We run 2 week sprints.
So, roughly 6 sprints per quarter.
Product sees this and thinks:
“Great! We have 6 sprints. How much can we fit in?”
Meanwhile, Engineering is looking at the same quarter thinking:
“Hang on… we have freezes, team holidays, focus weeks, dependencies, support work, unexpected issues, and probably something nobody has thought about yet.”
Then there’s the tiny detail that development work occasionally takes longer than the estimate suggested.
Shocking, I know. 😂
The reality is that not every sprint is 100% available for new feature development. And even when the capacity looks good on paper, the timing of when work actually starts can have a huge impact on what can realistically be delivered.
But despite all of this, we still do our best to deliver what we commit to.
And then, when something doesn’t finish exactly on time, the question becomes:
“Why didn’t this finish smoothly on schedule?”
Well…
Because we’re humans building software, not Excel formulas filling empty cells.
Surely I’m not the only Engineer Lead who has this battle every quarter?
Do other engineering teams deal with the same quarterly planning stress?!?