Best time tracking app

[mborinstein]

I am looking for a third-party app that will help our leadership understand how much time engineers are spending on tickets each month. My two MUST HAVES are:

1. Grouping by epic: For each epic, how much time did each engineer spend on tickets within that epic

2. NON-CUMULATIVE TIME: If an engineer worked on a ticket from November 1 - 3, and they picked up another ticket from November 2-3, I do not want the total time spent across both tickets (3 days + 2 days). I want to know that in November, they spent 3 business days working on tickets. 

I ideally also want an app that will let me customize what "time spent" working on a ticket means (i.e. being able to only look at the time from when a ticket moved to In Progress to when it moved to Done). 

I have found some apps that give me pieces of this (Timepiece, Time in Status) but the non-cumulative time part seems hard to find. Any recommendations? 

[Robert]

That’s a really thoughtful and well-defined question — and honestly, one that a lot of engineering teams struggle with once they scale. 👏

You’re absolutely right — most marketplace apps like Timepiece, Time in Status, or Tempo Timesheets tend to give you cumulative time logs, which are fine for reporting effort but not great for understanding actual working days spent within a time window.

From experience, what you’re describing — “non-cumulative time per engineer within epics” — usually requires something that can analyze state transitions + timestamps rather than raw time logs.

A few ideas worth exploring:

Custom Jira automation + reporting via eazyBI or Custom Charts: You can pull issue histories and calculate distinct “In Progress” dates per user. It’s a bit of setup, but it gives you exactly what you’re after — calendar days of activity rather than total logged time.

Tempo Timesheets (advanced filtering): It’s not perfect for non-cumulative time out of the box, but if you combine Tempo with Automation for Jira (to track state changes as custom fields), you can approximate it.

WorklogPRO might be another one to test — it supports aggregating worklogs by user and epic and can filter based on specific status durations.

If you want to go deeper, you can also export your issue histories via Jira REST API and process them in a small Python or Google Sheets script — compute “distinct active days per user per epic.” That’s often the cleanest approach if you don’t want to overpay for heavy marketplace apps.

Totally get what you’re going for though — leadership doesn’t need inflated “effort hours,” they need real working footprint data. Love how clearly you’ve defined that difference. 👌

[elita_kalane]

Hi,

This is Elita from the eazyBI Team.
What you're describing - tracking actual working days per engineer within epics rather than cumulative logged hours - can be achieved with eazyBI. 

We have standard/built-in calculations, "Days in transition status" and "Workdays in transition status," that are designed to capture the Days the tickets spent in specific statuses. Another option is to import Issue Cycles that allow you to configure the Issue Cycle based on the Statuses you want to consider (excluding statuses such as "to do" or "Waiting for approval", etc.). Here are some example reports or our Demo Dashboard - https://eazybi.com/accounts/1000/dashboards/7513-age-lead-and-cycle-time 

You can group the results based on your requirements, including the Epic level. 

With custom calculations, you can also determine the days spent in a status without cumulatively summing the days.

I created a test report on my account and defined a calculated measure that looks at the selected time period and counts only the weekdays (Monday-Friday) where at least one issue was "In Progress". If you select January 2025, this measure will tell you "on how many weekdays in January did assignee have at least one issue being worked on (was in Progress category)?"

So if your team member worked on issues for 15 out of 22 possible weekdays in January, the result would be 15.

Here is an example with results for the previous month:

If you're curious what the expression behind the measure looks like, here it is:

NonZero(
Count(
Filter(
-- Get all days in the selected time period
DescendantsSet(
[Time].CurrentHierarchyMember,
[Time].[Day]
),
-- Filter to business days only (exclude weekends)
NOT [Time].CurrentHierarchyMember.Get('Week day name') 
MATCHES 'Saturday|Sunday'
AND
-- Only count days up to today (not future days)
DateCompare(
[Time].CurrentHierarchyMember.StartDate,
Now()
) <= 0
AND
-- Check if any issues were in progress on this day
(
[Measures].[Issues history],
[Transition Status.Category].[In Progress]
) > 0
)
)
)

If you ever consider trying eazyBI for your reporting needs, please don't hesitate to reach out to us directly (support@eazybi.com) for assistance with setting up your reports and guidance on building custom measures. 

Best wishes,

Elita from support@eazybi.com

[mborinstein]

Hi Elita,

Thank you this is incredibly helpful! I was able to replicate this and am now trying to add the layer of grouping by epic but I'm not sure if it's working. Here is a screenshot of what it looks like when I do so (blocked out some stuff for privacy). You can see that for each assignee it gives me the "Workdays in a Month" total in the Epic row and then gives me other values on the ticket by ticket level. (Workdays in a Month is what I called the custom measure you created).

If you look at the tickets assigned to Lindsay you can see that she has one ticket with 3 Workdays in a Month and another ticket with 20 workdays. Then on the epic level it lists her total as 23. The scenario I'm worried about is let's say she worked on Ticket 1 from October 1 - 20 and Ticket 2 from October 17-20. She only technically worked 20 days but it may be adding that up to 23. 

Do you know if I would need to change the custom measure you created to have it calculate how many unique days she worked in any given month on each epic? 

To make sure I'm being clear - I'm looking for: If she worked October 1 - 20 on Epic 1 it will list 20 days, and if she worked October 3 - 10 on Epic 2, it lists 7 days on that Epic Row. Thank you!

[Mary from Planyway]

Planyway for Jira provides a highly visual and flexible platform that can be configured to meet your reporting needs:

1. You can typically drill down into an epic to see the individual tasks and the assignees.
2. As for non-cumulative time, you can easily group the report by tasks as well to see what's needed.
3. Use Planyway's filtering in reporting to only look at tasks that have moved through your "In Progress" to "Done" workflow steps within a given period.

[mborinstein]

Hi Mary - Does Planyway require engineers to log time on each ticket or is there an option to base "time worked" on time between statuses?

[Mary from Planyway]

Do you mean if it is possible to set time worked in advance by the manager?

[Michał Kowalewski_SolDevelo]

Hi @mborinstein 

For points 1 and 2, our marketplace application Worklogs - Time Tracking, Time Reports, Timesheets should meet your expectations.

1. Grouping by epic.
   
   In the Worklogs app, you can group your data in many various ways, including the possibility to display Epics and their child Jira work items (tasks, stories, etc.). For example, in the screenshot below, I display the following report: Project → Epic → Jira work items.
   
   Based on this information, you can see how much time was spent on each epic and its child issues. Of course, instead of the Project in the first column, you can display your employees to see how they log the time and where. You can also display a different date range based on your needs.
   
   
2. NON-CUMULATIVE TIME.
   
   In the app, you can easily display data and see how employees log their time. You will obtain information about what an employee worked on on a given day and what they worked on the next day. What's more, in the report, you get Summary to see if indeed 8h were spent on the particular day. For example, in the screenshot below, the employee worked on different tickets between November 1-4, and you can effortlessly get such information in the app:
   
   
   
   

The only thing you mentioned that our app lacks is the possibility to count the time in status for the Jira work items. You can always display the current status for the tickets in the report, but it won't tell you how long it took to change it from progress to done, for example.

However, many more functions can be useful for you and your team. With Worklogs, logging time and displaying data become very intuitive.

If you have any questions, feel free to reach us, or if you prefer a meeting, please book a demo session. We will be happy to learn more about your use-cases.

Kind regards,
Michał, SolDevelo Team 

[Iryna Komarnitska_SaaSJet_]

Hi @mborinstein ,
You’re essentially looking for two things:

1. Epic-level rollups by engineer, and

2. Distinct business days an engineer worked in a month (not the sum of overlapping time across multiple issues).

For #2, that’s fundamentally a worklog question rather than a status-time question. Status-based tools read Jira changelogs; they can tell how long an issue sat in In Progress, but they can’t infer whether two issues were worked in parallel by the same person. If both issues are In Progress on the same dates, changelog-based reports will double-count unless your workflow enforces only one active item at a time.

If you want to stay with status-time, the key is process discipline:

• Pause anything not actively being worked. When an engineer switches context, move the first issue out of In Progress (e.g., to On hold).

• Review your workflow. You may need an explicit Paused/On hold state (or similar) so the lifecycle reflects reality.

I’m on the Time in Status team, and here’s how you could build the epic/assignee report with our Pivot view (status-time approach):

1. Rows: Epic → Issue → Assignee

2. Columns/Values: Spent time in statuses

3. Filters: Date range = your target month; project(s)/team as needed

4. Totals: Show totals per Epic; optionally include Epic age

This gives leadership a clear breakdown of time-in-status by epic, issue, and engineer.

For your “non-cumulative days” requirement specifically:

• If this is a hard requirement, you’ll get the most reliable results with worklogs, because they can be analyzed as distinct working days per person per month across all issues (i.e., Nov 1–3 for Issue A and Nov 2–3 for Issue B count as 3 days total, not 5).

• If you prefer status-time, the closest proxy is to enforce that only one issue per engineer can be In Progress at a time (using the On hold pattern above). That prevents double-counting and makes status-time reports much closer to “distinct days.”

Happy to share a sample Pivot configuration or a quick walkthrough if that helps. Hope this clarifies the trade-offs!

[mborinstein]

Hi Iryna - if I want to go the worklogs route how would I do that in the Time in Status app? 

[Iryna Komarnitska_SaaSJet_]

Hi @mborinstein ,

No, the Time in Status app only calculates the time spent in statuses. For worklogs, you can find any app on the marketplace that allows you to log work and generate reports on it.

However, you will not be able to perform a retrospective analysis; only an app that analyzes Jira changelogs will allow you to do this.