TL;DR When scheduling features for a quarter, it's very risky to plan on delivering multiple projects that are starting from scratch.
Let's call this the "Shiny New Quarter" approach to planning.
Is this self-evidently problematic? Maybe to you. But apparently not to everyone, because I've seen it done repeatedly.
A year or so ago, when I took the notes that this is based on, my team at work was suffering from this in a big way. I have to credit our engineering manager for saying "no" consistently and articulately until things improved a lot.
Why is Shiny New Quarter risky?
Scheduling uncertainty increases
The beginning of each project is when we know the least about it, and therefore is when we can least accurately forecast when it'll be done.
In the worst case, we know literally nothing and haven't even estimated anything. Even in a perfect process, the uncertainty is initially high and decreases as we progress.
So every brand-new project decreases the odds that you can predict your completion dates.
This varies depending on your typical project breakdown into functional roles and how those roles interact. But a typical example might be:
We start with a pile of up-front design and research, while engineers wait for clarity on what they can start building.
We end with an inevitable crunch marathon for (especially) front-end and mobile engineers. The QA team, if there is one, gets the worst of it.
Possibly there is a devops crunch near the end too, eg. if there are new kinds of services to deploy.
Sandwiched somewhere in between is a crunch for any back-end or other work that is a dependency for the client-facing work.
Crunch time side-effects.
End-of-quarter crunch marathons have bad side effects: more fatigue, more bugs, more forced tech debt, more last-minute surprises during integration work, lower team morale, lower quality of the delivered product. If every quarter ends in crunch time for a year, you might want to stop doing that to yourselves.
The things you can deliver in a quarter are limited to those things you can start and finish from scratch while laboring under unbalanced load. Three months is a nice-sounding upper bound for project length, but it doesn't have to all be the same three months.
It's simple and hopefully obvious by now. To more effectively parallelize work, at any given time there should be a project in each stage of your process.
To achieve this, simply stagger the project kickoff dates. Aim to have a project in early research stages, a project primarly in design, a project primarly in back-end work, and a project primarily in front-end or mobile work, a project in final testing.
- We are more likely to be able to communicate and meet our delivery dates.
- We are less likely to have painful crunch time and fewer side effects.
- Over the long term, the average number of successful completed projects per cycle should be higher.
You can think of this as planning for maximum long-term throughput rather than for minimum short-term latency.
In this approach, ending a quarter with projects in many stages of progress wouldn't be cause for alarm; it would be the normal way we set up success for the next quarter.