Speed is easy to show and easy to fake. Ship faster, and the cost turns up a month later as bugs, reopened tickets and work that bounced back from QA. The new Quality page (under Analytics) puts that cost next to your delivery numbers so it cannot hide.
Three numbers, each hard to game
Defect Leakage Rate — the share of delivered tickets that were defects, with each defect weighted by its priority (Urgent 3, High 2, Normal 1, Low 0.5 by default; no priority counts as Low) and every other ticket counting once. It counts tickets rather than story points, so an unestimated hotfix still counts. By default the tags bug, incident, reqFix and devFix mark a defect.
Rework Rate — of the tasks closed in the window that entered QA, the share that came back afterwards: QA to development, through blocked back to development, or reopened after done. It is read from status history rather than from tags, so filing fewer bug tickets cannot lower it.
Defect Share — story points spent on defect-tagged work as a share of all story points delivered. This is the capacity fixing work consumed. Unsized defects are not treated as free: if defects closed but none carried an estimate, the card says it has no data rather than showing 0%.
All three are lower-is-better and follow your team filter. Rework Rate also follows your selected View; Defect Leakage Rate and Defect Share use the company's completed statuses, whichever View is selected. When nothing qualifies, a card shows no data, never a reassuring zero.
Every figure opens onto its tasks
Click a card to see the tasks behind it. For Rework Rate, each task has a Why it counts column with the path it took back — for example straight back from QA, back again before re-entering QA, reopened after done, or via a blocked status — plus breakdowns of what sent work back, how many times, and where it went. That turns "our rework is 18%" into a conversation about specific handoffs.
Switch between Cards (this window against the one before) and Chart (sprint by sprint). Allocation's chart also gained a Rework series beside QA and DLR.
Set the goals and definitions once
- Goals — the ceiling you consider acceptable for each metric (defaults: DLR 10%, Rework 15%, Defect Share 20%). These are the same targets the Organization Health score uses.
- Definitions — which tags count as delivery loss and as defects, and the priority weights.
- Rework is defined by your View's lens: the new Rework — gate statuses and Rework — return statuses pickers in Lens settings, with a live preview of the rework path. If you never set them, your pipeline's QA and Development stages are used; a View that deliberately lists none reports no rework rate.
Goals and definitions are company-wide and Admin-only.
The health score now measures quality
The Quality dimension of the Organization Health score used to be estimation consistency, which describes planning, not quality. It now scores these three metrics against your goals (DLR 50%, Rework 30%, Defect Share 20%), and estimation moved to Delivery Speed, where it belongs. Your score will move, and that is described in the metric-change note.
Do this first: check that your defect tags match how your teams actually label bugs, set the rework statuses on your main View, then set goals you would defend in a review.
The Quality page is on every plan. The Organization Health score is on Business and Enterprise.