Monday morning. Developer opens Jira, drags their ticket to "In Progress." Feels productive.
But no code is written until Wednesday. No PR opens until Friday. The ticket was "in progress" for a week, but actual work happened in two days.
This gap—between ticket status and actual engineering activity—is one of the most common sources of misleading metrics. If you're measuring velocity based on Jira transitions alone, you're seeing a polished fiction, not reality.
The Status Illusion
Jira statuses are intention statements, not activity records:
- "In Progress" = "I plan to work on this"
- "In Review" = "I think this is ready for review"
- "Done" = "I believe this is complete"
These are useful for workflow visualization. They're terrible for measuring actual work time.
Consider what "In Progress" might actually mean:
- The developer grabbed the ticket but hasn't started
- They did 30 minutes of research, then got pulled into something else
- They're blocked waiting for a question to be answered
- They're actively coding right now
The Jira status is the same for all of these. The activity is completely different.
Git Tells the Truth
Unlike Jira, Git activity is automatic and precise:
- First commit timestamp = work actually started
- Commit frequency = active development pattern
- PR opened = code ready for review
- PR merged = work complete
By comparing Jira timestamps to Git timestamps, you can see the gap between intention and reality.
The Velocinator Correlation View
We overlay Jira and GitHub data to reveal the true story:
Timeline View
For each ticket, see:
- Jira status transitions (colored blocks)
- GitHub activity (commits, PR events) overlaid
Healthy pattern:
- Ticket moves to "In Progress"
- First commit appears within hours
- Steady commit activity
- PR opens, review happens, merge
- Ticket moves to "Done" after merge
Unhealthy pattern:
- Ticket moves to "In Progress"
- Three days of silence
- Burst of activity
- PR opens
- Two more days of silence
- Ticket moves to "Done"
Same lead time. Very different actual work pattern.
Active Work Time vs. Lead Time
We calculate two metrics:
Lead Time: Total calendar time from "In Progress" to "Done"
Active Work Time: Sum of time periods with Git activity
Flow Efficiency: Active Work Time / Lead Time × 100
A ticket with 5-day lead time but only 8 hours of active work has 20% flow efficiency. The other 80% was waiting or overhead.
The Gap Report
See which tickets have the largest gap between status and activity:
- Moved to "In Progress" but no commits for >48 hours
- Marked "In Review" but PR not yet created
- Marked "Done" but PR still open
These gaps often indicate process problems or miscommunication.
Why Gaps Happen
Planning vs. Execution
Developers often move tickets to "In Progress" when they intend to start, not when they actually do. This is especially common:
- Monday morning (planning the week)
- Sprint start (claiming work)
- Before going to a meeting (optimistic scheduling)
Multi-Tasking Reality
The developer may be "working on" three things simultaneously. Each is "In Progress," but only one gets active attention at a time. The others sit.
Blocking Without Status Update
Work is blocked—waiting for an answer, dependency, or decision—but nobody updates the Jira status. It stays "In Progress" while no progress happens.
Premature Completion
Ticket marked "Done" because the PR is ready, but review takes 3 more days. Or marked "Done" because it's deployed to staging, but production deploy happens next week.
Using the Gap Data
For Estimation
If tickets consistently show 5-day lead time but 1 day of active work, you have a 5:1 overhead ratio. Future estimates should account for this.
Instead of "this is 2 days of work, so it'll be done in 2 days," think "this is 2 days of work, so with our typical 5:1 ratio, plan for 10 days lead time."
For Process Improvement
Large gaps reveal improvement opportunities:
- Long gap before first commit → Requirements clarity, blocking issues
- Long gaps between commits → Context switching, interruptions
- Long gap in review → Review bottleneck
- Long gap before done → Deployment process
Attack the biggest gaps first.
For Standups
Instead of asking "what are you working on?", ask "let's look at the activity view—I see PROJ-123 has been in progress for 3 days with no commits. What's the blocker?"
Data makes the conversation specific.
For Team Capacity Planning
If your team shows 25% flow efficiency (75% waiting), adding more developers won't help much. You'd be adding more people to wait longer.
Instead, fix the waiting problem first. Then add capacity.
Implementing Reality-Based Tracking
Automate the Link
Ensure commits and PRs link to Jira tickets:
- Use ticket keys in branch names:
feature/PROJ-123-add-login - Use ticket keys in commit messages:
PROJ-123: Add login form - GitHub/Jira integration auto-links these
Without the link, correlation is impossible.
Train the Team
Explain why accurate status matters:
- Statuses should reflect reality, not aspiration
- "Blocked" is a valid status—use it
- Moving to "Done" before actual completion obscures real cycle time
Review Weekly
Look at the gap report in team meetings:
- Which tickets had the largest intention/reality gaps?
- What caused the gaps?
- Can we prevent similar gaps?
Set Expectations
Some gap is inevitable. But set targets:
- First commit within 24 hours of "In Progress"
- PR within 4 hours of "In Review"
- Ticket closed within 24 hours of PR merge
Track against these expectations.
The Truth Shall Set You Free
Your Jira board isn't lying maliciously. It's just showing a simplified view of a complex reality.
By correlating Jira with GitHub, you see the full picture: not just when work was supposed to happen, but when it actually did. That truth—sometimes uncomfortable—is the foundation for real improvement.
Because you can't optimize what you're not actually measuring.
