A recent client of mine was really struggling with their team’s accountability. One of the biggest issues, it turned out, was injected work from the company owner. How could you expect a team to be accountable to their estimates if the owner of the company regularly injected work into a sprint, completely messing up the planning?
Injected work causes all sorts of issues, including:
Lack of commitment from the team as there’s a sense that plans don’t matter.
Morale issues: “I guess they don’t trust us enough to get this done, or worse, they don’t respect what we do.”
Velocity reports and optimization: If work is constantly injected, it’s hard to measure velocity. (See section on Rolling Stories from One Sprint to Another.)
Definitions:
Injected Work: Users’ stories, tasks, or any other work added to a sprint after it is planned.
Planned Injected Work: Knowing work is always injected, you plan for the injections. Consider planned injected work like training wheels on a bike: they can help you get going as you learn to balance, but they should be removed as soon as possible.
Suck -----------|-----------|----------|--------- Awesome
Suck: Stopping current work midstream to do injected work.
Still sucks: Adding injected work into a sprint.
Sucks a little less: Planned injected work.
Awesome: Work enters through the normal process.
Common Techniques for Handling Injected Work
Horse trading
Change the timing of the sprint
Shorten the duration of the sprint
Plan for the consistently unplannable events
Wait
Break the sprint
There are several techniques for handling injected work. Even the best teams and companies must deal with injected work from time to time. Here are some techniques, which can vary in how effective they are:
Horse Trading:
As soon as work needs to be injected, negotiate with stakeholders on what stories will be pulled out. Before you begin the conversation, remember there’s a good chance the stakeholder won’t totally grasp what a point is. Talk to the team first. The team will know which user stories and tasks can be delayed with the least disruption.
Furthermore, letting the team be part of the decision will help build trust within the group. Injected work should be estimated so an appropriate horse trade can be made. Note: Horse trading is easier to do at the beginning of the sprint than at the end.
Change the Timing of the Sprint:
The timing is not the same as extending the duration of the sprint. Every organization has a certain “flow” or cadence. Examine the organization’s flow and synchronize your sprint cadence to align with the organization’s flow rather than against it.
One of the teams I worked with started their sprints on Mondays because they liked to close a sprint on Friday and then start fresh on Monday with a new sprint. The issue was that the executive team met on Tuesdays to review priorities for the week, which caused the team to continuously replan their sprints because the priorities shifted during the executive meeting. The team adapted and moved their sprint start to right after the executive meeting. This change eliminated about two days of possible misalignment with the company goals.
Shorten the Duration:
Teams often feel like they can’t get the work done within a sprint, and work is being added to the sprint all the time. The logical conclusion to this conundrum is to lengthen the sprint. The better option is to shorten the sprint. I know it sounds counter-intuitive, but it works.
Say, for instance, your sprints are one month. You may have to wait 60 days for work to be put into the next sprint and then released. The waiting period is 60 days because even if you just miss getting into the current sprint (30 days), you have to wait for the next sprint to finish (30 more days). As you shorten the duration, the time you have to wait also shortens.
I recently made this change with a team I work with. Initially, it was a little stressful to shorten their sprint from two weeks to one, but the amount of injected work dramatically dropped. When work was injected, it was right at the beginning of the sprint, and the team wasn’t as frazzled.
Plan for the Consistently Unplannable Events
The agile purist isn’t going to like this suggestion, but I do real work with real teams, which is far from perfect. I was working with some hardcore entrepreneurs, and they just flat-out refused to plan, take part in planning, show up for planning meetings… you get the point. The team would be having a fantastic sprint, and then the owner would text the Product Owner in the middle of the sprint with a never-heard-of-before feature that “had to be done.”
In response, the team began to track how frequently the owner injected work and how disruptive (i.e., how many points) the injections were. It turns out, there were two owners, and on average, each injected two stories each sprint. So, the next sprint, we added four stories with eight points each and labeled them:
Owner 1 - Injection 1
Owner 1 - Injection 2
Owner 2 - Injection 1
Owner 2 - Injection 2
The team was on two-week sprints. So, about day four, if an owner hasn’t injected work, we swapped out his placeholder story with a story in the backlog. Then two-thirds of the way through the sprint, if again, there wasn’t injected work into a sprint, we pulled in a second user story from the backlog and replaced another ticket.
This approach is by no means a long-term solution, but blocking the time allowed the team to work on other areas of execution. Over time, the team was able to improve their processes enough so this approach was no longer needed.
As they started to execute better, they were able to remove the placeholder tickets and stay on track with the sprint as planned.
Wait
Waiting is another option. If sprints are consistently being executed, waiting is a great option. On average, the stakeholder would have to wait only one week for a two-week sprint. For one-week sprints, the wait time would be, on average, only three days.
Break the Sprint
Breaking, aborting, terminating, canceling, or replanning a sprint is a draconian option. Sometimes I will cancel the sprint out of principle (not spite) to clearly demonstrate to the organization all of the disruption caused by the inability to plan.
I include the event on my status reports. I walk the hallways to let everyone know. I phone all the stakeholders and let them know that we had to break the sprint.
There are consequences to injecting work, but if the team keeps sheltering the organization from the consequences, then how is the organization supposed to learn and improve?
If you are lucky, a different stakeholder than the one making the request may challenge the decision—which is awesome. That’s how you know the organization is starting to understand the consequences of injected work into a sprint.
Conclusion
Using these different techniques and approaches will help reduce injected work into a sprint. Once injections are reduced, the team will have the space it needs to continue to optimize. Over time, injections will be reserved for true emergencies vs. everyday tasks.
Why it’s so hard for agile teams is because, at the core, the team is reaching outside of its area of influence and attempting to train the organization, including owners, with a better process. Training takes time, and you have to be patient.
Comments