Office pull: capacity, blocked work and aging

Office pull: capacity, blocked work and aging

A request board becomes useful when the team agrees what may enter active work, what completion means and what to do when progress stops. Begin with a provisional capacity limit, not a supposedly universal number. Keep blocked requests visible and counted so that the limit reflects real commitments. Review old work and remove obstacles before admitting more. A limit can expose a dependency that another team must help resolve. Judge the experiment by completed service, elapsed time and rework, not by how many tickets moved between columns. Urgent work needs an explicit exception policy.

Follow the method

1. Ready
2. Active: limit 3
3. Blocked: counts in 3
4. Done

A blocked card remains inside the active limit

Fictional administrative team: the agreed active-work limit is three requests, including blocked work. R1 and R2 are progressing, R3 awaits a required approval, and complete request R4 is ready to start. Coordinator Devon is asked to move R3 off the board so R4 can be admitted.

Follow the method

1. Initial review
2. R3 blocker check
3. R1 accepted complete
4. R4 pulled
5. R3 moved off-screen only

A blocked request still occupies the system

Count blocked work inside the declared active limit, choose the next action from capacity and age evidence, and retain explicit control of urgent exceptions.

Fictional administrative team: the agreed active-work limit is three requests, including blocked work. R1 and R2 are progressing, R3 awaits a required approval, and complete request R4 is ready to start. Coordinator Devon is asked to move R3 off the board so R4 can be admitted.

Role: Office team coordinator with the approval owner.

Normal condition

Ready work is pulled when capacity is available; the team sees all accepted active work, its age and its blockers.

The gap

Moving the blocked card to an uncounted list would make the board appear to have capacity that the agreed rule does not provide.

• The limit of three is a local teaching policy, not a universal recommendation.
• Blocked means accepted but unable to progress; it does not mean completed or canceled.

1. Count the declared boundary

   Devon counts two progressing requests plus one blocked request. He records three active items against a limit of three and leaves R4 in Ready.

   Why: A WIP limit is meaningful only when its entry, exit and blocked-work rules remain consistent. Relabeling work does not release capacity.

   Evidence: 2 progressing + 1 blocked = 3 active; no ordinary slot for R4.

2. Investigate age and the blocker

   The team checks why R3 has waited four working days, whether the approval request was complete, and who can provide a decision. It records a next contact time rather than simply coloring the card red.

   Why: Aging prompts a response to accepted work. The oldest item is not automatically the most urgent, but its wait needs an explanation.

   Evidence: R3 has an approval owner, missing decision and next review time.

3. Help finish or unblock before starting

   Devon asks whether available colleagues can help R1 complete its review or assemble the missing approval evidence for R3. They retain each request’s acceptance criteria.

   Why: Starting more work can increase context switching while leaving completion unchanged. Helping finish must not bypass required checks.

   Evidence: One named support action, with the request still counted until genuine completion.

4. Admit the next eligible request visibly

   When R1 is actually completed and its acceptance evidence recorded, the active count falls to two. The team then pulls R4 using its agreed ready-queue ordering rule.

   Why: The release is linked to a real exit event, not to optimism that someone will finish later.

   Evidence: R1 completed; R2 and R3 remain active; R4 admitted; count returns to three.

5. Review the rule and recurring constraint

   Record blocked age, completion rate and any exceptions over a representative period. If approval delays repeatedly occupy the limit, address that dependency with its owner.

   Why: A board alone cannot remove a cross-team response failure. Changing the limit needs an explicit learning decision, not a hidden workaround.

   Evidence: A review record names the recurring approval cause and a test of response reliability.

An urgent request cannot wait for the normal rule

An authorized service owner declares R5 urgent under the existing exception policy while all three slots remain occupied.

Use the documented exception: name its approver, identify which commitment changes, record the temporary count and set a review/exit condition.

Urgency may justify a controlled exception; hiding an extra start prevents the team from seeing its cost or restoring the normal limit.

Exception record identifies R5, approval, temporary WIP and displaced work.

Run a practice session

Materials

• Request cards and a three-slot board
• Separate Ready area and blocker-response log

1. Define the active boundary · 4 minutes

   Does changing a card’s location change its commitment?

2. Work the three-slot case · 7 minutes

   What can the team do before starting R4?

3. Run the four-slot and urgency variants · 9 minutes

   Which evidence legitimately creates a slot?

4. Transfer the rule · 5 minutes

   Who owns a blocker outside this team?

Debrief

• Ask learners to describe an explicit exception without making it the normal route.
• Check whether age is measured consistently and used without blaming the assignee.

Count every accepted request on paper, then narrate the admission event and the unresolved blocker.

Transfer into the work

Owner: Service team owner with cross-team approval counterpart

Record: Active-work history, blocker age, completion evidence and exception log

Review: At the daily work review and the agreed policy-learning review

Evidence: Honest WIP, improving completion/age and fulfilled acceptance criteria

Escalate repeated external waits; revise readiness, response or WIP policy with a visible hypothesis.