The plan fits on a page

What has to fit on the page

Jeffries's card does not hold the whole requirement. It has just enough text to identify the story and remind people what it is. The card is a token for planning. Notes on it record priority and cost. He has almost never found a multi-page specification ideal, and he says that kind of document is more likely to slow you down.

Patton's frame, before a story map, is a short brief that constrains what you map. He also asks for the benefit, and for what the user does. I hold that brief to one page. Goal, cost, and what done means. Who can reach the data, and how that can be abused. A file no one will review is not the plan. That limit is mine. Neither of them published a one-page rule.

Jeffries, card, conversation, confirmation·Patton, story mapping·SDLC field card

The page is not the understanding

Jeffries puts the requirement in the conversation, an exchange between the customer and the programmers, not in the card. However much documentation you produce, he says you still cannot be certain enough about what is to be done. Certainty is the third part: the customer says how she will confirm the story, and that confirmation is the acceptance test. The best supplements are examples. The best examples are executable.

The manifesto puts working software ahead of comprehensive documentation, and it says the documentation still has value. The principle I use from it is face-to-face conversation as the way a team conveys information. Beside that, my rule: the page still has to exist, and a meeting with nothing written down does not make the change safer. The writing is required, and it is not sufficient.

Fowler calls a story handed to developers to implement a decreed story, and a misunderstanding. The story is refined in conversation. Developers help find the gaps, the cheaper alternative, and the split. Wake's word for that is negotiable. The story is not a contract for features. It captures the essence, and the details are created by the customer and the programmer during the work.

Jeffries, card, conversation, confirmation·Agile manifesto, 2001·Agile manifesto, face-to-face·Fowler, conversational stories·Wake, negotiable

Who can reach the data

Shostack's site states four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good job. I put the first two on the plan page.

Microsoft's Security Development Lifecycle names threat modeling as a core element, in five steps: security requirements, an application diagram, the threats, the mitigations, and a check that the mitigations happened. The tool's notation draws components, data flows, and security boundaries. I do not treat the tool as the plan. The page still has to name who can reach the data, and how that reach can be abused. NIST SP 800-218 practice PW.1 asks for that identification in design. I write it on this page, where a person will review it.

Shostack, four questions·Microsoft SDL, threat modeling·NIST SP 800-218, PW.1

The walk

This is the order I use before a change is built.

1. Write the page first. If it will not fit, the change is more than one change. Split it until a person can review what remains.
2. Patton's map runs left to right in the order you would tell the story. Conversation carries the variations. In the explore pass he asks what could go wrong, and what the user does to recover. I do not start the build until someone has walked one of those failures out loud and the page names it.
3. Fowler's conversation is allowed to change the page. A cheaper path, a split, or a gap is a result, and it gets written down. When the page reaches the build unchanged, I treat the walk as not done, and I walk it again.
4. Jeffries's confirmation is how the customer will know the story is done. I want that as an example someone can run. A confirmation that cannot fail is not a check.

Patton, story mapping·Fowler, conversational stories·Jeffries, card, conversation, confirmation·SDLC field card

What I inspect

These are the questions I ask of a plan. They are my check, not a list Jeffries or Patton published.

1. Can a person review this plan in one sitting?
2. Does it name the goal, the cost, and what done means?
3. Who can reach the data, and how can that be abused?
4. Has someone walked the journey, including a failure, and what did that change on the page?
5. What example will show the story is done, and can that example fail?

How I would know

I keep two counts. How often the plan is still one page when the build starts. How often the walk changes that page before the build: a split, a cheaper path, or a named abuse. When a plan reaches the build unchanged, I do not count the walk. When it outgrows a review, it has stopped being the plan. I do not have a target number for either count.

Where I do not use it

Patton's limit, which I use: if you need the precision of a workflow, a flow chart, or a UML model, a story map is the wrong tool. I use the page to decide the change. I do not use it in place of a design that has to be exact.

Wake's negotiable story is not a contract. I do not freeze the page against the conversation that is supposed to change it.

An agent may draft the page. It is not the plan until a person has reviewed it and walked a failure.

Release calendars, blast-radius proof, and the cutover sequence stay on the technology delivery field card. This page decides the change. It does not pick the window.

Patton, story mapping·Wake, negotiable·Technology delivery field card