How should we approach estimation when it comes to bugs?
Priority bugs should take priority over planned sprints, and the sprint should be adjusted accordingly (i.e. backlog items removed and rescheduled)
I recently updated our bug classification guide to include this statement about P1 bugs, which prompted the question:
How should we approach estimation when it comes to bugs?
I estimate bugs in the same way as any other item in the sprint backlog – a best effort based on perceived complexity and effort.
However – the underlying issue here is how often sprint backlogs need to be adjusted to account for variability. If you find yourself regularly shuffling backlog items or not delivering on your sprint goal due to reactive/unplanned work, you're probably over-planning your sprints.
Building slack into sprint planning
In a variable system, efficiency decreases exponentially as utilisation increases. Beyond around 80% utilisation, queue time increases dramatically and your ability to take on new work effectively stands still.
Instead of optimising for 100% utilisation towards roadmap contribution, I like to aim for 80% utilisation and implement a separate prioritised backlog of items which still deliver value, but aren't time-sensitive. This approach helps to ensure we're delivering smaller iterations faster, with capacity in reserve to absorb any unexpected additional issues.
Recommended reading
Rosie
Jacob Singh
Troy Magennis