How to Deal with Unplanned Work in Software Development

Unplanned work is just what you would expect—anything that needs to be done but hasn't gone through the usual planning cycle. This can be things like urgent bug fixes, unexpected opportunity-based feature requests, or sudden late-stage changes in requirements. Unplanned work can affect your team's productivity, planning accuracy, morale, and general job satisfaction. It also can displace other deliverables the team was supposed to be working on, which can have a follow-on impact on customers. However, most importantly, you should realize that unplanned work being detrimental to your team and deliverables is not intrinsic; it is potentially a symptom of other issues in your development process that can be addressed.

‍

This guide outlines some strategies for mitigating the detrimental impact of unplanned work in the short term and how you can modify your processes to reduce the risk and impact of unplanned work in the long term.

‍

Short-Term Tactics to Deal with Unplanned Work

If you are actively dealing with unplanned work, there are short-term tactics that you can try to take some of the pressure off. However, you should note that these are not sustainable solutions, and more extensive mitigation requires longer-term solutions that target the costs of unplanned work at the source (more on those later).

‍

Absorb

The default way to deal with unplanned work for countless teams is to simply absorb the work. This means you take the incoming unplanned work and simply fold it into your existing workload. If you work in sprints, this might look like adding one or more new tickets to the active sprint. Once the work has been absorbed, you can reprioritize the sprint's work if necessary. However, if you haven't left buffer capacity during your planning, it's likely that something you originally planned will be finished on time.

‍

Replace

If absorbing work means there is a good chance other work won't get done, you can expose this trade-off to stakeholders upfront by _replacing_ something with unplanned work. With this tactic, you would ideally remove a volume of work roughly equal to the amount you inject (again, assuming you have not provisioned any buffer for unplanned work). This way, you know that if the volumes of work are similar, then the sprint should still be able to contain all of the _newly_ selected work. For the things that were removed to make room, you have a concrete list to show stakeholders what has been delayed and why.

‍

Reject

Sometimes, unplanned work that is a priority for some stakeholders can arise, but it may not be urgent enough to inject into your current sprint through either _absorption_ or _replacement_. In these cases, the third immediate tactic you can employ is to _reject_ the work from your active sprint and handle it through your normal refinement and planning processes. This protects the work that you initially committed to and mitigates the risks posed by unplanned work.

‍

The immediate drawback to this approach is that it will leave some stakeholders unsatisfied in the short term. In the best-case scenario, the unplanned work won't be urgent. However, it is also possible that the unplanned work is time-sensitive—for example, a critical bug fix or a feature request to secure a client contract. In this case, preventing it from being injected into your sprint may lead to opportunity costs for the business.

‍

Long-Term Solutions to Prevent Unplanned Work

There are long-term solutions that can sustainably mitigate the impact of unplanned work, although these are not necessarily quick to implement and will require some planning and coordination. These solutions are not mutually exclusive, and you can use them together for a better chance at success.

‍

Provision a Buffer

Unplanned work is not inherently a bad thing. Much of its cost comes from the fact that it will often derail work that has been planned when handled through either _absorption_ or _replacement_. Including a buffer for unplanned work at planning time can mitigate this risk—expecting the unexpected.

While it can be demotivating, unplanned work being injected is rarely surprising when it happens. For some teams, it is simply a common occurrence. It becomes problematic when all of the team's capacity for a sprint or quarter is dedicated to explicitly known work, leaving no capacity for the anticipated work that is likely to be injected.

Instead, if you leave buffer capacity during your planning, one of two things will likely happen:

• Work will be injected: As anticipated, unplanned work might arise, which you can now absorb, to an extent, without jeopardizing your planned work.
• The buffer won't be needed: In some cases, if little to no unplanned work arises, the buffer will be partially or entirely unused. Rather than being a negative, this is a secondary benefit of using a buffer. If you complete all of your planned work for the sprint or quarter with capacity to spare, nothing stops you from pulling future work from your backlog to get ahead of the curve. Stakeholders certainly won't be upset if you're ahead of schedule.

To get an idea of how much buffer room you should leave, you can use a rule of thumb, like 10 to 20 percent of your overall capacity, or for a more accurate estimate, you can refer to past data to see how much work is likely to be injected. However, even with a buffer, you are still limited in the amount of actual work the team can do. Because of this, it's important to keep the buffer available for important tasks. You can refine the importance and urgency of work that makes it to the buffer by implementing stricter prioritization.

Improve Your Prioritization

Regular prioritization and planning are key aspects of working for agile teams. Planning and prioritization sessions are important for your team's long-term sustainability as they allow you to determine which work is the most valuable for your team to do and whether you have the information and context you need to do that work.

‍

When unplanned work arises, it often bypasses both of these processes. It's picked up by the team under the presumption of being more important than the already-planned work, especially when it replaces another piece of work. Requests for work to be injected will always happen as long as you have different stakeholders with their own priorities.

‍

However, in many cases, injecting work without putting it through proper planning and prioritization can do more harm than good if it displaces work that was already committed to. Remember that even with a buffer, you can only safely handle so much unplanned work.

‍

To further mitigate the impact of additional work being injected, you can insist that all work must go through appropriate prioritization, planning, and refinement sessions. This insistence should deter nonurgent, unplanned work requests. Still, some stakeholders will likely insist that what they need is urgent and cannot wait. It could be an urgent bug or a time-sensitive opportunity.

‍

At this point, you'll need to decide whether your buffer can handle the request and if it is strategically prudent to do so. You may determine that you simply cannot inject the work without putting other priorities at risk. There is no hard-and-fast rule for what you should do in this situation. In some cases, unplanned work may truly be the most valuable thing you could work on at a given moment, and this is a decision you must make on a case-by-case basis.

‍

To reduce occurrences where you cannot fall back on a well-known process, minimizing the potential sources of unplanned work as much as possible is helpful. One major source of unplanned work that you can reduce through well-known processes is urgent bugs.

Focus on Quality

Software-quality issues lead to bugs, which can range from innocuous glitches to showstopping blockers. The more severe a bug is, the more likely it will need to be fixed urgently, regardless of planned work. Therefore, it stands to reason that if you can decrease the occurrence of bugs in your software, you will face fewer unplanned work requests to fix those bugs.

‍

Urgent bugs arising in production in the middle of the sprint are a sign that you likely have deeper quality issues. To mitigate them, you need to identify the gap in the development process that allowed these quality issues into production. Some examples of potential gaps include the following:

• A lack of automated or manual testing
• A lack of acceptance testing
• Inadequate acceptance criteria for tickets
• A gap in your code review process

You can narrow in on potential gaps by considering where in the software development process a quality issue should have been caught:

• Automated testing: Should automated tests have caught this issue in your CI pipeline?
• Code review: Is this issue something that reasonably should have been noticed in a code review?
• Acceptance testing: If it is an issue with functional requirements, should it have been caught during acceptance testing?
• Prerelease validation: If you have a prerelease validation process, would you have expected this issue to be caught at that stage?
• ‍

If multiple stages are applicable, you need to address them all. Still, it makes sense to shift left on the fix as much as possible since fixing issues is generally cheaper the earlier in the development lifecycle you do it. By iteratively improving your quality practices, you can reduce the volume of urgent bugs that arise, which will directly impact the number of unplanned bug fixes you need to work on.

‍

As with anything, the only way to know if you're making progress on reducing your unplanned work is to have a reliable way to measure it.

Enter DevStats

DevStats is a platform that helps you track and measure analytics about your dev team. By integrating with tools like GitHub and Jira, it can automatically pull the information it needs to create powerful reports and insights.

‍

For instance, if you want to implement an unplanned work buffer, you need to know roughly how much unplanned work to expect, at least initially, before making other changes. With DevStats, this is as simple as running an allocation report over a given period. This report shows the allocation breakdown of your work, highlighting how much was from your roadmap and how much was unplanned.

‍

This is also incredibly helpful when you try other strategies to manage your unplanned work volume. When you measure something, you put yourself in a position to improve it, and unplanned work is no different. With this information, you can gauge the effectiveness of the strategies you implement to see which ones have a material impact on your team.

‍

Wrapping Up

Unplanned work can be a major source of disruption for software development teams. From developer burnout to unhappy stakeholders, there are countless reasons you may want to reduce the amount of unplanned work your team has to do.

‍

While there are short-term tactics you can employ to handle unplanned work as it arises, these tactics have pretty significant drawbacks and are not sustainable on their own. Instead, you'll want to employ long-term solutions that mitigate the impact of unplanned work at the source. This could be by providing a buffer to give your team the capacity to handle high-priority requests, keeping to a strict prioritization process and rejecting less urgent unplanned work, or by dealing with underlying quality issues to reduce the urgent bug fixing you need to do.

‍

Whichever approach you decide to try, you need to be able to measure its effectiveness. DevStats can help with this by providing reports and insights based on data pulled from the tools you already use, like GitHub and Jira. Give it a try today to start getting your unplanned work under control.