How does Scrum deal with handling defects and\or unexpected disturbances?
This is a question that often pops up during my Scrum trainings. Although Scrum does not explicitly give an answer to this question I have seen a usefull pattern that pops up at almost every Scrum team that I’ve encountered in the last 10 years. In this blog I will share this pattern with you. Feel free to share your experiences as well.
Here’s a scenario that might sound familiar:
|Trainee:||"Where does new work goto in Scrum?"|
|Trainer:||"All the work that has potential business value will go into the Product Backlog, that is owned by the Product Owner. It will be refined by the Product Owner and the Development team. Once the work is 'ready' to be picked up by the team, it will be planned into the Sprint Backlog during the Sprint Planning meeting.|
|Trainee:||"Ok, I get this, but for some reason people are continuously coming up with high priority issues that are disturbing our Sprint."|
There can be a number of reasons why teams might be struggling with this problem:
- They might suffer from technical debt
- Not all stakeholders are aware of the mechanism how new work goes to the Product Backlog through the Product Owner
- They might be responsible for the maintenance of other software, that causes a lot of unplannable work (in a way this is technical debt as well)
There are a number of different scenario’s that lead to new work for a Development Team. Each of these scenario’s should be handled with Scrum in order to avoid unclarity. A way to handle this scenario is the following (the pattern I referred to above):
I have often used this pattern to configure the flow in Agile management tools (for example Jira). How this pattern works:
- New features (or new functionality) go directly into the Product Backlog and will be refined in the Product Backlog Refinement by the Product Owner and the Development team.
- Changes are modifications to functionality that already exist. This often happens during a Sprint Review, when stakeholders have inspected the Sprint result and get new insights (but it might also happen due to new market developments at your customers). We make a distinction between New Features and Changes to get insights in how often requirements change (or how good we\stakeholders are at defining their requirements).
- Development Issues are issues that are found during the implementation of an Increment during the Sprint. To avoid the creation of Technical Debt we should always fix Development Issues during the Sprint (this will typically lead to new tasks under the Sprint Backlog item that it belongs to)
- Defects are issues that are found outside the Sprint scope. This means they have not been detected during the Sprint or the Sprint Review. Defects are Technical Debt that we should fix. One of the biggest mistakes, made with Defects is that the priority question is often not handled by the Product Owners, since stakeholders go directly to the team. The Backlog Refinements sessions are a good place where these kind of questions kan be answered.
To summarize, this is were the different activities reside in Scrum:
Defects are propably already present in your increment and therefore always have a high priority (that is also the tension many trainees in my training talk about). With the mechanism described above you can handle defects in an Agile way by focussing on avoiding Technical Debt. However, if you are in a situation where you already have Technical Debt, make sure that you have enough focus on fixing this debt by putting it on your Product Backlog.
More info on this topic? Download my whitepaper “Managing Defects in an Agile environment”