Estimating and Tracking of incidents

[Subbulakshmi K]

how you track incident and requests that we received sprint on sprint.

1. Do you estimate them during planning considering the history of incidents received by the team.

2. If you estimate, how do you predict complexity and size?

3. If not, which metric you use to project incident effort and how do you handle burndown n velocity in such cases

[Akash Singh · Accepted solution]

@Subbulakshmi K Welcome to Atlassian Community!

1. Most teams don’t estimate incidents during sprint planning because the volume and complexity can vary. Instead, they look at historical data to reserve a buffer, say 10-20% of their sprint capacity for any unplanned work.

2. If your incidents are somewhat predictable i.e. similar types of incident keeps recurring, then you can group them into categories and assign rough T-shirt sizes (S/M/L) or story points based on past resolution times. For completely unpredictable incidents, avoid detailed estimates and track time spent instead.

3. A few helpful metrics:

• Historical incident effort (in hours) to forecast future sprints.

• % of sprint capacity spent on unplanned work, it helps in adjusting velocity expectations.

• Cycle time for incidents, helps in understanding turnaround.

To avoid skewing velocity, most of the teams that I have worked with track incidents separately (e.g., in a Kanban board or an ITSM project) and don’t include them in sprint commitment. Others use a separate issue type like “Support” and include them in velocity only if estimated.

[Iryna Komarnitska_SaaSJet_]

Hi @Subbulakshmi K 

Great question—incident and unplanned work tracking often gets overlooked in sprint planning, but it’s crucial for teams with recurring operational load.

One tool we’ve developed to help with this is Time in Status (built by my team at SaaSJet). While it doesn’t estimate effort directly, it does give you visibility into how long incidents and requests typically spend in each status or phase. That can be incredibly useful for spotting patterns over multiple sprints—such as average time to resolution, time in triage, or how long tasks remain unassigned.

For example:

Some teams use this historical data to create more realistic buffers or track the actual operational load from one sprint to the next. It also helps explain why velocity fluctuates (e.g., if escalations or blocked tickets absorb more time).

Happy to share a use case if that’s helpful—or feel free to try it out and see if the insights support your planning process.