Wondering why these are being retired and what I can use to get the same insights?
Hi @JAGEI tried to find an official explanation from Atlassian, but so far I haven't found any documentation explaining why these reports are being retired. The current support documentation still describes the reports without mentioning the deprecation, and recent Community questions about the retirement haven't received an official response yet.You can have a look at that thread.https://community.atlassian.com/forums/Jira-questions/Why-are-Version-Report-Release-Burndown-and-Epic-Burndown-being/qaq-p/3255262#M1185560
The only official explanation is Ben Payne's, from Atlassian, on 13 July in the thread Gor linked. These were among the six least-used legacy reports, so a retirement banner went up to see who objected, and three were kept because people did. Time Tracking, User Workload and Version Workload drew little response, so they stayed on the list. Atlassian has not posted there since. If you rely on one, say so on that thread; it is the lever Atlassian named.
Meanwhile, Time Tracking is easy to rebuild: a filter in list view with Original Estimate, Time Spent and Remaining Estimate as columns gives the same per-issue comparison, and it exports.
For User Workload, the Workload Pie Chart gadget grouped by Assignee totals remaining estimate per person. But like the report, it only gives a total: 30 hours on someone means little until you know whether they have 20 or 40 hours available this fortnight.
Disclosure: I built a Jira app called Project Commander, on the Atlassian Marketplace. It covers that gap, setting each person's outstanding work against their own capacity after leave and holidays. It does not replace Time Tracking.
Hi JAGE, adding to Project Commander's reply: voting on Ben Payne's thread is the one lever Atlassian named, so do that first. Meanwhile, here is how I'd rebuild each of the three natively so nothing breaks when they go:
project = ABC AND fixVersion = "1.4" ORDER BY Rank
resolution = Unresolved AND assignee is not EMPTY
fixVersion = "1.4" AND resolution = Unresolved
The one thing none of these do (and the old reports didn't really do either) is "hours logged per person per week." worklogAuthor = someone AND worklogDate >= startOfWeek() will find the work items, but the list still shows each item's total Time Spent, not that person's hours for the week.
worklogAuthor = someone AND worklogDate >= startOfWeek()
If that per-person weekly view is what you actually used these reports for, Aneto Hours Reports and Resource Planner builds timesheets from the Jira worklogs you already have (by person and project, filtered by JQL). It also shows capacity next to time spent, so you can see who is over-allocated for a given week.
Disclosure: I work at Aneto Software, which makes this app.
Adding one native method for the piece Josh flagged as missing, hours per person per week. JQL can't sum worklogs, but the REST API can list them: GET /rest/api/3/search/jql?jql=worklogDate >= startOfWeek() AND worklogDate <= endOfWeek()&fields=worklog returns each matching work item's worklogs with author, started date and timeSpentSeconds. Two traps: the issue-level worklog field only includes the first 20 entries (fetch /rest/api/3/issue/{key}/worklog for busy items), and you have to filter by started inside your window because the issue's worklogs include all history. A 30-line script into a spreadsheet gives finance the per-person weekly grid; it's what most teams do until they pick an app. Disclosure: I'm the developer of Native Timesheets for Jira (Forge, in Marketplace review).
GET /rest/api/3/search/jql?jql=worklogDate >= startOfWeek() AND worklogDate <= endOfWeek()&fields=worklog
worklog
/rest/api/3/issue/{key}/worklog
started
Hi, I'm Alexey 'Ce' from CelesteCS. For the Time Tracking report specifically, if a Confluence page works for you, our Reporting for Confluence app (Cloud and Data Center) rebuilds it from live Jira data: a Reporting Jira Data Provider with your JQL (a version, a sprint, an epic) and the fields summary,status,timeoriginalestimate,timespent,timeestimate, one column per field (divided by 3600, as Jira stores seconds), totals in the footer, and the issues whose logged plus remaining time exceeds the original estimate highlighted:
summary,status,timeoriginalestimate,timespent,timeestimate
Sorting by assignee, or one table per person, gives a per-user view of the same numbers, and the aggregate fields (aggregatetimespent etc.) include Sub-tasks.
aggregatetimespent
Configuration: Replacing the retired Time Tracking report with a Confluence table
One honest limit: it reports per issue, so "hours one person logged on issues assigned to someone else" (true worklog-level reporting) still needs a timesheet app or the REST API approach Alfred described.
It looks like you're new here. Sign in or register to get started.
