Three ways to avoid unplanned work

When a team is creating software it has to take into account that there is more than only feature development. During Sprint Planning work is pulled from the Product Backlog, a Sprint Goal is drafted and an actionable plan is made. 

But what about work that shows up after the Sprint is started? Stakeholders might be in dire need to get stuff done and ask the team to drop what they are doing to get something fixed real quick. Unplanned work can break commitment on the Sprint and demotivate a team.

Welcome change, even late in development

One of the agile principles is to welcome change. As developers we want to deliver beautiful solutions to our users. We can allow change, but we need to think about implementing it as well. All changes have consequences. Consequences on time, effort, capacity and knowledge. In short, we need to refine first to understand what needs to be done so we won't create technical debt (technical debt is work that needs to be done after the solution is delivered). The impact of a late change can be huge. So, we welcome change, even late in development but not late in our commitment (of the Sprint).

Refinement

To minimize unplanned work a team can improve on refining. If unplanned work arises because of incomplete refinement, we should focus on improving that. Using the INVEST acronym can help improving the quality of the story and make it more transparent for the stakeholders. Transparency helps the stakeholders to reflect if they told the right story so that they can change the story before the sprint instead of during one, reducing changes and unplanned (extra) work.

Sprint length

The closest Scrum comes to a project development method like SDM is when we talk about the Sprint. A Sprint can be seen as a mini project, with a fixed planning, a fixed team and a fixed budget. The longer the Sprint takes, the longer stakeholders need to wait to get what they asked for. So the longer the stakeholder needs to wait to see if the story was correct. A longer Sprint length will therefor limit inspectability and adaptability. To reduce unplanned work, improve those by reducing Sprint length. If there is a lot of unplanned work, try a Sprint of a week.

No

The hardest part of being a Product Owner seems to be to say no. There are many stakeholders and a limited time to do work in. Naturally not all work can be done at once, so there needs to be some order of importance. The Product Owner has a Product Backlog in which the work is ordered at the PO's delight. And naturally not everybody agrees with the PO's priorities. It is important for the PO to say no to the items that don't match the scope of the product or are not opportune at the moment. In hybrid Scrum implementations where managers of the PO or Scrum team are responsible for work and HR, this can be a real pain. They can break into the Sprint and wreak havoc if a PO doesn't stand it's ground.

To improve on reducing unplanned work, keep track of it. Find out how much time is spent on unplanned work and compare it to planned work. Find out how much extra time is lost because it is unplanned. Be transparent, present it during review and talk about it with stakeholders. The goal is to reduce unplanned work and become more predictable and deliver on your promise.