Your team already logs time in Jira. Finance asks what the project has cost so far and whether the budget will last. Jira holds the hours but not the money. Here is how to get from one to the other with the built-in tools, and where that stops.
What Jira gives you
- Worklogs: who logged how much time, on which work item, on which day.
- Time tracking fields: Original estimate, Remaining estimate and Time spent on each work item.
- JQL to find the work items in a project, epic or version, and CSV export with their time fields.
Everything is in hours. Jira has no hourly rates and no budget with an amount and a period.
Option 1: export and a spreadsheet
Exporting work items gives you Time spent per work item, but not per person or per day. For a real cost you need the individual worklogs: author, date and time spent.
- Pull the worklogs with the REST API:
/rest/api/3/issue/{key}/worklogper work item, or/rest/api/3/worklog/updatedplus/rest/api/3/worklog/listfor everything changed since a date. - Keep a rates table with one row per person or role, an hourly rate and a start date. When a rate changes, add a row instead of editing the old one.
- Price each worklog with the rate that applied on its own date: hours times rate. If you only keep the current rate, every rate change silently re-prices past work.
- Group the cost by project, epic or fix version. For epics and versions, include the time on child work items and sub-tasks.
- Compare with the budget: spent so far, remaining, share used.
Prefer a script? There's a free MIT one here: https://github.com/kayabyte-2/atlassian-admin-scripts#jira-epic-cost
Where the spreadsheet breaks
- It goes stale. Worklogs are added, edited and deleted every day, and work moves between epics and versions. A monthly export is out of date within days.
- Forecasting is manual. "Will the money last?" needs a pace, a run-out date and the remaining estimates of open work priced at your average rate.
- Cost and billing differ. What an hour costs you and what you bill the client are different rates, so you need two tables.
- Rates are sensitive. Most people who should see whether a budget is on track should not see what each person costs, so the sheet ends up shared with very few people.
Option 2: Automation
A scheduled rule can look up the work items in an epic or project and message someone when their time spent passes a threshold you typed in. That is a rough check of hours against an hour budget. For money you still need a rates table somewhere, and dated rates are awkward to keep inside a rule. Rule runs also count towards your plan's Automation usage.
Rules that keep the numbers trustworthy
- Never change a past rate. Add a new one with a start date.
- Decide once what a budget covers (a project, an epic and its children, a version or a JQL query) and whether it is one-off or resets every month or quarter.
- Keep non-billable work out with a label, and apply it to the work under it too.
Option 3: an app that reads the worklogs
Full disclosure: we build Burnrate, so weigh this one with that in mind. Burnrate for Jira reads the worklogs your team already logs and keeps the numbers current.
- A rate card with dated cost and billing rates for a default rate, roles and people. A new rate never changes the cost of past work.
- Budgets in money or hours for projects, epics, fix versions or any JQL query, one-off, monthly or quarterly.
- Pace, run-out date, projected spend and an estimate at completion from remaining estimates.
- A Cost panel on every work item and epic, and reports by project, epic, person or month with CSV export.
- Two Jira permissions decide who manages rates and who only sees budgets.
For one small project and a monthly report, the spreadsheet is fine. When several budgets run at once and rates change, keeping it current by hand is the part that stops working.
More detail in the guide: https://kayabyte.dev/atlassian/guides/jira-project-cost-from-worklogs
Jira and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.
Top comments (0)