In a fictional online shop, orders containing two parcels are charged twice for shipping even though the advertised price covers both. Support refunds the excess charge.
The fix takes two hours on Tuesday morning, followed by one hour of testing and review. It is ready at noon. Company procedure requires approval at Thursday’s committee and release at noon the following Monday.
Three hours of work, then six days of waiting. The times and volumes in this article are assumptions for the worked example. They let us calculate the work left with support after the development ticket is complete.
The ticket is marked complete at noon on Tuesday
This is the timeline used in the example.
| When | Event | What the customer sees |
|---|---|---|
| Tuesday, 9–11 am | Calculation fixed | Shipping still charged twice |
| Tuesday, 11 am–noon | Tests and review | Error still present |
| Thursday, 2 pm | Approval committee | Error still present |
| Following Monday, noon | Release | Shipping charged once |
Development tracking stops at the second row. Support has to keep working until the fourth. In this scenario, the committee approves the fix without requesting any further changes.
Daily meetings change none of these dates. Everybody knows the fix is ready, but those attending the morning meeting cannot authorise its release. Another status report would record the same obstacle again.
Six days add three hundred refunds
The example assumes fifty affected orders a day over those six days, with each refund taking two minutes to process.
50 orders × 6 days × 2 minutes = 600 minutes, or 10 hours of support work.
This excludes additional complaints and customers’ time. It also does not treat the refund as a commercial loss: the excess charge had to be returned anyway. It isolates ten hours of manual work after the fix was finished.
Halving the two hours of development would have saved an hour on Tuesday. With the same committee and release slot, the fix would still have arrived on Monday. All three hundred refunds would still have been necessary.
The release delay therefore deserves an explicit decision. Here, six days of waiting cost ten hours of support work. Any risk that justifies the delay needs to be weighed against that cost, rather than disappearing behind “that is the procedure”.
Can approval happen on Tuesday?
Answering this requires specifying what the committee checks. In our example, the evidence includes the two-parcel basket reproducing the error, the expected charge, the corrected result and a second developer’s review. A single-parcel basket is also tested to check that its price remains unchanged.
If the committee receives those same items on Thursday and accepts them without asking for further evidence, the intervening two days added no verification. An authorised person could examine the material on Tuesday. The check would remain, without depending on the weekly meeting.
Release has its own constraints: someone available to monitor it and a procedure if the new version fails. If those conditions can only be met on Monday, the wait has an identified cause. The capacity to release then needs attention, rather than the developers’ speed.
The expected result is an earlier release date
A process change will have helped this case only if it allows release before the following Monday with the required checks in place. Renaming board columns or shortening the morning meeting leaves the refund calculation unchanged.
The comparison follows the same events: review completed, release authorised, change deployed. It shows where time was saved and whether a check was removed or simply brought forward.
This example does not establish that every committee is unnecessary. It shows that additional development capacity is not the missing resource here. The fix already exists. What is missing is a release decision before support processes three hundred more refunds.
When every initiative needs permission examines a different case: an improvement that cannot even begin. Both belong to the five faces of technical debt.