Unplanned Work — Step 1

For what it’s 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 that come up during a sprint. This situation never happens. It’s 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’re going to produce software predictably in the future

For example:

In any team, there’s 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’re 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. Then you can see whether it’s a problem or not.

This info is independent of Scrum / Kanban / Waterfall / Chaos.

Show your support

Clapping shows how much you appreciated Simon Powers’s story.