Rework and loops

Why 30% rework does not mean adding 30% to the time.

Rework is where intuition goes wrong most often. “20% of cases get sent back” sounds like adding 20% more effort, but a case that was sent back can be sent back again.

Why it is not just adding 20%

Let p be the probability of having to redo it. A case runs that step once for certain, once more with probability p, once more with probability p²… The expected total number of runs is a geometric series:

E [k] = 1 + p + p 2 + p 3 + \dots = 1 1 - p geometric series

🧮 Rework at 20% and 40%

p = 0,2 → E[k] = 1 / 0,8 = 1,25 runs → effort rises 25%, not 20%.

p = 0,4 → E[k] = 1 / 0,6 = 1,67 runs → a rise of 67%, not 40%.

The higher the rework rate, the bigger the error in thinking “just add p”.

What a loop looks like on the diagram

A typical rework loop has three parts:

The work step (drafting the file, reconciling the documents)
The check gateway (passed / failed)
The fix-up step, with a loop-back flow to the work step

ℹ

A 100% loop-back flow is normal
The “fix it” step almost always returns to the “check” step with probability 100% — it has no other branch. That is entirely valid. The probability of escaping the loop lives at the check gateway, not on the loop-back flow.

⛔

An infinite loop is blocked
The tool only raises an error when the entire loop has no branch that can escape — at that point the expected time is mathematically infinite, and returning a finite number would be a lie.

Where rework shows up in the interface

The BPMN diagram — the loop-back flow is drawn as an orange dashed line running around underneath.
The analysis charts — an orange 1,43× badge in the top right corner of the repeated step.
The per-step metrics table — the “Runs” and “Actual time” columns (= duration × number of runs).

For how it is solved in detail: Loops — Markov chains.

Anything unclear or missing?