Developers accept time tracking when it costs them almost nothing, when it is tied to the work items they already use, and when the data is used for planning and billing instead of ranking people. Track time against issues automatically, keep idle thresholds generous, and never compare individuals on hours or activity.
Key takeaways
- The objection is rarely to the data. It is to interruption and to how the data gets used.
- Tie time to issues, not to a separate timesheet.
- Thinking, reading and waiting for builds are work. Set the tool up to respect that.
- Use the numbers for estimates, budgets and capacity. Keep them out of performance rankings.
Why do developers resist time tracking?
It interrupts
Stopping to start a timer or fill in a sheet breaks concentration, and concentration is the job.
It misreads the work
An hour reading code or thinking through a design shows no keyboard activity.
It doubles the admin
Time goes into Jira and then into a timesheet as well.
It feels like suspicion
Activity scores and screenshots read as "we do not believe you".
The first point has research behind it. Experiments described by the American Psychological Association found that people lose time whenever they switch tasks, and lose more as tasks get more complex. One of the researchers has said these switching costs can take up as much as 40 percent of someone's productive time. A tracking method that adds switches works against itself. See context switching at work.
What is developer time data good for?
| Use | The question it answers |
|---|---|
| Estimates | How long did work like this take last time? |
| Client billing | How many hours went into this client's issues? |
| Budgets | How much of the project's budget is used? |
| Capacity | How much of the team's week is left after meetings and support? |
| Maintenance load | How much time goes to bugs and incidents, against new work? |
None of these needs a judgment about any one person. That is the line to hold.
What should you never do with it?
Do
- Compare estimates with actuals to improve estimates
- Report hours by project, epic and type of work
- Share the reports with the team
- Let people correct their own entries
Do not
- Rank developers by hours or activity
- Treat idle time as time not worked
- Ask people to justify individual gaps
- Bring time totals into performance reviews
Idle time needs special care in engineering. Reading, reviewing, waiting for a build and thinking all register as no input. Set the idle threshold longer than you would for other roles and read it as a pattern. See idle time at work.
Hours or story points?
Both, for different jobs. Atlassian's agile guidance describes story points as a relative measure of the overall effort needed to finish a backlog item, taking in complexity, amount of work and risk. Points are for planning a sprint. Hours are for billing, budgets and learning how long things really take.
You do not need to estimate in hours to record hours. The comparison is in story points vs hours.
Which method suits an engineering team?
| Method | Effort for the developer | Accuracy | Main drawback |
|---|---|---|---|
| Manual worklogs in Jira | High. Every issue, every day | Low. Filled in from memory | Forgotten and rounded |
| Start and stop timers | Medium. A click per switch | Medium | Timers left running |
| Automatic tracking tied to issues | Low. Pick the issue when it changes | High | Needs clear rules about what is recorded |
How Jira's own time tracking works is covered in how to log work in Jira.
How do you set it up?
Say what the data is for
Estimates, billing and capacity. Put in writing that it will not be used to rank individuals.
Track against issues
Every piece of time belongs to an issue. No second timesheet.
Decide on screenshots with the team
If no client contract needs them, say so and explain what is recorded instead.
Set a generous idle threshold
Ten minutes or more for roles with heavy reading and review.
Cover time away from the keyboard
Design sessions, calls and whiteboard work go in as manual entries.
Review at the retrospective
Look at estimate against actual by type of work, as a team.
A general rollout plan is in how to introduce time tracking.
How does BirdsEye work for developers?
- Jira issue picker. Developers choose a real Jira issue as their task in the desktop agent, without opening Jira.
- Worklogs that stay correct. BirdsEye creates, updates and removes Jira worklogs so they match tracked time, including after an entry is edited or deleted.
- Two machines, one total. Overlapping time on a laptop and a desktop is counted once, before it reaches Jira.
- Offline tracking. The agent keeps recording without a connection and syncs later.
- Rules that fit the work. Starter rules classify common development tools from day one, and you can add rules by application, website domain or window title.
- Visible limits. Tracking runs only inside working hours, and each developer can see the rules in the agent.
Jira is available on the Team and Business plans. BirdsEye's desktop agent is Windows first. See Jira time tracking.
Frequently asked questions
Should developers track their time?
When the business bills by the hour, works to budgets or needs better estimates, yes. The method should add as little interruption as possible and the data should be used for planning.
Do developers need screenshots?
Usually not. Screenshots exist to prove work to a client. If no contract asks for them, tell the team so. If one does, blur them and keep them briefly.
How do you track time in Jira without manual worklogs?
Use a tracker that records time against the Jira issue a developer has selected and writes the worklog for them.
Is time tracking compatible with agile?
Yes. Story points plan the sprint and hours record what the work cost. They answer different questions and can run side by side.