The goal of all scrum teams is to maximize the amount of value they can deliver sprint over sprint. Spending time working on anything other than value delivery occurs all the time. Scrum teams that are interested in maximizing their value delivered work hard to work around the impediments that impact them. But, it is impossible to completely eliminate all of them. This blog post is about the subject of impediments and how to plan for them and how to track them. Because, if the team doesn’t have the right visibility into their impediments, it will be impossible to improve them. This blog will highlight ways to manage impediments to improve velocity and ensure that teams can have hard data to review in their retrospectives and continuously improve.
Types of Work
Impediments can come in all shapes and sizes. They cannot be avoided. Often they just appear, are dealt with, and then we move on. We tend to ignore the impact that they have on us because we wish they didn’t happen. It will be necessary to organize your work in order to visualize your impediments and their impact. There are 3 types of work that we do:
- Value adding work – This work adds value to our end users and/or our company’s bottom line. Some examples include: Adding features designed to get new customers, saving money by decreasing overhead costs, or providing new infrastructure to expand our market reach.
- Value enabling work – Value enabling work is work that is necessary to perform to enable delivery of value. This includes work such as: Planning, testing, and deploying software.
- Impediments – Impediments are anything that prevents you from completing your value adding or enabling work. This includes things like: Unplanned support, bugs, and non-related meetings.
The goal of all Scrum teams should be to:
- Maximize value adding work by minimizing the amount of time spent on value enabling work and eliminating impediments.
Examples of Work Patterns
To achieve this goal, teams need visibility into the impact of impediments so they can improve them over time. Using the data they can measure their improvement and start to track trends and root causes. Here are a couple of examples of what this data can give:
This team is getting a lot of impediments and it takes a lot of value enabling work just to actually deliver value. This scenario may be familiar to a lot of people. The good thing about Agile is that it gives you the procedures to make this sort of information visible so you can act on it. If this is the state your team visualizing this data is the first step to improving your processes.
Excessive Value Enabling Work
A team that requires a lot of value enabling work. This team has their impediments under control. But, they spend a lot of time on value enabling activities. These activities should be identified so the team can start to minimize them.
This team has their impediments under control and do not have as many dependent tasks required to enable value.
Categorizing all work based on these 3 work types can give teams insight into their throughput of value. In a well formed backlog. These 3 types of work typically fall into the following 3 categories:
- User Stories – define the value adding work that we are currently developing. User stories are the most granular level of definition for value adding.
- NFR (Non-functional Requirement) – defines the value enabling work necessary to complete our Stories/Features
- Bug/Impediment – defines work that is blocking the team from doing more value adding effort.
In the rest of this document we are going to focus on Impediments and describe some tips and tricks to manage and control them.
Managing your Impediments
Statistics are boring to most of us. But there is an old saying around that you can only improve what you measure. Without proper data you are only making decisions based on your feelings. Nobody like getting interrupted so impediments are always annoying. But, do you really have an accurate view of how they are affecting your ability to deliver value? Are you under-estimating their impact? Are you over-estimating their impact? Without some way to measure and compare your performance sprint over sprint your efforts to improve may not have the success you hope. Often, it is not natural for development teams to use data to improve. Traditionally, that has been the responsibility of management. Management typically used data like this to drive improvement. But, when management drives this, the improvements are pushed down on the team based on perceived lack of performance. Often this setup adversarial relationships between the team and their data. Why would the team embrace a process that is only used to expose their shortcomings? Well Agile turns that whole responsibility upside-down. Agile Teams are supposed to be self-managed. That doesn’t mean that they just do whatever they want. It means that the responsibility for improvement lies with the team. Culturally we will always struggle with this transition. But, the change needs to occur and it has to start with the teams building trust in their ability enact improvements. Having good data is the first step to proving this.
Planning for Impediments
Finding a good place to start is the first challenge that teams run into. Impediments are ruining their plans, how can they make their planning better? Teams struggle for a way to plan for their impediments. They can try all kinds of creative ways to identify and plan impediments. One of the common practices is to make work items that represent anticipated impediments and apply estimates to those work items. This is often referred to as the bucketing technique. If you make enough buckets to cover all your impediments that can occur you can identify and
plan for them. But, this rarely works. In fact it often creates situations where the team is under-committing and spending more time on impediment planning than actual value planning.
The Fallacy of Impediment Planning – It is impossible to predict without some confidence in the probability of events. History only tells you something about past impediments. It cannot accurately predict what will happen the next sprint because the nature and impact of impediments can vary so dramatically. Did you predict that your hard drive would crash next sprint?
Let’s look into our crystal ball…
Impediments are the wrong thing to focus on in planning. Any attempt at trying to accurately predict them involves planning for the worst case. If last sprint the team suffered 30% of their time wasted on impediments. Then should they plan for 30% impediments from now on? Even if this was the only sprint that they ever had such a substantial impact? As we discussed earlier, teams need to focus on maximizing the value delivered. Impediments are for the retrospective not the planning meetings. The team should be focused on eliminating these, not working around them. Efforts to improve the accuracy of planning for impediments is waste, avoid this.
So, if you shouldn’t plan for impediments, how can the team be sure and realize their sprint commitments? The answer to this has already been stated: The goal of all sprint teams is to maximize the amount of value they deliver. So the team should focus on that during planning. They should make their plans based on historical team velocity and any planned improvements they make. They should plan to stretch their commitments to ensure they maximize velocity sprint over sprint. If they mix impediments into this process it becomes completely diluted. Impediments are not delivered value and should NEVER be included in a team’s velocity. But teams that add buckets for working on impediments are doing exactly that. For example:
- A team creates a support bucket of 25 story points for this sprint and plan on delivering 75 story points of value. But, they only deliver 65 story points because of unplanned support impediments.
Next sprint they will:
- Plan for 35 story points for support and 65 story points of value. If during any subsequent sprint, they still can’t complete the 65 story points, the team will grow the support bucket again.
This process will continue until the team can predictably realize 100 story points of “velocity”. I put “velocity” in quotes because they are actually doing the opposite. By driving to consistent “velocity” by using support buckets they are actually lowering their real value delivered instead of maximizing it. There will be many sprints that the team doesn’t need the full bucket they allocated to impediments. In these cases, they will not be incentivized to maximize their delivery. Instead they will be content that they can easily meet their commitments.
Driving to predictable velocity is done by managing and eliminating impediments, not planning for them.
Managing and Eliminating Impediments
The first step to managing your impediments is to start tracking them. In order to track them you want to create work items in your system for them. Once you start adding work items you could also provide some categorization of them. Some examples might be:
- Production Support – the team is required to divert from their work to support an issue in production. This can be just debugging or phone support. If there really is an issue that requires a software fix, a Bug work item should be created.
- IT Infrastructure Problem – the team is impacted because supporting infrastructure or tooling is not available. If this impact is preventing the team from completing their tasks, then create an Impediment for it.
- Supporting other Teams – the team is impacted due to support needs from other teams. Note: If this is due to user story work that is related to what the team is trying to deliver, this should be part of planned work for those stories. Only write an impediment if this is unrelated support. For example: Team member asked to help a team that is working on a product that he/she had worked on in the past.
- Unrelated Meetings – if the team is pulled into an unrelated meeting an Impediment could be used to track this. Most of the times these meetings are unavoidable. The Impediment work item is a good way to track the overall impact of them to the team’s velocity.
- Or any other category you may be interested in
The workflow for Impediments could look something like this:
Here are some important aspects to note about the Impediment workflow:
- Impediments that occur during the sprint are moved directly to Committed State – Impediments should be addressed as soon as they are discovered. So, they should immediately be moved to the Committed State. Normally, there is no need to add an effort estimate to the impediment. If the impediment can be planned it is probably a Bug, Story, or NFR. Be sure to use this work item only for true impediments.
- The team evaluates impediments and adds tasks for any work that is necessary – The team should evaluate and create the tasks necessary to address the impediment. Any work that is necessary to resolve the impediment should be captured using the task work item. This is important, because without tasks, there is no way to accurately track the effort impact to the team.
- When all tasks complete, the impediments is marked done – Completing all tasks will close the Impediment. The sum of all completed work for the tasks required is the impact (in hours) of this impediment. It is important to enter completed hours in the task work item so it can be used during retrospectives to identify the impediments that had the largest impact on the team.
Impediments identified during the sprint need to be addressed and completed to unblock teams. The tracking of work and details about the impediment will be brought to the team’s sprint retrospective in order to define process improvements. Accurate tracking of the sprint impediments will give the team much better data to act on. So it is critical to capture as much as possible when the impediment occurs.
Sprint Retrospective and Impediments
As stated earlier in this blog, the sprint retrospective is the place where impediments should be reviewed. If you do proper tracking, it will be easy to set up some impediment reporting that will enable the team to act on pesky impediments that are causing them pain. With all impediments in TFS, the team can set up reporting based on many different views. Below are samples of the types of analysis that can be performed:
Tracking by Type
Tracking total impediments by type:
- There is some obvious growth in the number of production support impediments. This should trigger the team to research what is going on. Is there a quality issue? A large rollout? Major infrastructure changes? During the retrospective, the team should come up with a set of actions to mitigate these issues.
Tracking by Hours
Tracking total impediments by effort invested in resolving (hours):
- Not surprising, there is a growing amount of hours dedicated to production support. But, this graph also shows that an IT infrastructure problem in sprint 17.1.3 had a major impact. But, that impact appears to have resided because for the last 2 sprints there hasn’t been much impact. Is there anything the team should followup with IT? Is there any different escalation procedures that the team should adopt? These questions should be discussed in the retrospective and action items defined around them.
Any issue identified during the retrospective should be added to the team backlog for action in a future sprint. For example:
Make an NFR – if the team is suggesting some infrastructure or process change
Create a Story – if the team feels there is product enhancements that can mitigate impediments.
Write a Bug – if this is a product issue or technical debt problem that caused the impediment.
The team will have to work with the product owner to prioritize action on these issues once they have them identified. But, having all of the data will aid in creating a strong business case to address any work item that is defined to address impediments the team has encountered.
Scrum teams focused on increased velocity of value added work need to be able to differentiate work that adds value, work that is necessary to enable value, and impediments. reducing the amount of work required to enable value and eliminating impediments will maximize velocity for Scrum teams. In this blog we defined some techniques to help teams at Mitchell to:
- Define their work in ways that separate value added work from their impediments
- Collect data as they execute their sprint that will help them to retrospect on their impediments
- Use data collected throughout the sprint to make educated decisions about priority and impact of impediments
These techniques will help teams to begin to manage their impediments and improve based on their experience. But, this problem is more than just data gathering and analysis. it is a cultural shift from top-down management to Scrum teams taking ownership of the impediments that deter them. Everything in this blog are just the tools to help teams make it happen. But, nothing will improve unless the teams feel empowered to take the accountability and ownership to be a truly self-managed Agile team. Thanks for reading this long post. Hopefully you found it valuable. Feel free to add comments at the end or inline anywhere in the document. If you want to connect with me directly feel free to email me. Also, the best way to end off this post is with a Dilbert cartoon. Enjoy: