Handling the stumbling block of ad hoc tasks or unplanned work

Handling the stumbling block of ad hoc tasks or unplanned work

Working with multiple Scrum teams and across continents, I can assure you that every Scrum or non-Scrum team has felt the pressure and burnout from ad hoc or unplanned work.

It can be a high-priority vulnerability, a so-called production issue, an infrastructure crisis, or simply an unknown tech debt that was left unattended and turned into a big mess.

If you are a victim of this stumbling block, I assure you that reading further might help you either find a possible solution or at least let you commiserate with people who feel the same pain and burnout.

Statement: A critical, high-priority unplanned task needs to be attended without any delay.

Solution: The simplest possible solution might be consulting with the Product Owner to prioritize, and remove one or a few tasks or stories out of the current sprint to address the unplanned work. But believe me, it’s not always that simple. Let’s add some practical impediments that can complicate this simple solution:

• The desire for a flawless report or burn-down will be reduced to ashes if you follow the simple solution;
• There are high expectations from the team to squeeze in this unplanned work alongside the existing commitment;
• Some might even end up underestimating the effort required from 5 days to 5 hours for this unplanned work;
• Burnout and a decline in performance are the outcomes of a continuous burden and multitasking. This often goes unnoticed and adversely affects the team’s performance.

With all these influencing factors, the most critical part of the solution is setting expectations and supporting them with accurate, reliable data. The Scrum framework, various tools, and reports help the team to do so.

Every team must investigate and provide a unique solution to this stumbling block. If the team encounters this demon and wants to find a solution for it, they are already on the right track. Establishing good estimating techniques, exhibiting velocity and capacity reports, fostering a culture of trust, monitoring the amount of unplanned work to see if any patterns emerge, and supporting one another in the team may all help. These are only a few suggestions; there are so many more options to explore.

‍

The next biggest mistake any team makes is adapting and implementing all of these solutions without proper coaching or training.

For example, introducing estimation by installing a planning poker plugin or by ordering the poker cards or even T-shirt sizing won’t help the team understand how exactly they need to handle it. What problem is it going to address and how is this technique going to address it? This is some very basic information that the team needs to be made aware of. The team needs to dig deeper into how they can measure complexity, which sizing technique suits them the most, and why. Finding answers to every “why” is required if you want to get to the logical solution.

Team Capacity Planning

Another example could be measuring team capacity. Even when the official working hours are 8 per day, you cannot simply calculate the capacity as 8*5 = 40 hours of work per week. Capacity needs to be measured sensibly, considering time spent in meetings, various scrum events, and other administrative work such as completing mandatory training, filling in timesheets, vacations, surveys, appraisal cycles, review, one-on-one meetings, etc.

The role of a Scrum Master is critical in this situation. A person who coaches the team not just to evaluate which solutions they find appropriate but also how to implement them the right way. A Scrum Master needs to be like a mirror, showing exactly what the team is building, reflecting what it looks like rather than merely applauding the team for adapting something new.

Regular evaluation is equally as important for keeping tabs on whether the implemented solution is helping the team resolve the intended problem, or whether a decision was made in haste. Flexibility and acceptance are mandatory when implementing such solutions. The team might not get it right on the first attempt; it takes a few iterations before we can evaluate a solution. Early evaluation or no evaluation is equally harmful. 

As I said, there is no one solution that fits all teams. It has to be a tailored approach based on many influencing factors, such as proper coaching, evaluation, setting expectations backed by data, fostering a culture of trust, and, of course, trial and error. That is why transparency, inspection, and adaptation are the 3 main pillars of Empiricism in Scrum.

The quest never ends for a well-bonded, high-performing team. They have to keep their guard up to avoid falling into the same potholes. Sooner or later, the team is bound to face one of the old demons, and that is when it needs to either reinforce its decisions and strategies to maintain stability or again discover what suits the team in the present situation to avoid burnout from the stumbling block of ad hoc or unplanned work. You should also keep in mind that a solution that might have worked for the team in the past may not be the right solution in the present. The team dynamics and understanding have evolved, and so must the solution.

I am keen to hear if any of these issues resonate with my readers. It would be interesting to know if this article provided you with a new perspective or a deeper understanding of the simple problem and its simple solution. Of course, I am also open to learning if any of you found a different route to your destination, a different solution that I or other readers might not have explored. Feel free to share your own words of advice - they might just hit the right note for someone else.