{
  "id": 7303657,
  "title": "Rework is an outcome your tracker probably cannot express",
  "url": "https://urgent.news/2026/09/14/rework-is-an-outcome-your-tracker-probably-cannot-express",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-14T11:20:46.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/sam_novak_574b07811e18495/rework-is-an-outcome-your-tracker-probably-cannot-express-3lcc"
  },
  "original_language": "en",
  "account": "Your tracker typically categorizes work into three states: not started, in progress, and finished. However, it often fails to accurately capture certain types of rework. When work is returned because it solved the wrong problem, most trackers collapse this back into the \"in progress\" state, discarding valuable information. This issue arises because a rejected delivery is treated as a state change rather than an event. As a result, you lose crucial data: whether the delivery happened at all, the cycle-time, and why it was returned. The reasons for return can vary - requirements might have changed, the brief was ambiguous, or the implementation was incorrect. Each of these scenarios requires different fixes, but they all appear identical on the board. One key metric that suffers is the first-pass rate, which indicates whether your briefs are improving or declining over time. This matters greatly, especially when some of the work is being done by agents who cannot communicate their confusion through the tracker. To address this, you could treat rework as an event with a reason rather than a state transition. Adding a required field on the rework submission, with a short list of options, could help. For instance, reasons could include: the brief was ambiguous, the brief was wrong, requirements changed after the brief, or the implementation did not match a clear brief. Out of scope work and work that does not match a clear brief could also be options. However, it's crucial to use a closed list, not free text, as free text provides many unique sentences but no aggregate data. Five predefined buckets, on the other hand, yield a monthly number that can be acted upon. When the team at Wagglet started counting rework reasons, they discovered that most of their reworks were not due to implementation errors, but rather ambiguous briefs. They had been treating specification problems as execution problems, which is why their previous solutions hadn't worked. This is not a profound insight, but one that became available only when they introduced a reason code. If you're building or choosing tooling, consider whether rework feedback is being carried back into the task context that the next run of the work will read. A reason code that only ends up in a report is an analytics feature. One that reaches the person or entity handling the task next is a correctness feature. The Wagglet workflow treats rework feedback as part of the task context for this reason. The reason-code idea costs nothing and can be implemented in any existing system.",
  "summary": "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…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}