All Work Time by Ticket Status (ATTS)
All Work Time by Ticket Status (ATTS) measures the total time engineers spend working on or around a task across all workflow stages, not just active development. It helps surface how much effort is spent waiting, coordinating, reviewing, or unblocking tasks throughout the lifecycle of a ticket.
Calculation
Time is attributed based on the ticket’s status history in the issue tracker and the corresponding timestamps. Each time window between status changes is mapped to a category (e.g., “In Progress,” “In Review,” “Blocked,” etc.).
It can be broken down by both ticket and aggregate views to reveal patterns.
The metric is calculated as:
ATTS = sum of time spent in each ticket status per work item or team
Goals
ATTS helps teams quantify non-development effort and delivery overhead. It answers questions like:
- How much time are developers spending in coordination or review instead of coding?
- Are bottlenecks forming in specific workflow states?
- Is delivery time being consumed by idle work, dependencies, or approvals?
By making invisible work visible, this metric supports more balanced planning and deeper insight into workflow health.
Variations
ATTS may also be referred to as Full Ticket Time Breakdown, Lifecycle Time Analysis, or Time in Status. Common breakdowns include:
- By status category, such as development, review, testing, blocked, or backlog
- By ticket type, to compare features vs. bugs or chores
- By team or contributor, to highlight coordination-heavy workloads
- By age bracket, such as new vs. stale tickets
- By project or service, to identify slow-moving areas of the organization
Some teams report percentage of time in non-dev states, which focuses on time spent outside of “In Progress” or “Coding.”
Limitations
ATTS shows where time is spent. Long stretches in “Blocked” or “In Review” don’t reveal the cause or urgency of the delay.
It also depends on timely ticket updates. If engineers delay status changes, the data may misrepresent where time was actually spent.
To interpret this metric effectively, pair it with:
| Complementary Metric | Why It’s Relevant |
|---|---|
| Cycle Time | Tracks overall time from work start to finish—ATTS breaks that time into meaningful stages |
| Review Latency | Highlights how long work sits waiting for feedback in specific states like “In Review” |
| Work in Progress (WIP) | Provides context for multitasking or overloaded queues contributing to state transitions |
Optimization
Improving ATTS requires reducing idle or coordination-heavy time and unblocking critical path work more effectively.
-
Analyze time in each state. Review historical ticket data to identify stages where time accumulates unnecessarily.
-
Improve state hygiene. Ensure developers update ticket statuses consistently and accurately to maintain data integrity.
-
Automate transitions when possible. Trigger state changes based on actions in Git or CI tools to reduce tracking friction.
-
Focus on stuck tickets. Set alerts for tickets that exceed time thresholds in review, testing, or blocked states.
-
Balance planning across stages. Don’t over-optimize for dev speed at the cost of review, QA, or delivery readiness.
ATTS helps answer a critical delivery question: “Where is our time actually going?” When tracked well, it turns ticket history into a clear blueprint for improvement.
