Burnover. Another name for Stories or backlog items that are incomplete at the end of the current Sprint and fall into a subsequent Sprint. Call it what you like, but if you want to reach your Agile Nirvana, then you need to develop better recognition, techniques for handling, and methods of prevention. If not, then you risk introducing frustration, finger pointing and even issues with team morale.
Does this happen to others?
Absolutely. It occurs more frequently than one might think. No matter the experience level of a Scrum team, Burnover will occur. For teams and organizations early to Agile, this is quite a common outcome and can hinder adoption. I’ve witnessed many situations where Burnover was sited as an example of why Agile wouldn’t work within the organization and why they had to fall back to <insert another non-effective methodology here>.
What Causes Burnover to Occur?
Good news, it’s real simple. Most of the time Burnover is your fault! When I say “you”, I mean your Scrum team (the collective you). For whatever reason, your team wasn’t able to deliver against your commitment. The three most common causes that attributed to Burnover are:
- Overcommitment – This is the result of fairly classic human behavior. As humans we want to help. We want to sign-up for more, always. It’s how we are wired and actually a very important and helpful behavior, but one that requires some reigning in.
- Misestimation – Estimation is a art and one that frankly I’ve struggled with in the past. It requires technique, practice and a good deal of patience in order to perfect. Experience and conscious measurement will help you get better with this. It’s very important to recognize that certain team members will be better at this than others or gaining consistent velocity can prove difficult.
- Impediments – Stuff happens. We are advancing product and technology at such a fast pace. There are many moving parts, teams are collaborating and integrating – and because of this we often uncover surprises. Sometimes these impediments prevent forward progress and result in Burnover.
During your retrospective, it’s important to assess each Burnover Story or backlog item, classifying it as one of the categories above. Knowing the source will better help you prescribe a remedy.
How to Properly Handle Burnover?
Because this will happen, you best know what to do with Burnover Stories or backlog items. First of all, don’t ignore Burnover or sweep it under the rug. Regardless of how you feel, ignoring or hiding will only increase frustration and prolong your teams ability to achieve consistent velocity. Here’s a quick five-step guide on how you should handle Burnover:
- Because the Story or backlog item was incomplete, it’s Story points do not count against the Sprint.
- The Story or backlog item needs to be moved into a future Sprint or into the backlog. You shouldn’t make the assumption that it should automatically move to the next Sprint. Consult your Product Owner and team to find out if the remaining tasks (assuming some had been completed) are still higher priority than other backlog items.
- Opinions vary sharply on this, but personally I prefer to “clone” each of the incomplete tasks for an incomplete Story to move to the next Sprint or into the backlog. This way, we can report against tasks that were completed within each Sprint. Some tooling will let you track and record this without the need to clone.
- Your team will need to review the estimates assigned to each cloned task to ensure that the original estimates are still accurate and the remaining time will need to be reset.
- Your team capacity for your subsequent Sprint with the newly added Burnover Stories or backlog items will need to be adjusted.
Tip: I like to color-code, tag and/or label Burnover Stories and backlog items, so they can be quickly filtered from the active list of committed items within a Sprint. It’s good to keep a watchful eye on these in their subsequent Sprint, so we don’t repeat and push forward into additional Sprints.
Tips for Preventing Burnover
Impediments aside, you can prevent most Burnover from occurring in the first place. Prevention starts with historical analysis of your past Sprints. When coaching teams, I’ll typically build a quick scorecards or something I call a “blame pie“. It’s a simple pie chart that assigns historical totals (output as percentage) against the three types of Burnover (Overcommitment, Misestimation, and Impediments). Using this simple chart will help you focus your attention towards some corrective actions.
Let’s assume for a moment that your blame pie indicates that the largest percentage of Burnover is attributable to Overcommitment. In this case, then as a team you need to decrease Stories and backlog items being committed to each Sprint. While that’s fairly obvious, what I typically see teams doing is guessing at the frequency in which to dial back their commitments. The method that I find works best, is to have your team commit to their historical average, less the historical average Burnover. Repeat until you are delivering against 100% of your commitments.
What if your blame pie indicates that your largest percentage of Burnover is attributed to Misestimation. In this case, you may need to perform some additional analysis. To grow your teams estimation skills, you need to find out the types of Stories and backlog items where misestimation is occurring. Once isolated, look for patterns and find a way to describe or personify the Stories or backlog items along with actions your team will take when they come across something similar in the future. For example, maybe you find a Story that was “Way too large” and really should have been broken into multiple smaller Stories. Develop a “Way too large” persona for this Story and describe the characteristics and the action of breaking the Story into smaller portions. Or maybe you find a task that is not very common, but always takes your team longer than expected because they forget how “Uber complicated” the details are hidden within the task. Develop a “Uber complicated” persona for this task and make sure you indicate that the estimate should always be higher than the initial value assessed by the team. Once you have a series of persona’s, make sure you publish them in a manor where it is easy to reference during your planning / commitment meetings.
It’s unlikely that Impediments are top on your historical blame pie. Not to say it doesn’t happen. I have come across this on rare occasion. True impediments are difficult to predict and therefore prevent. However, I do have several suggestions for how to deal with them and will discuss this in greater detail during a future post. For now, let’s have you focus on reducing and ultimately eliminating Overcommitment and Misestimation from the mix.
Does your team experience Burndown? If so, what are you doing to mitigate? Please share your experiences via comments below or tweet@VelocityCounts.
Enjoy this post? React on Twitter: