Use Cases & Best Practices

Real-world scenarios showing how teams use Time Tracking and Duration fields to solve common Jira challenges — with step-by-step setup instructions for each use case.

This page shows how different teams use Time Tracking Customfield to solve real problems. Each use case includes what you need, how to set it up, and what the result looks like in practice.

Not sure which field type to use? Time Tracking fields store three values (original estimate, time spent, remaining) and support work logging. Duration fields store a single time value without work logging. See Two field types, one app for a detailed comparison.

---

Separate QA time tracking

Problem: Your team needs to track QA effort separately from development effort — but Jira only has one built-in Time Tracking field.

Solution: Create a dedicated Time Tracking field for QA.

1

Create the field

Go to Jira settings → Issues → Custom fields → Create custom field and select Time Tracking. Name it "QA Estimate".

2

Add to screens

Add the field to the Create, View/Edit, and optionally transition screens for your projects.

3

Use it

QA engineers enter their estimate when work begins (for example 4h). As they test, they log time against this field. The remaining QA time decreases automatically.

Result:

On the issue

Each issue shows both Jira Time Tracking (dev effort) and QA Estimate (QA effort) side by side. Teams can see at a glance how much QA time is left.

In JQL and dashboards

"QA Estimate".RemainingEstimateSeconds < 3600
AND status != Done

Find issues where QA time is almost used up — and build dashboards around it.

Best practice: Use clear, team-specific names ("QA Estimate", "Dev Estimate") so users immediately know which field to log time against.

---

SLA monitoring with Duration fields

Problem: Your support team needs to record an SLA response or resolution time limit on each request — but Jira has no native duration field.

Solution: Create a Duration field to store the SLA threshold.

1

Create the field

Go to Jira settings → Issues → Custom fields → Create custom field and select Duration. Name it "SLA Limit".

2

Configure time units

Open the field's configuration and set hours per day and days per week to match your support team's working hours (for example 8h/day, 5d/week).

3

Add to screens and portals

Add the field to your service project's request form and issue view screens.

4

Set values per request type

When creating or triaging requests, set the SLA limit (for example 4h for high priority, 2d for low priority).

Result:

On the issue

Each request shows its SLA limit as a clear, formatted duration (for example 4h or 2d).

In automation

"SLA Limit".DurationSeconds > 28800
AND priority = High

Trigger alerts when high-priority tickets have SLA limits above 8 hours — a sign that something may need re-prioritisation.

Duration vs Time Tracking for SLAs: If you only need to record the SLA threshold, use a Duration field. If you also want to log work against the SLA and track how much time is left, use a Time Tracking field instead.

---

Contract hour tracking

Problem: You sell services by the hour and need to track how much of a client's contracted budget has been used — without mixing it into the team's regular time tracking.

Solution: Create a Time Tracking field for contract hours, optionally with a workflow validator.

1

Create the field

Create a Time Tracking field called "Contract Hours" and add it to your project screens.

2

Set the budget per issue

When a new task for the client comes in, set the original estimate to the allocated budget (for example 8h or 2d).

3

Log work against the contract

As team members work on client tasks, they log time against Contract Hours. Remaining time decreases automatically.

4

Add a workflow validator (optional)

Add the Require time to be logged validator to the Done transition so issues cannot be closed without logging at least some contract time.

Result:

On the issue

The Contract Hours field shows original budget, time used, and remaining — separate from dev or QA effort.

In reports and exports

project = CLIENT-A
AND "Contract Hours".TimeSpentSeconds > 0

Export all issues with logged contract time. Use TimeSpentSeconds in CSV exports for billing calculations.

Watch out: Make sure your team knows the difference between logging time on Contract Hours vs Jira Time Tracking. Clear field names and a short team briefing prevent confusion.

---

Multi-team estimation with native Time Tracking sync

Problem: Dev, QA, and DevOps each need their own estimates, but your PM still relies on Jira's built-in Time Tracking for total effort on dashboards and reports.

Solution: Create multiple Time Tracking fields and sync them to native Time Tracking using a bucket set.

1

Create the fields

Create three Time Tracking fields: "Dev Estimate", "QA Estimate", "DevOps Estimate". Add them to your project screens.

2

Configure a bucket set

Open Project settings → Time Tracking Custom Field and create a new bucket set. Add all three fields to the set.

3

Teams work independently

Each team sets their own estimate and logs work against their own field. Dev logs to Dev Estimate, QA logs to QA Estimate, and so on.

4

PM sees the total

Jira's native Time Tracking automatically shows the combined remaining and time spent across all three fields. Existing dashboards and reports continue to work without changes.

Result:

For teams

Each team has a dedicated time bucket. They see only what's relevant to them and don't interfere with each other's estimates.

For project managers

Native Time Tracking aggregates everything. Existing Jira reports, gadgets, and automation rules that rely on Time Tracking continue to function as before.

Best practice: Use bucket sets when you need both granular per-team tracking and a combined total. If you only need separate fields without aggregation, skip the bucket set — the fields work independently by default.

---

Time-based workflow gates

Problem: Issues are being moved to "Done" without any work logged, making time reports unreliable.

Solution: Add a Require time to be logged workflow validator to enforce a minimum before closing.

1

Open the workflow editor

Open the workflow for your project and select the In Progress → Done transition.

2

Add the validator

Choose Require time to be logged and set the minimum to 30m.

3

Publish the workflow

Save and publish. From now on, any attempt to move an issue to Done without at least 30 minutes logged will be blocked with a clear error message.

You can set different thresholds for different transitions. For example, 15m to leave "To Do" (ensures someone acknowledged the task) and 2h to reach "Done" (ensures real work was logged).

---

Best practices summary

Naming

Use clear, team-specific names so users immediately know which field to use:

• "Dev Estimate" — not "Time Tracking 1"

• "QA Estimate" — not "Custom Time Field"

• "SLA Limit" — not "Duration"

• "Contract Hours" — not "Extra Time"

A good field name is self-documenting. If you need to explain what a field is for, the name is too vague.

Field type choice

Rollout

Reporting

---

See also

ConfigurationUse Time Tracking fieldsUse Duration fieldsSearch & Reporting