For what it is worth, my thoughts on unplanned work are as follows 🙂
Unplanned work is largely inevitable on any team unless there are zero defects and no emergencies ever that come up during a sprint. This situation never happens and is probably not even desirable based on the amount of energy/effort it would take to produce a process and quality to that degree, versus getting work out the door at all and to market in any reasonable time. If we were building software for nuclear power stations or medical devices, then this might be more realistic.
So the problem then becomes:
what do we do with unplanned work?
My approach is to first – just measure it. How much time are we spending on unplanned work? i.e. work we didn’t know we were doing at the beginning of the sprint.
The reason we care at all about unplanned work is twofold:
- firstly it gives an indication of the quality of the software if the unplanned work is defect based
- secondly we need to have a handle on it if we are going to be able to produce software predictably in the future
For example:
In any team, there is an actual capacity of people multiplied by useful hours. If the amount of unplanned work is constant, we can accurately know our capacity for future estimates. If the amount of unplanned work is increasing steadily, we know we are not investing enough time in the quality of our work. If the unplanned work is erratic, we have no way of estimating future work.
So in the first instance, just measure it, and then you can see whether it is a problem or not.
This info is independent of Scrum / Kanban / Waterfall / Chaos.