Reworked Tasks counts tasks that moved backward in the workflow — for example, from "In Review" back to "In Progress." It's a direct signal of quality issues, requirements churn, or weak review processes.
Where it appears
Reworked Tasks is a per-member column inside the Team Overview tab of the Performance Delivery dashboard. There is no standalone Reworked Tasks card on Workflow Performance.
What it measures
From the live tooltip: "Tasks that moved backward in the workflow, indicating revisions or corrections were needed. Signals quality or requirement issues. High rework rates may indicate lack of clarity or weak review processes."
"Backward" is determined by the status order you've configured for each integration's statuses inside Administration → Productivity Tools. Each step that moves a task to a status with a lower order than its previous status counts as a rework event. A task that moves backward more than once contributes more than once.
The Team Overview view counts only tasks whose latest status sits in a "done" state and whose completion date falls within the selected period. Rework events on tasks that haven't completed yet are not counted in this view.
Different number in Bottleneck Insights
A separate per-person Reworked Tasks number appears in the Bottleneck Insights modal. That view uses a coarser definition (status category rather than ordered status) and counts each task at most once. The two numbers can disagree for the same person — that's expected. Use Team Overview for ordered-workflow rework signal, and Bottleneck Insights for "did this person experience rework at all?"
How to interpret it
Steady, low number — healthy. Some rework is normal in any creative workflow.
Climbing trend — signals quality erosion, unclear requirements, or test-coverage gaps.
Concentrated on one issue type (for example, all bug fixes) — that segment of work specifically needs attention.
What to do about it
Strengthen definition-of-ready so requirements are clearer before work starts.
Tighten definition-of-done with explicit testing and acceptance criteria.
Investigate whether reviewers can catch issues earlier — long-cycle reviews tend to surface rework late.
If the trend coincides with a status-mapping change, double-check the new mapping reflects forward progress correctly.
Related metrics
Cycle Time
Change Failure Rate
Sprint Efficiency
