Every few months someone asks Atlassian Community how to track meeting time in Jira, and the thread fills with the same three answers. Jira has no notion of a meeting. Time exists only as worklogs, and a worklog must belong to an issue. So meeting time either gets an issue to live on, or it quietly disappears and the sprint looks like it had five more productive days than it did. Where to log it is the first half of this. The second half is reading the number and letting Planim Time fill it in from your calendar.
Three places meeting time can live
A ceremonies issue per sprint. Create OPS-15 Sprint 42 ceremonies with the sprint, and standups, planning, refinement and retro all get logged there. The point is the report: at the end of the sprint the issue's time spent is your ceremony cost, one number, comparable sprint to sprint. Some teams make it one issue per quarter instead; the per-sprint version is easier to compare.
The issue the meeting was about. A design review of the checkout flow is checkout work. A call with finance about refunds is refund work. Logged on those issues, the time shows up where it belongs in estimates versus actuals, and in anything billable. Standups don't belong here.
Not logging it, and cutting capacity instead. Some teams plan 6 hours a day instead of 8 and never log a meeting. That works for sprint planning until someone asks for a timesheet or wants to know why the sprint underdelivered.
Most teams end up with the first two together: ceremonies on the sprint issue, topic meetings on their issue. Write that rule down once, so nobody has to decide per meeting.
Reading the number
Once meetings have a home, the questions become answerable.
How much of the sprint went to ceremonies: open the ceremonies issue, time spent is the answer. For the trend, a JQL filter like summary ~ "ceremonies" ORDER BY created DESC lists them, and a worklog report or a CSV export gives you the series.
How much of a feature was meetings: on the feature issue, the worklog comments tell you. That only works if the comment names the meeting, like "Design review: checkout flow, 1h", and not just "meeting".
Per person: Jira's built-in reports stop at per project and per version, so for a per-person split you need an external report or an export. Capacity planning off these numbers is its own topic, but teams that measure their meeting share for the first time usually find it larger than they planned for.
Getting the numbers without typing them
The Community threads keep coming back because logging meetings means opening Jira six times a day, or rebuilding the week from the calendar on Friday. Every start time and duration is already in the calendar; you only have to add the issue.
This is what Planim Time does. Connect Google Calendar, Microsoft 365 or, on a Mac, Apple Calendar, with read-only access, and your meetings appear next to your worklogs. An issue key in the title is matched directly. Pick an issue for a meeting once and the app remembers it for that series and that title, so the daily standup goes to the ceremonies issue from then on without asking. Other meetings get keyword suggestions against your issues, and a default issue catches what is left. One click per meeting, or Log all for the day, and each one lands in Jira as a normal worklog with the real start time, the duration, and the meeting title as the comment.
Calendar events stay on your machine, and the Planim Time server is involved only in the sign-in. Private events are not read. The step-by-step, with the manual Log work procedure for comparison, is in How to log meeting time in Jira straight from your calendar.
A three-line team rule
Put it in the team's working agreement:
- Ceremonies go on this sprint's ceremonies issue.
- A meeting about a ticket goes on that ticket, with the meeting name in the comment.
- Log it the same day, from the calendar, not on Friday from memory.
Top comments (0)