I'm currently working with an organization that is using the Jira Tempo Timesheets plugin to track developer time, but the way that Jira stories and tasks are being used fails to capture overhead accurately without a lot of manual tweaking.

For example, if the team has a user story with two tasks:

  1. Two people might collaborate on one of the tasks. If both people log work on the task, it doubles the time Jira thinks the task took.
  2. One person might spend two 30-minute blocks working on a task, but two hours blocked.
    • The unblocking process (e.g. making calls, chasing resources, holding meetings) could theoretically be allocated towards the blocked task, but then the dashboard (especially the Agile view) looks really skewed.
    • Not allocating that time towards the blocked task hides details about lead time, and makes the level of effort look smaller than it was.
  3. Sometimes an activity could be charged against multiple tasks/subtasks, but entering it in both causes the roll-up values to be ridiculously large and ultimately misleading.
  4. On the other hand, splitting the time between separate activities that just happen to share a common dependency makes it look like task performers have spent half the time they really did to complete something.

In short, I'm not sure how to reconcile Jira as a epic/story or task/subtask tool (especially for collaborative user stories) with its organizational role as the "source of truth" for individual time sheets.

While I personally think Jira is not the right tool for a truly Agile process, especially for projects that follow Scrum or XP, that's not my decision to make. I just need a better process for tracking work, billable hours, and cycle time within Jira.

What process changes can I make so that the time allocations to stories/tasks are meaningful at the executive level without making it look like every calendar week consumes 300 man hours of each person's time? And how do I make Jira account for process overhead, so that time allocated to specific activities (which is often smaller than the actual elapsed time to reach the Definition of Done) doesn't ignore the real cost of completing the stories?

1 Answer 1


My approach would be:

  1. Let both developers log work on the issue they worked on together. It is the simple truth that if 2 developers worked for an hour on to then 2 hours are spent. The logged work is not time but effort.
  2. For everything the dev do that is not directly related to stories I would recommend "pooling tasks", e.g. a task "Meetings April" where every participant of a meetings logs work in this issue. If you have these on a monthly base you will get a nice report how much time was spent on "everything else". Something that is a great opener in a retrospective when you show the team how much time they actually spent on things that are not story-related.
  3. I would recommend to log work only on stories not on tasks. If something aims at several stories I would split work logged between them.
  4. This is only a problem if you want to do a deep-dive into the work done for a specific story. For metrics like cycle time and lead time it should not make any difference.

My advice for a process change would be to question time tracking altogether. Time tracking is a method from the command & control way of project management. I would recommend to use Scrum where you have sprints as fixed time-boxes. With simple steps you get a pretty good understanding of the work capacity a team has.

Management should focus on strategy and trust the teams that they will continuously improve their processes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.