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_vujl0e

@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.