Initiative Status Diagrams with Boxes and Lines

Throughout most of human history, the big things we built were plainly visible. How’s the bridge going? Look for yourself. How’s the harvest? You can see it. Now here we are, and some of the most important things organizations work on are intangible concepts in our heads and bits on a computer.

There’s surely prior art, but my teams have coalesced on a simple diagram that’s proven useful for seeing where we are on bigger projects. It helps drive initiatives and gives everyone a shared mental model of what we’re building. Stakeholders, engineers, leaders, and testers all reference it to drive discussions and get alignment. Sometimes in conversation we’ll point to areas of the diagram even when it isn’t in front of us — it lives in everyone’s head.

This isn’t a replacement for gantt charts, epic burn-downs, or a well-placed sequence diagram. It complements those things. The diagram can communicate a lot of detail, but the best part is that you can blur your eyes, glance at it, and get a gut feel for where the project is.

What the colors mean

It’s a basic boxes-and-lines diagram, with colors that have specific meaning:

• Gray — no work to do for this initiative, but it’s interesting enough to show on the diagram.
• Red — work has been identified, but no code yet.
• Yellow — code is being written.
• Green — production ready. Testers have validated it; dependent systems are integrated and satisfied.

For me, the direction of arrows doesn’t indicate data flow. Source knows about destination from a network perspective — you can read it as “source depends on destination.”

Building it in DGMO

DGMO’s boxes-and-lines chart type pairs perfectly with this. Define a Status tag group with the four colors, then mark each box with | s: <status>. The active-tag directive tells the renderer which group to color by.

boxes-and-lines Checkout Initiative

tag Status s NoWork(gray), Identified(red), InProgress(yellow), Done(green)
active-tag Status

direction LR

Mobile | s: Done
  -> Back End | s: Done

Web Front End | s: Identified
  -> Back End | s: Identified

Back End | s: InProgress
  -getUser-> Vendor | s: Done
  -getEvent-> Vendor | s: Identified
  -> Identity Service | s: Done
  -> Some Service | s: Identified
  -> Database | s: InProgress

Vendor | s: InProgress
Identity Service | s: NoWork
Some Service | s: InProgress
Database | s: Done

A few things to notice:

• tag Status s ... declares a tag group named Status with short alias s, plus the four named values and their colors.
• active-tag Status tells the renderer to color boxes by their Status tag.
• | s: InProgress is pipe metadata — assign the tag value to a box (or an edge).
• Indented edges under a box ( -getUser-> Vendor) declare arrows from that box. Labeled arrows like -getUser-> are great when you have multiple calls between the same two systems.
• direction LR lays the diagram out left-to-right.

Reading the diagram

From the example above:

• Mobile is completely done.
• Web Front End hasn’t begun at all.
• Back End is done with getUser but hasn’t started getEvent.
• Identity Service required no work and integration is done.
• Some Service has started their work but we haven’t started calling them.
• Database work is done and we’re coding to it.

Why this works

• Stakeholders understand current status at a glance.
• Engineers get a sense of accomplishment when boxes change color. On weekly initiative calls we celebrate color changes — sometimes updating the diagram in real time and sharing it in team chats.
• Engineering leaders are accountable for their systems and know the status of their dependencies and dependents.
• Dependencies become clear. Areas of stagnation are obvious.
• It drives discussion. With a shared model, product and process people know who to ask to clear obstacles and build momentum.

Refinements

You can color edges too — not just boxes. That’s useful when one team’s API has multiple calls in different states of done-ness. Add | s: Done to the edge declaration:

boxes-and-lines Checkout Initiative — refined

tag Status s NoWork(gray), Identified(red), InProgress(yellow), Done(green)
active-tag Status

direction LR

Mobile | s: Done
  -> Back End

Web Front End | s: Identified
  -> Back End | s: Identified

Back End | s: InProgress
  -getUser-> Vendor | s: Done
  -getEvent-> Vendor | s: Identified
  -> Database | s: Done

Vendor | s: InProgress
Database | s: Done

Other refinements that have worked for me:

• Multiple lines between the same two boxes — if you have several API calls or use cases between two systems, draw them individually. Don’t go overboard.
• Dashed green for partial done-ness — done and validated by their own testers, but the client hasn’t finished coding to it. Be careful, this gets confusing fast.
• Self-loops — if a box does something important that isn’t an external call and you really want it on the diagram, an edge looping back can work. Most of the time, skip it — too much detail to help coordination.

Try it yourself

The fastest way to start:

1. Online Editor — write DGMO and see it render live in your browser
2. Desktop app — full editor with live preview and click-to-source navigation
3. CLI — render from the terminal with dgmo diagram.dgmo -o output.png

Initiative status diagrams are text. They live in your repo, get reviewed like code, and stay current — which is the whole point.