This changes how a number is computed. Your charts can move without your data moving. Each change is named below with the reason for it.

Some of your charts changed between 1 September and 14 October without your data changing. This page lists each change, the direction it moves the number, and why we made it, so that a figure you have already reported is explainable rather than mysterious.

We do not put a size on most of these. The effect depends on your data, and we only publish figures we have measured and can reproduce. Where a change can move your number a lot, we say so.

1. Organization Health: Quality now measures quality

Changed 22 September 2026.

Before: the Quality dimension was entirely estimation consistency — whether tasks took the effort their estimates predicted. That describes planning, not quality.

Now: Quality scores Defect Leakage Rate (50%), Rework Rate (30%) and Defect Share (20%) against your quality goals. Each scores 100 at or under its goal and goal ÷ actual × 100 above it, so a rate at twice its goal scores 50. A component with no data drops out and the others are re-weighted. Estimation moved into Delivery Speed as its third component.

Direction: your Quality score moves towards whatever your defect and rework rates actually are. For teams with good estimation but a high defect share it falls; for the reverse it rises. Delivery Speed moves too. If you have no quality data at all, Quality shows no data and is left out of the overall score, instead of counting as zero.

2. Delivery Pace has a new definition, and the old card is gone

Changed 5 October 2026.

Two cards were affected:

  • The previous Delivery Pace card (a per-person baseline, with 100 meaning on pace) has been removed.
  • Estimation Predictability — the share of tasks within ±25% of each person's usual effort per point — has been redefined and renamed Delivery Pace. The old version read low every sprint even when the typical task matched history, because a strict per-task band punishes ordinary variation.

Delivery Pace now = hours per story point over your trailing history (90 days by default) ÷ hours per story point in the selected period, minus one. Positive means faster. It is measured on a configurable clock (default: start of work). See story point calibration.

Direction: not comparable with either old card. The scale is different (a percentage around 0, not a share or a score around 100), so do not put a figure from before 5 October next to one from after. In the Health score's Delivery Speed it now scores 100 minus the size of the pace deviation, faster or slower.

3. SP / Active Work Hour removed from Velocity

Changed 5 October 2026.

The SP / Active Work Hour card has been removed. Time per story point now lives on Time Tracking as two median-based cards, Elapsed Time per SP and Lifecycle Time per SP, each on a clock you choose. A median of per-task ratios is harder to skew with one long-running task than a ratio of totals. SP per work hour still counts in the Organization Health score, as half of the Productivity dimension by default.

4. Allocation: Investment is priced by who did the work

Changed 5 October 2026. Visible only with financial access.

Before: Investment per category was story points × one blended cost per story point for the sprint. So the share of Investment was always identical to the share of story points, and the chart told you nothing new.

Now: each person's pay for the sprint is split across the categories their own story points went to. Pay of people who closed nothing that sprint is spread in the same proportions, so each sprint still adds up to its payroll. Unassigned work, and work by people with no salary on file, is not priced and is shown in a note.

Direction: each sprint's Investment now equals that sprint's payroll for the people who closed priced work. Totals can differ from before where the old blended rate did not match payroll, and a sprint in which no salaried person closed story points now shows no Investment. Investment counts closed work only. Category shares move towards wherever your higher-paid people spent their points, which is exactly what the chart is for.

5. Velocity: sprint bars add up to the headline

Changed 22 September and 5 October 2026.

  • Edge sprints are clipped to your date range (5 October). A sprint that started before your range used to be counted in full, so the bars could sum to well over the Total Story Points card beside them. Only the days inside the range count now, and the bars add up to the card. Sprints that end after the range are now shown too; previously they were dropped.
  • Partial sprints at the edges keep their bars but no longer feed the trend line, the averages, the sparklines or the sprint-over-sprint change. Half a sprint compared with a whole one is not a trend.
  • Per-sprint hours per story point (22 September) count only estimated tasks, the same rule as the headline. Unestimated tasks stuck in a status for months used to inflate one sprint's hours. Per-sprint hours go down and story points per hour go up where that happened.
  • KPI sparklines now cover both windows the change badge compares, and the badge says what it compared against.

The Trend chart view was removed, and the Lead and Cycle Time per Sprint charts moved to Time Tracking.

6. Capacity and cost count people, not tracker accounts

Changed 3 September 2026.

Someone with two ClickUp accounts under one name used to be counted twice: twice the capacity in Planning, and their salary twice in cost. They are now counted once, and salaries are never added together. If the two records state different pay, the larger is used.

Direction: available person-days and salary cost go down wherever this applied, and Planning forecasts become less optimistic. People with a single account are unaffected.

Still true, from the Planning release: capacity does not yet exclude weekends, counts everyone as full-time, and only counts people with a salary on file. Since salary became optional on 14 October, an employee saved without one adds no capacity, and Planning does not list who was left out. Check your People list if a forecast looks short-handed.

7. Planning: "planned" means committed

Changed 28–29 September 2026.

Planned story points per category are now the committed figure. Work closed before the interval started, and work added after you committed, are no longer counted as planned. They appear as their own rows in the new ledger. Planned share, and any Reserve sized from it, can read lower than before.

8. Inventory follows your View and your pipeline order

Changed 21–22 September 2026.

  • Inventory now uses the selected View's boundary; it always used the company default before. For some companies the card read 0 because of which task types the Milestones page shows. Those now show their real inventory, so the number goes up from zero.
  • Statuses are ranked by lifecycle stage, not by column order on Status Configuration. QA and review statuses that sat before the boundary in column order now count as inventory (up). Statuses not placed in your pipeline no longer count as inventory (down), and appear separately as outside the pipeline. With no boundary set, Backlog milestones count as upstream (down). Reordering columns no longer changes any metric.

9. Empty is no longer zero

Changed 21 September 2026.

  • A View that explicitly lists no cycle-time statuses now shows no data for cycle time and the figures derived from it, instead of 0. A zero there was a measurement of nothing. Views that never set the list are unaffected.
  • The Workflow Bottleneck Detector no longer has a default exclusion list or a "billable only" switch. It excludes nothing unless you tell it to, so it can now surface statuses it used to hide.

10. AI reports are measured like your dashboards

Changed 21 September 2026.

AI reports now compute under the selected View and team filter. Before, they used no View lens, and a team-filtered report measured the whole company. Hours and counts in a team report can be much lower than in one generated earlier for the same range. The new figure is the one that matches the rest of the product.

11. DORA is computed by a new engine

Changed 5–6 October 2026. Enterprise.

DORA Metrics was rebuilt, and every figure is now computed differently from the previous version. Do not compare a DORA number from before 5 October with one from after. What changed, and the direction it pushes:

  • Medians replace averages for lead time and recovery time. Typically lower, because a few very slow changes no longer drag the figure up. p75 and p90 are shown alongside.
  • Deployment frequency counts releases, not deployments. A commit counts once, at its first production deployment, even if it goes to several regions, and an immediate retry of the same commit counts once. A rollback is a release in its own right. Lower or equal; lower for multi-region rollouts.
  • A failed deploy job is no longer a change failure. Nothing shipped, so it is listed separately and not counted. Change fail rate goes down wherever failed CI jobs used to count.
  • Change failures are attributed by evidence, not proximity. A deployment fails when a revert, rollback, incident or hotfix points back to it on the same production target. A hotfix that can only be attributed by deploy order must follow within seven days, and fixes that go through a release branch blame nothing. Being followed by a fix-up deployment is no longer enough. This removes false blames, but also finds failures the old rules missed, so change fail rate can move either way.
  • Release trains. A merge from a long-lived release branch is no longer counted as one large change; the merge requests inside it are. Changes per deployment and batch size go down. Lead time usually goes up, because it now includes the time work waited on the release branch, shown as its own segment.
  • Rework rate (new) counts deployments that shipped only remediation: rollbacks, reverts, hotfixes, work tagged unplanned or incident, and fix: changes tied to an urgent bug or incident or to a ticket created within two days. A planned release that happens to carry a fix is not rework.
  • No Elite/High/Medium/Low tiers on the DORA page. Bands follow the DORA 2025 survey.
  • Too few to score. Too few deployments or changes (fewer than five), or fewer than three failures for recovery time, reads Too few to score rather than a number.

If a number you reported has moved

Contact support with the figure, the date range and the View you were using, and we will reconstruct what it was before and after the change, for your data.

Dates on this page are the dates a change was committed; production followed within days. This list covers the changes we identified. If you find a figure it does not explain, tell us, and we will investigate it and add it here.

← All releases · Subscribe (Atom)