Specify Just in Time

This is the second part of the product owner toolbox. The running example is a tool that replaces the spreadsheet a 300-person company uses for holiday requests.

The old way to build the leave tool would be a specification first: forty pages covering every leave type, every approval path and every edge case around the end of the year, signed off before anyone writes code.

That fails in two ways, and both cost money.

The content goes stale. Requirements change while you write them, and so does the world around them. By the time development reaches page 30, page 30 describes a need that no longer exists. Writing it was wasted effort, and updating it is more.

The detail is too deep. Half of what’s specified never gets built, because priorities move or the first release teaches you something. You paid for the detailed description anyway.

Detail on demand

Just-in-time specification means a requirement is only as detailed as the next step needs. It gets refined step by step, as part of the work, from a rough idea to something a team can build:

1. Idea: one line. “Employees can see their remaining days.”
2. Backlog item: enough to rank it against other items.
3. In progress: discussed with the team, cut to a size that fits a sprint.
4. Ready to build: acceptance criteria, edge cases, open questions answered.

You only move to the next level once going there makes sense for an actual implementation. If an idea is dropped, documentation stops immediately. The rule I use is: as early as necessary, as late as possible.

From why to what

The same idea applies to the whole hierarchy of backlog items:

• Vision: why the product exists
• Goal: what we want to reach next
• Epic: a large need or problem worth investing in
• Feature: a piece of functionality for a group of users
• User story: a slice small enough for one sprint

The higher up an item is, the more it says about why. The lower down, the more it says about what. Detail and cost increase with every step down, and so does understanding.

The format changes along the way, too. At the top, draw: a sketch of the process, a picture of the person who suffers from the spreadsheet. Pictures build a shared understanding of the context faster than text, and they make the refinement later much easier. At the bottom, write: text, a model, acceptance criteria. And talk, with a drawing on the whiteboard next to you.

Don’t finish a level, follow the priority

Detail is driven by priority, not by level. You don’t complete every epic, then every feature, then every story. You only go deeper where the work is about to happen.

For the leave tool, that means the vision is written and there are four epics on the board. Only one of them, “request and approve leave”, is broken into features. Only the first two features have stories. “Carry over unused days into next year” is still a single line, and that’s correct, because nobody will touch it before spring.

Your levels, your definitions

In practice, few teams need every level. A small product can start with features and stories and add epics once there are enough features to group. What matters is that the team defines every level it uses, including who prioritises at that level.

Tools disagree on the words. In one setup a feature contains epics, in another it’s the other way round, and some teams use “theme” for a group of anything. Mike Cohn made the point years ago that story, epic and theme are just words that make some conversations easier. Pick a meaning, write it down and use it consistently.

Next

Every level in this ladder hangs from the top one. So next time I’ll write the leave tool’s product vision and explain why its most important job is to say no.