Initiative

If nothing in the backlog is bigger than a few weeks of work, quarterly planning runs into a wall. The backlog is the ordered list of everything that might get built, and a list of forty multi-week chunks is not something you can hold a three-month conversation over.

The scene went like this. Someone asks what the quarter holds, and the owner starts reading the list down: card registration, refund handling, receipt delivery, failed-payment notifications. Ten lines in, nobody can hold the individual lines, and nobody notices that all of them are the same subject. Those ten lines were one piece of work, and the list had no name for that one piece.

An initiative is the layer that supplies the name. The unit branch of a product backlog stacks by how big a single line is: initiative at the top, then epic, then user story, then task at the bottom. The layers exist because deciding order and doing the work happen at different moments. A quarterly plan has to fit on one screen as ten large items; this week's engineering has to be broken down to something one person can finish in a few days.

A line at this level describes not what gets built but what should be different once it's done. "Rebuild the payment experience from scratch" is the name, and epics like card registration, refund handling and receipt delivery hang beneath it. An epic is a large chunk that splits into pieces, usually a few weeks long, and below that sit tasks one person can finish in days.

Five fields go on each one.

1. The end state — a sentence describing what has changed when this is finished. "Half as many users drop out at payment as today" works. Write a means here instead, like "replace the payment module," and the whole initiative becomes wrong the moment that means turns out to be wrong.
2. Why now — the case for spending this quarter on it. Leave this blank and there is nothing to reason from two months later when something else becomes urgent.
3. How it gets checked — the number or condition that settles whether it happened. Ideally it measures field 1 directly; otherwise name the closest stand-in and say why it stands in. Picking the figure at the start also forces the end state in field 1 to be written in terms something can actually count.
4. Duration — typically one quarter or one half. Anything nowhere near fitting in three months gets split into two.
5. The epics attached — the list of what's needed to reach that state. Nobody knows all of it at the start, so it opens with three or four and grows or shrinks along the way.

Ordering happens at this level too. Choosing which of five goes first is prioritization, and cutting here beats cutting a layer down. Cut by epic and half of a payment initiative ships, which from the user's side means nothing changed at all. Dropping a whole initiative is the more honest cut, and it leaves the remaining ones intact enough to finish.

Three places. The first is quarterly or half-year planning: a five-line list makes what you decided not to do visible on the same screen. The second is as the display unit of a product roadmap, the chart of what gets built roughly when — put epics on it and the reader has forty rows to get through. The third is naming work that crosses teams. When payments involves engineering, design and support at once, each team keeps its own list, and only a shared name above them shows that the three lists are one piece of work.

There are also teams better off without the layer. In a product with one team doing one thing at a time, initiative and epic collapse into the same line. Every extra layer costs effort in moving items and keeping names aligned, so with no real gain from the split, stopping at epics is the better call. The same holds for teams that skip quarterly planning and work in two- or three-week horizons.

"This should go in as an initiative, not an epic. Three teams are involved."

It's past the size one team finishes in a few weeks, so it belongs a layer up.

"Three initiatives this quarter, and the rest waits."

Setting how many large items the quarter will carry.

"The initiative says 'module replacement,' but that's a method."

This layer takes an end state, not a means.

At Pagedeck, Mia assembles the candidates two weeks before the quarter starts. Last quarter twelve payment-related lines were scattered through the list, and she pulled them under one line: cut the number of users who leave without finishing payment in half. The check was a single figure — the share of people who reach the payment screen and leave without completing.

Grace's question about that line was whether all twelve were actually needed. Theo answered that four of them couldn't be touched until the failure causes were known, so the first six weeks attached one epic for failure logging and left the rest to be decided from the results. By mid-quarter the attached epic list had become six — two of the original twelve turned out to be the same problem, and three new ones came out of the logs — while the line above it stayed the same. That's the normal shape: the epic list churns and the end state doesn't.

The most common mistake is reading an initiative as a very large epic. Described as one layer up, it sounds like a size difference and nothing more. But the two layers hold different kinds of content: an epic states what gets built, an initiative states what must be different. Go by size alone and you write the thing being built in larger words — "complete payment system overhaul" — and at quarter end nobody can judge whether that line is finished.

Believing a quarter can hold several initiatives is nearly as common. Adding a line to a list feels free, and a team with a lot it wants to do drifts to five or six. But one line at this layer is sized to consume an entire quarter. A company with two teams that starts five initiatives ends the quarter with five things half-done, which from the user's side is a quarter where nothing shipped.