This entry is cross-posted from the Responsive Advisors blog, and includes an easy reference PDF for download, also from Responsive Advisors.
SPRINT PLANNING IS DONE…OR IS IT?
Sprint Planning adjourned! It was challenging, but you and your Scrum team formed a Sprint Goal, chose items from your Product Backlog, and created a plan to complete these items and achieve your goal. Well done!
…and that’s when the “emergencies” begin coming to your team. Your Sprint is planned. Does Scrum even allow for unplanned work? Isn’t the Sprint Backlog locked down after Sprint Planning? How would you adapt your Sprint plan to accommodate these so-called emergencies, anyway? The answers may surprise you.
DOES SCRUM ALLOW FOR UNPLANNED WORK?
There’s a well-intentioned, but incorrect idea out there that once a Scrum team finishes Sprint Planning, your newly-formed Sprint Backlog is locked in place, shouldn’t be touched, and is metaphorically set in stone. This idea is well-intentioned but incorrect. We commit to the Sprint Goal at Sprint Planning, but the items on the Sprint Backlog are flexible. The Scrum Guide makes this clear in the section on the Sprint Backlog:
[The Sprint Backlog] is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned.
The Scrum Guide, November 2020 edition
The reason you’re using Scrum in the first place is to manage the unknowns and changes inherent in complex work. Of course, there will be pieces of unplanned work that crop up in this complex domain. While it’s ideal to funnel most of that work into the Product Backlog for future sprints, it would be unrealistic to set an unbreakable rule that no work shall be added to the Sprint once Sprint Planning is complete. In other words, yes, Scrum allows for unplanned work to be added to the Sprint, as long as the Sprint Goal is not put at risk. In fact, there are at least two very good reasons to do so.
TWO TYPES OF UNPLANNED WORK
The first type of unplanned work you may add to the Sprint Backlog is work discovered in pursuit of the Sprint Goal. Think of a time you planned out an activity — not necessarily technical or professional work, but perhaps a home project, a volunteering activity, or a social event that you were planning. Have you ever discovered new tasks that you needed to do in order to complete your goal that you didn’t know about when planning? How about tasks that you couldn’t have known about during your planning?
These tasks are called unknown unknowns — risks, tasks, or other items that we aren’t aware of at planning, but rather discover once we’re in the process of executing the plan. When these types of tasks are discovered during a Sprint, and they are necessary to meet your Sprint Goal, they should be made transparent and the Sprint Backlog should be adapted as needed. The Developers have the authority and should be empowered with the self-management to do just that.
Another type of unplanned work that might be added to a Sprint is emergency work that comes to our attention during the Sprint. Imagine your team is building a flourishing e-commerce website. Visits are up, sales are booming, and you are pursuing a Sprint Goal that has the potential to double your reach into the marketplace. Suddenly, someone from your security team bursts into your office. There’s been a security breach and customer information — including passwords and credit card numbers — has been leaked. Your team is needed to help resolve the issue. How do you think the phrase “we’ll get to that next Sprint” will go over?
Like it or not, there are true emergencies that require that we change our plans for the Sprint. I once worked with a company that administrated health care plans for their customer. One day, they got a call from a client who said they had several employees who could not access their Health Savings Accounts. This was a true emergency that could not wait until their next Sprint. In cases like these, Scrum Teams may adapt their plans for the Sprint, as long as the Sprint Goal remains paramount. It’s this type of unplanned work that we will focus on for the remainder of this blog.
WHO DECIDES ON UNPLANNED WORK?
The accountabilities in Scrum are generally clear on their boundaries when it comes to the two backlogs: the Product Owner manages the Product Backlog, while the Developers manage the Sprint Backlog. When it comes to unplanned work, there should be a conversation between at least these two accountabilities, if not the whole team.
The Product Owner brings an important perspective on how the unplanned work relates in terms of value and relation to the Product Goal. The Developers have an important perspective with respect to the unplanned work and its relation to the Sprint Goal and the other items on the Sprint Backlog.
While the ideal scenario is a unified decision from the whole team, ultimately the Developers have the final decision on the unplanned work, as it is being added to the Sprint Backlog, which the Developers own and manage. If the Developers think the work can be added without putting the achievement of the Sprint Goal at risk, they are free to add the item(s).
ASKING THE 5 WS FOR UNPLANNED WORK
Just because adding unplanned work to the Sprint Backlog is allowed doesn’t mean it’s always a good idea. In fact, I’d conjecture that more often than not, adding work during the Sprint is a mistake that can jeopardize the Sprint Goal and the team’s effectiveness. That’s especially true of the latter type of unplanned work mentioned above: the emergencies (or “emergencies” as the case may be) unrelated to the Sprint Goal.
So, if unplanned work comes to the Scrum Team, it’s important to think critically about these new items, rather than just add them to the Sprint Backlog without question. In fact, I propose the following five questions be added when considering adding unplanned work during a Sprint: Why?, Workaround?, Wait?, Where?, and What Drops?
WHY: DO WE UNDERSTAND THE VALUE?
This may seem obvious, but I often see Scrum teams add items to their Sprint Backlog without taking the time to dig into why the request is being made in the first place. Who is asking for it? Who is affected by it? How many people? How could it affect our team and our organization at large? Don’t be afraid to ask why multiple times to get to the root cause of the request.
WORKAROUND: COULD WE DO SOMETHING ELSE FOR NOW?
Oftentimes, “emergency” unplanned work comes in the form of a request to resolve a specific issue — a defect in a product, a customer support request, or a fix for something that is broken. Perhaps this issue was even known, but it was thought that the resolution could wait a while and now the issue has been escalated. In these scenarios, it can be helpful to consider a quick alternative to the “real” solution as a compromise. Is there something you can do to temporarily solve the immediate problem, minimizing the impact to your current Sprint Backlog, and then the more permanent solution could be added to you Product Backlog and taken on during a future Sprint?
WAIT: COULD THIS SIMPLY BE DONE LATER?
Another question that seems so obvious, but is often missed entirely is: Can this wait? Or, to unpack it a bit further, what would be the impact of putting this on the Product Backlog and getting to it at the next Sprint, rather than interrupting an already-planned Sprint and potentially jeopardizing the Sprint Goal? Presumably, perhaps this is being requested now because there will be some negative impact to waiting. That impact should be compared against the impact of potentially not completing items planned for this Sprint, or worse, potentially missing the Sprint Goal.
WHERE: HOW DOES IT COMPARE ITEMS ALREADY ON THE BACKLOGS?
We have two backlogs in Scrum. The Product Backlog contains work for future sprints. The Sprint Backlog contains work for the current Sprint. If work is added to the Sprint Backlog during a Sprint, that is inherently stating that this new work is more valuable than all the work on the Product Backlog, and potentially more valuable than some of the items on the Sprint Backlog. But is that true? Sometimes a request comes in with such urgency that we don’t stop to consider the relative priority. Perhaps it’s not more valuable than everything else on the Product Backlog, and it should be ordered by the Product Owner and stored in the Product Backlog for a future Sprint.
WHAT DROPS: IF THIS CAUSES SOMETHING TO GO UNDONE, WHAT SHOULD IT BE?
While slack in a sprint can be very beneficial, many Scrum teams plan a sprint based on their capacity, and some even plan very aggressive sprints knowing they may not achieve everything on the Sprint Backlog. The advantages and disadvantages of these Sprint Planning choices are for a debate at another time. The takeaway here is that adding unplanned work into a Sprint might cause some work that was planned to not get done, but must not jeopardize the Sprint Goal.
When adding items to the Sprint in progress, the team should think through that potential impact not just in terms of the Sprint Goal, but also in terms of the items planned for the Sprint. If this new work is done, but these planned items don’t get finished, is that a win for our stakeholders? For our Product Goal?
Ideally, you should be transparent at the Sprint Review with a statement like, “We had planned to do Item X this sprint, but added Item Y to this Sprint at Stakeholder Z’s request, which led to Item X not getting completed this Sprint.” If we’re making the right call by adding Item X, there should be broad levels of agreement that this was the correct decision.
USE THE 5WS FOR UNPLANNED WORK
Adding work to a Sprint already in progress is not ideal. The Sprint is supposed to be an agreement between the Scrum Team and Stakeholders. The Scrum Team provides flexibility to change direction each sprint. The Stakeholders provide stability and leave the Scrum Team alone during the Sprint to achieve their Sprint Goal. However, true emergencies do crop up from time to time.
The Sprint Goal is your commitment to the Sprint Backlog. Don’t put it at risk by adding unnecessary items during the Sprint. If you must consider adding unplanned work, use the 5W Questions to think critically before adding it to the Sprint Backlog. Download 5Ws for Unplanned Work as a quick reference for you and your team and use them as they are, or modify these questions to your specific context.
