The Jira Time Tracking Pre-Launch Checklist

[#1]

Most teams treat time tracking in Jira as a switch you flip: enable it, tell people to log time, assume clean data shows up a week later. It almost never does. Adoption stalls, worklogs go missing, reports contradict each other, and within a month, nobody trusts the numbers.

The teams that get it right run through a checklist first, deciding what they're measuring, configuring the foundation, and agreeing on conventions before anyone touches a worklog field.

Phase 1: Define "Why"

Every downstream decision traces back to this phase. Skip it, and you'll configure the wrong fields, grant the wrong permissions, and build dashboards nobody asked for.

• Name your primary goal: billing, capacity planning, SLA compliance, or process improvement
• Confirm billing/capacity goals need granular timesheet data by person and project
• Confirm process-improvement goals need time-in-status data by workflow stage
• Separate effort tracking (manual worklogs) from cycle-time tracking (automatic status duration); don't conflate the two

Phase 2: Configure the Foundation

This is where most rollouts quietly break. Settings here feed every calculation both plugins produce, so errors don't surface until someone questions a report weeks later.

• Enable native time tracking and confirm working hours (e.g., 8/day, 5/week), default unit, and display format
• Add estimate and worklog fields to create, edit, and view screens for relevant issue types
• Configure Worklog Attributes in Worklog Time Tracking & Timesheets (billable/non-billable flags, cost centers, custom metadata)
• Align working calendars across native Jira and both plugins to avoid conflicting reports

Phase 3: Set Permissions

Loose permissions lead to edited timesheets and report fatigue. Lock this down before logging starts, not after a dispute.

• Confirm who can log work via the Work On Issues permission (typically developers, QA, support)
• Decide who can edit/delete worklogs; restrict tightly for billing or compliance use cases
• Choose global vs. per-team Worklog Attributes settings and communicate the standard
• Grant Time in Status Reports read access to PMs, Scrum Masters, and team leads only.

Phase 4: Set Up Dashboards

A shared dashboard on day one drives adoption: people trust reports when they can already see the payoff.

• Add dashboard gadgets from both plugins before launch
• Include timesheet summaries by person, project, and date range (Worklog Time Tracking & Timesheets)
• Include bottleneck and cycle time trends (Time in Status Reports)
• Align the estimate, worklog, and time tracking fields across boards so they reconcile
• Test JQL filters for project, sprint, assignee, and issue type scopes
• Confirm exports work: Time in Status Reports (Power BI/JSON, CSV/Excel) and Worklog Time Tracking & Timesheets (Excel/CSV), and note row caps and refresh cadence

Phase 5: Onboard the Team

Inconsistent logging is the biggest killer of data trust. A short onboarding pass now saves months of "why doesn't this number look right" later.

• Document logging conventions: when to log, how granular, how to handle non-project time
• Set a daily logging cadence (e.g., by 5 PM) instead of Friday reconstruction
• Explain that time-in-status tracking is automatic and needs zero developer effort
• Run a live demo of both plugins with one pilot team before org-wide rollout

Phase 6: Verify Before Launch

A small pilot is the cheapest way to catch a misconfigured calendar or permission gap before hundreds of people log time against it.

• Have 2–3 people log sample work across projects for 3–5 days, across varied statuses
• Reconcile logged hours in Worklog Time Tracking & Timesheets views (by person, project, date, assignee)
• Verify time-in-status numbers match reality (e.g., a 2-day Code Review shows 2 days, not 3 or 48 clock-hours)
• Test billable/non-billable flags in timesheet reports and exports
• Pull all stakeholder reports (timesheet summaries, bottleneck reports, cycle time trends, SLA percentiles) and confirm they make sense
• Test edge cases: worklogs across sprints, backward status transitions, reassignments, billable flag changes

Why Native Jira Isn't Enough for This

If you've worked through the checklist above using only native Jira, you've probably hit a wall. Native time tracking gives you an estimate field, a "log work" button, and a basic worklog total, nothing more. No timesheet views by person or project, no billable/non-billable tagging, no bottleneck analysis, no automatic status-duration reporting. Phases 2 through 6 simply aren't achievable out of the box.

That's because native Jira answers one narrow question ("was time logged?") while this checklist answers two bigger ones: how much effort went in, and where did it get stuck. Each needs its own tooling:

• Effort tracking (the timesheet items in Phases 2–3 and the billing checks in Phase 6) needs a dedicated worklog plugin like Worklog Time Tracking & Timesheets, which adds timesheet views by person/project/date, Worklog Attributes for billable flags and cost centers, and Excel/CSV exports.
• Workflow tracking (the calendar alignment in Phase 2, bottleneck gadgets in Phase 4, and status-duration checks in Phase 6) needs a plugin that reads transition history automatically, like Time in Status Reports, which requires zero manual logging and surfaces cycle time and bottlenecks directly from existing workflow data.

With both in place, the checklist above stops being theoretical and becomes something you can actually configure, test, and launch.

The Throughline

Time tracking in Jira is a process-and-people rollout, not a toggle. The teams with trustworthy data six months in are the ones who:

• Decided to ask their questions first
• Configured native tracking and plugin layers together
• Settled permissions and Worklog Attributes before launch
• Verified the pipeline with a pilot

Worklogs tell you the effort. Time-in-status tells you where it got stuck. Together, you get time tracking data that people actually act on.

Ready to roll out time tracking the right way? Worklog Time Tracking & Timesheets and Time in Status Reports are both available on the Atlassian Marketplace. Set up your foundation before go-live, not after.

Both plugins are available on the Atlassian Marketplace. Set up your foundation before go-live, not after.