--- title: "Use cases" canonical: "https://support.appfire.com/space/IC/3217391701/Use%20cases" format: markdown --- The following examples show how teams use Issue History Collector to solve real workflow challenges across different contexts and deployment types. --- ## Identifying SLA bottlenecks in a support queue A service desk manager notices that a growing number of tickets are breaching SLA targets, but the data in Jira alone doesn't show where the delays are occurring. Using Issue History Collector, the manager opens the Issue History Statistics report and filters by project and status. The report shows that tickets are spending far longer than expected in the "Waiting for triage" status — and that the delays are concentrated on specific days of the week. Armed with this data, the manager adjusts the team's working-hours configuration to reflect actual availability, sets a threshold highlight on the TTiS custom field so tickets approaching the SLA limit are flagged automatically, and reassigns triage responsibilities to reduce the queue time. SLA compliance improves within the next sprint cycle. ### How to set this up 1. Go to **Jira Administration > Manage apps** and click **Configuration** in the Issue History Collector section. 2. Under **Projects**, select the service desk project you want to monitor. 3. Add a **Total Time in Status (TTiS)** custom field via **Administration > Issues > Custom Fields > Add custom field**. Select **Total Time in Status** from the list, name it (for example, "Time in Triage"), and add it to the relevant issue screens. 4. Back in the app configuration, locate the TTiS field in the **Total Time in Status custom field** section. Click the cog icon in the **Actions** column and select the statuses to track — for example, "Waiting for triage" and "In progress". 5. In the SLA field for that custom field, enter your threshold in minutes. The field displays green when within the threshold and red when exceeded. 6. To configure working hours so off-hours time is excluded from calculations, click **Settings** in the working hours section. Set the team's timezone, define working days and hours, and add any non-working days. 7. To view delay patterns, navigate to **Project > Reports > Issue History Statistics**. Filter by status to see where time is accumulating across your queue. --- ## Measuring individual contributor throughput for sprint reviews A development team lead wants to bring objective data to sprint retrospectives rather than relying on estimates. Before each review, the lead runs the Assignee History Statistics report for the sprint's project, filtered to the relevant time period. The report breaks down how long each team member held issues in active-work statuses versus blocked statuses. The data reveals that one engineer consistently moves issues through quickly but is frequently blocked waiting for code review. Rather than flagging the engineer for low output, the team restructures the review rotation. The next sprint shows a measurable reduction in review wait time across the board. ### How to set this up 1. Go to **Jira Administration > Manage apps > Configuration** and select the development project under **Projects**. 2. Configure a working-hours calendar for the project so time calculations reflect actual sprint hours. Click **Add** next to the project, then **Settings**, and define working days and timezone. 3. At the start of each sprint, note the sprint start date. At the end, go to **Project > Reports > Assignee History Statistics**. 4. Filter the report by the sprint's date range and select the statuses that represent active work (for example, "In progress" and "In review"). 5. The report shows time spent per assignee per status. Compare active-work time against blocked time (for example, time in "Awaiting review") to identify where handoffs are causing delays. 6. Export the data to Excel using the export option in the report if you want to include it in a sprint review document or share it outside Jira. --- ## Auditing process compliance for enterprise clients A project manager at a professional services firm needs to demonstrate to an enterprise client that tickets classified as "Critical" are being resolved within contractually agreed timeframes. Using the TTiS custom field configured to track time in the "In Progress" and "Under Review" statuses, the manager builds a Jira dashboard gadget that displays current compliance at a glance. For the monthly client report, the manager exports the Issue History Statistics data to Excel, adds it to the report template, and delivers it without any manual data gathering. The client gains confidence in the team's process adherence, and the manager saves several hours per reporting cycle. ### How to set this up 1. Go to **Jira Administration > Manage apps > Configuration** and select the client project under **Projects**. 2. Add a TTiS custom field via **Administration > Issues > Custom Fields > Add custom field**. Name it to reflect what you're tracking (for example, "Active resolution time") and add it to the issue view screen. 3. In the app configuration, click the cog icon next to the field and select the statuses that represent active resolution work — for example, "In progress" and "Under review". 4. Enter the contractual SLA threshold in minutes in the SLA field. The TTiS field will display green for compliant tickets and red for breached ones, visible directly on each issue. 5. To create a compliance dashboard, go to a Jira Dashboard and add the **Issue History Collector gadget**. Configure it to show the relevant project and report type. This gives stakeholders a live view without needing to run reports manually. 6. For monthly reporting, navigate to **Project > Reports > Issue History Statistics**, filter to the reporting period, and use the **Export to Excel** option to pull the data into your report template. --- ## Benchmarking status durations after a workflow redesign A Jira admin has simplified a project's workflow, collapsing several redundant statuses into a single "In Review" stage. Before the change goes live, the admin uses Issue History Collector to capture baseline data on how long issues historically spent in each of the old statuses. After the redesign is deployed, the admin runs the same report against the new workflow after two sprints. The comparison shows that the consolidated status has reduced total review time by an average of 1.5 days per issue. The admin presents this data to leadership as evidence that the workflow simplification achieved its intended outcome, and uses the same approach to monitor regression going forward. ### How to set this up 1. Before making any workflow changes, go to **Project > Reports > Issue History Statistics** and run a report against the current workflow. Select each status you plan to consolidate or remove and note the average time spent in each. 2. Export the baseline data to Excel using the **Export to Excel** option. Label it clearly with the date and workflow version. 3. Implement the workflow changes in Jira. If you're adding new statuses to replace old ones, go to **Jira Administration > Manage apps > Configuration** and verify the project is still selected under **Projects**. Issue History Collector begins capturing data for the new statuses automatically once they appear in the project. 4. After two sprints, return to **Project > Reports > Issue History Statistics** and run the same report against the new statuses over the equivalent time period. 5. Export the post-redesign data to Excel and compare against the baseline. Look at average time per status and total throughput time to quantify the impact of the change. 6. To monitor for regression on an ongoing basis, add a TTiS custom field for the key consolidated status and set a threshold. If time in that status starts creeping up, the red highlight on issue views will surface the trend before it becomes a problem.