How should we plan work on support issues without a "battery"?

Question

We are working on a very old project with a lot of legacy code. This means that we have around 3-5 unplanned issues every Sprint.

We were handling that with "batteries": time set aside for unscheduled issues each Sprint. But I recently read an article that recommended against using batteries, and many points from it are true. For example:

1. The battery is always used up, but it's sometimes used for unrelated things.
2. The battery has a negative influence on our velocity.

How should we handle this situation in our projects? And yes, we are doing quality stories to improve the current state of the project. :)

Answer 1

No Invisible Work, Ever!

Work is work, whether it's on bugs or new features. Therefore, all work needs to be tracked on the Sprint and Product backlogs, regardless of the source. If you are using Kanban, it is certainly possible to have a separate queue for bugs vs. new work, but unless you have separate development and maintenance teams, it doesn't matter: you still have queue and global work-in-progress limits that need to be honored.

Bugs Should Slow Velocity of New Features

Bugs, refactoring, and other types of rework are a form of technical debt. Since they count as work, they should actually have no impact on overall velocity if the work is being properly tracked.

The only time hot-fixes and production patches will appear to slow a team's velocity is if the technical debt is not being accounted for. If you were an accountant, this would be called "cooking the books" and would be illegal--so don't do that.

Of course, iterations are time-boxed, so time allocated to fixing bugs or paying off technical debt means less time for new features. This is correct, and an intrinsic part of the framework: to identify the capacity limits of the system, and present the organization with the opportunity to inspect-and-adapt its processes.

Velocity Isn't a Delivery-Date Commitment

Of course, even if your per-Sprint velocity does have wild swings, your average velocity should remain fairly stable. If it doesn't, then the process should be reviewed to uncover the source of the problem: it could be poor estimates, invisible work, technical debt, process issues, or something else. Find out!

More importantly, if average velocity is being impacted by interruptions to the Sprint by support work or technical debt, that's great! That means the velocity metric is doing its job of making the impact to the system of this rework visible to the organization. That's all velocity is really for: measuring variance in team output, and identifying process issues.

Don't Abuse Velocity

If you're using velocity as a management target of how many features must be delivered each Sprint, rather than an estimation and feedback tool, then it's being misused. Velocity is for estimation, and provides a secondary function as a detective control to identify process bottlenecks.

Options for Managing Support/Maintenance

You have some basic options here.

1. Treat bugs and support work as normal Product Backlog items, and require the Product Owner to prioritize them along with new features. In this case, hot-fixes may not interrupt a Sprint without an explicit abnormal termination by the Product Owner and a return to Sprint Planning.

2. Have one team for support/maintenance, and a separate team for development. I would recommend adopting Kanban or some other pull-system instead of Scrum for the support organization, since it's often a better fit for ticket-based demand-queuing, but that's up to you.

3. Reduce work-in-progress limits (for Kanban) or story points per Sprint (for Scrum) to provide sufficient slack in your process--including task-switching overhead--to handle demand-driven interruptions like hot-fixes. If 30% of your capacity is being spent on untracked technical debt, then you need to reduce your velocity estimates by 35-50% to account for it. It's better to track the effort directly, but fudge-factors can work, too.

Educate the Organization

Ultimately, the goal of project management is not to sweep work under the rug, but to make the cost of work (in time and money) visible to the organization so that accurate estimates can be made. Providing honest metrics and accurate estimates to the organization allows business leaders to make informed business decisions--and the more information they have to feed the decision-making process, the better those decisions can be.

Make sure that management understands that velocity is primarily an estimation tool, and occasionally useful as a detective control. Velocity is not a substitute for capacity planning or process engineering. Part of your job as a project manager is to explain the value and proper use of your metrics to the organization.

Be an honest information broker. Making sound business decisions that ensure the success of a project is senior management's job, and your responsibility is to make sure that they are as fully-informed as possible.

Answer 2

I won't make a difference between user stories and issues. The product owner should know whether new features or issues are more important, and should put them into the right order. With this approach you don't have to bother with batteries or velocity, because they are part of the daily work. Based on my experience teams need about 1-2 months to get used to this idea, but after that the work simply flows (setting acceptance criterias for an issue is sometimes easier than for a user story).

One can argue that an issue may have a longer investigation time, which makes the sprint unpredictable. This is a tricky situation, because there are no general solutions. My approach is to check the nature of the upcoming issues during the sprint planning, check out similar solved issues and use this information to find out how the issue fits into the sprint. Sometimes the prediction is just fine, sometimes it takes longer than one sprint to solve that issue, but the very same happens with user stories as well.

My colleagues like the idea to have a separate sprint and a separate team for solving issues of a legacy system. I don't like the separate team approach, because with this approach the feedback loop is cut into to pieces and the development teams won't get enough feedback on their work, and they'll do the same mistakes over and over. When you have a "feature sprint - issue sprint" rotation, you'll loose the predictability and speed. Additionally, based on my experience you'll team will weary of the constant change.

Let's say you'll mix the user stories and the issues. In the beginning the velocity will go down, but due to the nature of a proper Scrum implementation you'll speed up eventually, sort out the issues, can focus on user stories and the velocity will go up again.

One more thing. In this case, I think it would help you to categorize the issues: legacy issues and new feature issues. If you would like to improve your quality you should put more focus on the new feature issues, because you can do something about them.

Answer 3

I agree with CodeGnome, but I would also like to add a bit about legacy code.

So you inherited a steaming pile? Or maybe, your teams built the steaming pile? This is a risk to your project, but it isn't one that should be "managed". It should be reduced. Each and every time you create a task dealing with your legacy code, part of that task should be improving the code beyond merely quick fixing the bug. Add unit tests. Add an abstraction layer to decouple. Refactor something. Anything other than getting in and getting out as quickly as possible. If quick fixing the issue is your game plan for dealing with your legacy code, understand that you are increasing the amount of legacy code with every line added, increasing your team's technical debt, and thereby increasing the risk to your project. You should be actively reducing this risk. It will pay dividends in fewer "live issues".

A final suggestion: Shorten your sprint cycles and make sure "urgent live issues" really are "urgent". If you are running 1 week sprints, often product owners will be satisfied if the "urgent" issue is placed in the following weeks sprint.