TI-08
Time Tracking Consistency Across Sprint
Time Tracking Integrity
Default severity: medium
EstimationProcessMetricsEffort
What it detects
At the sprint level: total time logged by team across the sprint is inconsistent with team capacity (team_size × days × hours_per_day). Either significantly more or less time was logged than the team could theoretically have worked. Detects both under-logging (invisible work) and over-logging (time logged to wrong sprint period). sprint_capacity_hours = team_size * sprint_duration_days * config.ti.hours_per_day_per_person // default: 7h total_logged_sprint = SUM(worklog.time_spent WHERE started BETWEEN sprint.start AND sprint.end, team=T) logging_ratio = total_logged_sprint / sprint_capacity_hours
Detection formula
IF logging_ratio \< config.ti.min_logging_ratio // default: 0.50 (less than 50% capacity logged) THEN FLAG under_logging IF logging_ratio > config.ti.max_logging_ratio // default: 1.10 (more than 110% capacity logged) THEN FLAG over_logging // time from outside sprint window logged here Report: team_capacity, total_logged, logging_ratio, per-person breakdownExamples in practice
- Per team per sprint
- A team shows at the sprint level: total time logged by team across the sprint is inconsistent with team capacity (team_size × days × hours_per_day) while min logging ratio is set to 0.50 (less than 50% capacity logged).
- Example signal: At the sprint level: total time logged by team across the sprint is inconsistent with team capacity (team_size × days × hours_per_day).
Suggested response
Fix time-tracking states so remaining, spent, and status align with reality.
Coaching playbook
Symptom
At the sprint level: total time logged by team across the sprint is inconsistent with team capacity (team_size × days × hours_per_day). Either significantly more or less time was logged than the team could theoretically have worked. Detects both under-logging (invisible work) and over-logging (time logged to wrong sprint period). sprint_capacity_hours = team_size * sprint_duration_days * config.ti.hours_per_day_per_person // default: 7h total_logged_sprint = SUM(worklog.time_spent WHERE started BETWEEN sprint.start AND sprint.end, team=T) logging_ratio = total_logged_sprint / sprint_capacity_hours
Why it matters
When "Time Tracking Consistency Across Sprint" keeps appearing, the team is signalling a repeatable process gap. Left unexamined, the pattern hides where work really stalls and makes improvement metrics harder to trust.
What you can achieve
Fix time-tracking states so remaining, spent, and status align with reality.
Facilitation questions
- What system change would stop "Time Tracking Consistency Across Sprint" from firing again?
- What do the cited issues have in common — same root cause or same workaround?
- Who owns the two-week experiment and how will we verify on the next import?
Run this rule against your own tracker data with Flow Analyzer.