Work Metrics

Cycle time — task and project

Cycle time is the time between a task entering 'in progress' and reaching 'done.' It is the most basic throughput metric and the most useful first signal.

Kavanah computes cycle time at task and project granularity. Task-level cycle time, distributed by skill tag, tells you where the team is fast and where it is slow. Project-level cycle time, computed as the duration between project kickoff and project close, tells you whether the team's project shape is sustainable.

The healthy signal is stable median cycle time with a thin right tail. Stable means the team's process is predictable; thin right tail means the long-running tasks are rare. A long right tail — many tasks that take 5x median to ship — usually indicates either poor breakdown (the task should have been multiple tasks) or unclear acceptance (the doer doesn't know when to stop).

The action when cycle time drifts: look at the right tail. The fix is almost never 'work faster'; it is 'break smaller' or 'sharpen acceptance.'

Estimate accuracy — calibration, not performance

Estimate accuracy is the rolling MAPE between estimated and actual time on completed tasks. It is the calibration signal for the estimator.

We suggest treating a rolling MAPE under about 30% as 'calibrated' for a maturing workspace, trending down as history accumulates — a figure consistent with long-standing findings that software effort estimates overrun by roughly 30% on average and that this hasn't improved much over decades (Jørgensen 2014). Treat it as a reference point to beat against your own history, not a guarantee, and remember MAPE is not the same quantity as mean overrun. The unhealthy signal is rising MAPE — the system was calibrated, and something changed (new project type, new contributor, shift in description style) and the estimator hasn't caught up.

The critical discipline is to read estimate accuracy as a calibration metric, not a performance metric. A team where one member's estimates consistently underrun is not a team with one bad estimator; it is a team that has discovered something about that member's domain that the model hasn't yet — usually that their skill is genuinely higher than declared. The action is to retag, not to retrain the member.

Kavanah publishes estimate accuracy at workspace and project levels, with per-skill breakdowns. It is a workspace-health metric, not a per-member ranking.

KVN completeness — overall and by stakes

Two metrics share this name and they should be read together.

Overall KVN completeness is the fraction of created tasks with all three task-level KVN axes populated. There is no external benchmark for this — KVN is specific to how your team works. We suggest starting from the expectation that only a minority of routine tasks (say, a fifth to two-fifths) will carry full KVN, and calibrating to your own mix; the figure is a Kavanah starting recommendation, not a measured norm.

KVN completeness on high-stakes tasks (the agent flags these based on cost, complexity, cross-functional touchpoints) should almost always be high — aim for 80%+. If it is lower, the discipline is failing exactly where it matters most.

Reading these together protects against both failure modes: KVN theater (high overall completeness, low information value) and KVN avoidance (low completeness on high-stakes work).

The action when high-stakes completeness drops: the team has stopped writing KVN where it matters. Surface this in the next retro; usually the cause is that the team's recent run of work has been familiar enough that KVN seemed unnecessary — and a 'we don't need it' attitude on familiar work carries forward into 'we don't need it' on the next high-stakes task.

Rework rate — when work has to be redone vs. iterated on

Rework is the situation where a task that was previously closed has to be reopened and redone — not iterated upon, but redone. Iteration is healthy and expected. Rework is a quality signal.

The rework rate is the fraction of recently-closed tasks that were reopened within two weeks. We suggest treating a reopen rate in the mid-single-digits as normal background surprise, and a sustained rate above roughly 15% as worth investigating — but establish your own baseline first, since what counts as 'high' depends on your work type and how strictly you distinguish rework from iteration. These bands are Kavanah guidance, not an industry standard.

The critical distinction is rework vs. iteration. Iteration is when the work shipped, was reviewed by the next-step stakeholder, and the feedback produced a follow-up task. The original task is closed and the follow-up is a new task; this is healthy. Rework is when the task itself comes back open because what shipped did not actually meet the stated acceptance — usually because the acceptance was unclear or the V was vague.

Kavanah's task lifecycle records the reopen events. The Reports surface distinguishes reopens-with-edit (someone reopened the existing task) from new-task follow-ups. Track the former; the latter is just iteration.

Dismissal rate — the back side of capture

Dismissal rate is the fraction of candidate tasks that get dismissed at triage. It is the counterweight to capture coverage.

We recommend starting from a rough 15–35% band and reading anything outside it as a prompt to inspect the dismissal-reason distribution — the healthy range is really a property of your intake sources and triage discipline, so calibrate it. As a starting guideline: below 15% often means triage is too permissive — the team is accepting work that should not have been work; above 35% often means the agent is over-proposing (probably surfacing recurring operations as candidates), or the team is too restrictive at triage.

The dismissal-reason distribution (Module 2.4) is the diagnostic. If a single reason dominates — usually a Negation — that is healthy and the boundary is doing its job. If 'no checkable outcome' dominates, the team is rephrasing topics as candidates and the workspace V probably needs sharpening.