Skip to content
EmargenEmargenDocs

InitiativesIdea

Decomposition

The decomposition shows what an initiative will change before anyone builds it. Which screens, which code, which data, and what still needs a person’s answer. The agent draws it on its own once an approach is chosen, by reading your organisation’s code.

A plan you can check against the code

Section titled “A plan you can check against the code”

A chosen approach says in words how the work gets built. That’s enough to agree on, but not to plan from. Someone still has to check what needs changing and what can stay. Without that, you find surprises halfway through the build.

So once an approach is chosen, the agent reads the repositories your organisation added against it, and writes the decomposition in the background. When it can’t read a repository, it says so. Everyone who can open the initiative then sees what the work touches before they promise a date or take a task.

The pieces, where they live, and what’s open

Section titled “The pieces, where they live, and what’s open”

The map connects what people see with the code behind it and the data it keeps. It marks each piece as new, changed or already there. That’s the decomposition’s first page, Affordances.

Places and flows shows where the pieces live, like a settings page or an email, and shows each flow across them, a step at a time. The agent can draw a rough screen of each place too. Questions holds what only a person can answer.

Take an initiative that switches all of a customer’s depots to single sign-on at once. An administrator presses one new button. Behind it, new code switches every depot that passed its test, through the per-depot switch the sign-in service already has. The depots’ sign-in settings change. A support lead reads the same map to see which settings page changes, before the first call about it.

The affordances map of ACM-293: three columns, UI 7, Code 6 and Storage 2, each with a bar of new, changed and unchanged pieces and its rows, such as Switch every tested depot on, button; the row picked, with a note beside it: UI3, button, Opens the confirmation with the depots that will switch and the ones left out, In A1 One switch.The affordances map of ACM-293: three columns, UI 7, Code 6 and Storage 2, each with a bar of new, changed and unchanged pieces and its rows, such as Switch every tested depot on, button; the row picked, with a note beside it: UI3, button, Opens the confirmation with the depots that will switch and the ones left out, In A1 One switch.
That initiative at ACME, the company in the docs' pictures. The new button is picked, with what it does and the part of the approach it belongs to.
  1. UI. What a person sees and does.
  2. How many of its pieces are new, changed or as they are.
  3. Code. What runs underneath.
  4. Storage. What the code keeps.
  5. The new button, picked.
  6. What it does, and the part of the approach it belongs to, A1.

An answer for now

Section titled “An answer for now”

The agent doesn’t stop where the code leaves a question. It asks, and each question says what the plan assumes for now, and what changes if the answer goes the other way. We keep it to five at most, the ones that hold up the slices first, because a long list of doubts doesn’t get answered.

In the example, the service that sends the day-before email needs to know who manages each depot. For now, the service that sends it asks the sign-in service. Otherwise, it keeps its own list, and someone has to keep that list up to date.

A question on ACM-293's Questions page, Open: Should the notifier ask the identity service who manages each depot, or keep its own list? Above it the chips A4 Day-before email, CO5 Email depot managers the day before and R4; under it For now and Otherwise, each in a sentence, and the buttons Go with this, Answer… and Investigate.A question on ACM-293's Questions page, Open: Should the notifier ask the identity service who manages each depot, or keep its own list? Above it the chips A4 Day-before email, CO5 Email depot managers the day before and R4; under it For now and Otherwise, each in a sentence, and the buttons Go with this, Answer… and Investigate.
The question, with the part of the approach, the piece of code and the requirement it's about.
  1. What it’s about: the part of the approach, then the piece of code and the requirement.
  2. Open until someone answers it.
  3. For now. What the plan assumes until then.
  4. Otherwise. What changes if the answer goes the other way.
  5. Go with this, Answer… or Investigate: the ways to answer it.

The owner, or someone who edits the initiative, answers it. Go with this keeps the answer for now. Answer… lets you write your own. Investigate opens a spike on it. Nothing runs straight away. The next analysis uses the answer.

Analysed again

Section titled “Analysed again”

The analysis runs again when the approach changes, and whenever someone who edits the initiative asks with Refine, adding a note on where to look. A piece the code still confirms keeps its id, so you can still find it from a slice or a comment.

Once the initiative is approved, a new analysis can only add or correct pieces no started slice uses. To change a piece a started slice uses, someone raises a change request.

Slices and the Kickoff

Section titled “Slices and the Kickoff”

The slices are cut from the decomposition’s pieces, and each says which parts of the approach it builds. The Kickoff lists the questions still open for whoever approves. Everyone who can open the initiative reads the decomposition and comments on any piece.

Next

Section titled “Next”

How to

Page by page