At our 0-1 startup, speed was everything. We moved fast, broke things (intentionally), and often forgot one tiny detail—tagging PRs and commits with Jira IDs. And, as expected, it came back to haunt us.
One day, one of our developers raised a PR to push a beta feature to production by cherry-picking changes from staging. Since there were no Jira IDs to reference, he had to rely purely on memory to gather the necessary commits—an effort that took considerable time. To make matters worse, the PR itself also lacked a Jira ID, leaving the reviewer to merge it based on the limited context he had. Everything seemed fine—until we realized the feature behaved differently in staging and production. Everything seemed fine—until we noticed discrepancies between the staging and production beta environments.
Cue the panic. A few commits had mysteriously vanished. Now, without Jira tags to trace them, we embarked on a grand treasure hunt: first, digging through Jira to find the right ticket (5+ minutes), then manually tracking down the missing commits (30+ minutes). After what felt like an eternity, we finally cherry-picked the missing changes to production.
Had we just tagged the PR and commits properly:
1. The reviewer would have had the full context, avoiding this detective saga.
2. The missing commits could have been found in seconds instead of an embarrassing 30 minute wild goose chase.
So, lesson learned: skipping small processes for speed can often slow you down in the long run. And sometimes, all it takes is a missing Jira tag to turn you into an unintentional bug bounty hunter.
Do you know what unaccounted work is?
These missing Jira tags are often referred to as Unaccounted work. It’s any development effort—whether in the form of pull requests (PRs) or commits—that is not linked to an official issue or ticket within a project management tool such as Jira. This means the work exists in the codebase but lacks a traceable connection to planned tasks, story points, or organizational priorities.
In fast-paced development environments, unaccounted work often surfaces when:
1. Developers push changes without associating them with a tracked issue.
2. Hotfixes, quick refactors, or ad-hoc improvements bypass the standard workflow.
3. Teams lack strict enforcement of linking code contributions to formalized tasks.
While unaccounted work might sometimes improve code quality or resolve urgent issues, it poses challenges in terms of visibility, accountability, and sprint tracking. Without a direct mapping between effort and planning, teams struggle to measure actual work done versus planned work—leading to discrepancies in velocity, unbalanced workloads, and potential gaps in reporting.
The Hidden Challenges of Unaccounted work (for managers & leads)
In fast-paced engineering orgs like ours, unaccounted work often creeps in when (changing requirements and priorities, loss of deadlines etc.)
This might look like a small slip for now, but in the long run it can cause -
1. Lack of Visibility and Accountability: Without a direct link to a Jira ticket or any other tracking tool, managers struggle to trace where development efforts are going. Teams may also be working on unplanned or unauthorized changes, making it difficult to justify resource allocation.
2.Disruptions in Sprint Planning and Tracking: Work that isn't accounted for distorts sprint velocity, making it hard to measure actual progress. Leads cannot accurately assess team performance, causing potential overestimation or underestimation in future sprints.
3. Difficulty in Justifying Effort and Deliverables: When reporting to stakeholders, managers lack clarity on where engineering effort is being spent. It becomes challenging to explain delays, unexpected scope creep, or why planned work isn’t fully delivered.
4. Challenges in Post-Mortem Analysis: In case of production incidents, tracking down the root cause is harder when commits lack proper documentation or issue references. Teams may struggle to identify who worked on what, delaying resolutions and accountability.
5. Production Bugs: QA usually relies on Jira tasks and not having an issue bypasses the standard QA process inviting production bugs. Devs are responsible to deliver the full story for QA to efficiently test.
But how do we measure unaccounted work?
For managers and leads, tracking unaccounted work manually is a nightmare. Without a dedicated tool, teams are forced to manually cross-check PRs and commits against Jira or other project tracking tools—a frustrating and time-consuming process.
Tools like Hivel automatically calculate unaccounted work at both the PR level and commit level, giving team leads and managers instant visibility into untracked efforts. No more chasing down developers or digging through endless commit logs—Hivel presents unaccounted work insights with just a few clicks.
Unaccounted work at Commit Level
Unaccounted work at PR Level
With Hivel, engineering leaders can ensure accountability, improve sprint planning, and streamline code reviews—all while keeping their teams focused on work that drives business impact.
How do we get devs to maintain Git-Jira hygiene?
Now that we understand the value of tracking unaccounted work—and have tools like Hivel to measure it—there’s still one missing piece: ensuring Jira IDs are consistently added to PR titles and commit messages.
Let’s be honest—developers (myself included) aren’t always the biggest fans of following strict processes. Manually adding Jira IDs to every commit feels like an unnecessary hassle. But as the saying goes:
"We are what we repeatedly do. Excellence, then, is not an act, but a habit." – Aristotle
Initially, I felt the friction of adding Jira IDs to every commit message. So, I started looking for ways to automate it—and that’s when I stumbled upon a hidden Git feature: Git Hooks
The Magic of Git Hooks: Automating Jira ID in Commit Messages
With a simple prepare-commit hook, we can extract the Jira ID from the branch name and automatically prepend it to every commit message—saving developers from manual effort.
How to do Git Hooks implementation:
1. Your branch name contains the Jira ID (e.g., feat/MAV-123/2024-wrapped).
2. When you commit a change with a message like: "Adjusted the padding for a better UI look"
3. The Git hook detects the Jira ID in the branch and automatically updates your commit message to: "[MAV-123] Adjusted the padding for a better UI look"
This way, developers don’t have to manually copy and paste Jira IDs in every commit. If a commit message already contains a Jira ID, the script simply skips adding another one. By setting up this lightweight automation, we reduce friction, ensure every commit is properly tracked, and make life easier for both developers and reviewers.
Because let’s face it—if a process isn’t automated, it’s likely to be forgotten.
Enforcing Jira ID in PR Titles: Ensuring Every PR is Ready for Merging
While we’ve automated Jira ID tagging in commit messages using Git Hooks, the next crucial step is ensuring every PR title includes a Jira ID before it’s ready to merge. A properly structured PR title improves traceability, streamlines reviews, and guarantees that every code change is linked to a planned task.
Since a PR is created just once, adding a Jira ID is a small effort with a big impact. However, developers (myself included) often overlook this step. That’s why we can leverage PR title validation rules to enforce this automatically.
Automating PR title validation Using GitHub, GitLab, or Bitbucket rules
Most version control platforms (GitHub, GitLab, Bitbucket) allow us to enforce naming rules for PR titles using regular expressions (regex). By implementing a simple validation rule, we can reject PRs that don’t follow the required pattern—forcing developers to include a Jira ID before merging.
How It works:
1. Define a regex pattern to enforce Jira IDs in PR titles:
• Example pattern: ^.*(MAV-\d+).*$
• This ensures PRs have a Jira ID in the format MAV-123 anywhere in the title.
2. Enforce this rule in GitHub, GitLab, or Bitbucket:
• GitHub: Use GitHub Actions or repository branch protection rules.
• GitLab: Use merge request approval rules with regex validation.
• Bitbucket: Use repository hooks to enforce PR naming conventions.
Example PR Titles:
With PR title validation in place, a PR cannot be merged until it meets the required format. This simple automation ensures compliance, improves tracking, and eliminates unaccounted work—without adding unnecessary friction to the development process.
The Impact of eliminating unaccounted work
Reducing unaccounted work isn’t just about process enforcement—it’s about making development smoother, faster, and more transparent for everyone. With simple automation like commit and PR validation, teams can eliminate guesswork, improve collaboration, and prevent costly mistakes.
A little discipline today means fewer production issues, better sprint tracking, and faster reviews tomorrow—allowing developers to focus on what they do best: building great software.
FAQs
1. What is unaccounted work in software development?
Unaccounted work refers to development efforts—such as pull requests (PRs) or commits—that are not linked to an official issue or ticket in a project management tool like Jira. This work exists in the codebase but lacks traceability, making it difficult to track against planned tasks and organizational priorities.
2. Why is unaccounted work a problem for engineering teams?
Unaccounted work disrupts sprint planning, affects velocity calculations, and reduces accountability. When work is not linked to Jira tickets, managers struggle to justify resource allocation, track progress, and report deliverables accurately. It can also cause delays in debugging and post-mortem analysis.
3. How can organizations measure unaccounted work?
Tracking unaccounted work manually is time-consuming, as it requires cross-checking PRs and commits against project tracking tools. Platforms like Hivel automate this process by detecting untracked efforts at both the PR and commit levels, giving managers instant visibility into unaccounted work.
4. How can developers prevent unaccounted work?
Developers can prevent unaccounted work by consistently tagging PRs and commits with Jira IDs. Automating this process with Git Hooks ensures that Jira IDs are automatically added to commit messages based on branch names. PR title validation in GitHub, GitLab, or Bitbucket can further enforce tracking compliance.
5. What are the benefits of eliminating unaccounted work?
Eliminating unaccounted work improves sprint accuracy, enhances collaboration, and prevents costly errors in production. By enforcing lightweight automation, teams can ensure better traceability, faster code reviews, and smoother software delivery—without adding unnecessary friction to development workflows.
Also, read - Beyond the Tickets: Recognizing Ghost Efforts of Developers
.jpg)
