Example data. Fieldnote is a fictional company used to fill all 61 boards, so the examples tell one consistent story.
Scale-up Fieldnote, the board Karim keeps updated after PI Planning so the three squads see the same dependencies every Monday.
What the team took away
Five strings, none crossing backwards after the sprint 2 move. The board goes on the wall next to Marc's dispatch screen, half joking, half not.
How to run it
Preparation
RTE plus the PO of each team. No developers: this is a maintenance session, not a planning one.
Send the current board and the list of features that moved since the last update 24 hours before.
Have the milestone row and the dependency strings visible. Prepare red stickies for slipped items.
Agenda
15 min
What moved Each PO states in one minute what shifted in their row since last time: done early, slipped, dropped.
40 min
Update the strings For every slipped feature, follow its dependency strings. Ask the receiving PO: does this break your sprint? Move or cut on the spot.
20 min
Milestone check Walk the milestone row. Any milestone with a red feature upstream gets a risk sticky and an owner.
25 min
Capacity reality Compare the load per sprint to the printed capacity. Any sprint over 100 percent gets one feature pushed right, chosen by the PO, not the RTE.
20 min
Publish the delta Write a five-line summary: what moved, what is at risk, who owns what. Send it to the train before end of day.
Pitfalls
Do not re-plan the whole increment. If more than a third of the board moves, you need a PI re-plan, not a board update.
Do not let a PO move a feature into a later sprint without asking who was waiting for it. The strings exist for that.
Do not keep zombie features on the board. If nobody can say who needs it, remove it and note it in the delta.
Afterwards
The board feeds the weekly sync and the Inspect & Adapt. Features that slip twice in a row become a topic for the dependency map or the next PI Planning.