Your tracker has states for work that has not started, work in progress, and work that is finished. Ask it to express "this was delivered, reviewed, and sent back because it solved the wrong problem" and most of them quietly collapse that into moving the ticket back to In Progress.
That collapse throws away the most useful signal you have.
What gets lost
When a rejected delivery is represented as a state change rather than an event, you lose:
- That a delivery happened at all. The cycle-time number now says the task took nine days, with no indication that it was done on day three and redone twice.
- Why it came back. "Requirements changed" and "the brief was ambiguous" and "the implementation was wrong" are three completely different problems with three different fixes, and they all look identical from the board.
- First-pass rate. Which is the single number that tells you whether your briefs are getting better or worse.
This matters for human work. It matters much more once agents are doing some of the work, because the agent cannot tell you it was confused, and the rework reason is the only place that confusion becomes visible.
The cheap version
You do not need a new tool. You need rework to be an event with a reason, not a state transition.
Add one required field on send-back, with a short closed list. Ours is roughly:
- brief was ambiguous
- brief was wrong
- requirements changed after the brief
- implementation did not match a clear brief
- out of scope work included
Closed list, not free text. Free text gives you a thousand unique sentences and no aggregate. Five buckets give you a monthly number you can act on.
What we found when we started counting
The honest result: most of our send-backs were not the implementation being wrong. They were the brief being ambiguous in a way that was obvious in hindsight and invisible at writing time. We had been treating a specification problem as an execution problem, which is why none of the things we tried had been helping.
That is not a profound insight. It is just one that was unavailable to us until rework had a reason code.
One design note
If you are building or choosing tooling here, look at whether rework feedback is carried back into the task context that the next run of the work actually reads. A reason code that only lands in a report is an analytics feature. One that reaches whoever, or whatever, picks the task up next is a correctness feature. The Wagglet workflow docs treat rework feedback as part of the task context for exactly this reason.
Disclosure: I work with the team that builds Wagglet. The reason-code idea costs nothing and works in whatever you already have.
Top comments (0)