2

In capacity-based sprint planning, a calculation can be performed in order to build in production support hours by having one developer's capacity minimized.

How would a team plan for production support in a velocity-based sprint planning model?

4

3 Answers 3

2

If the production support overhead is reasonably consistent, then when using velocity you don't need to do anything at all.

The amount of planned sprint work the team gets done will deduce due to the impact of the production support and this will drag the team's velocity down.

In the end the team will be putting a smaller amount of work in each sprint that reflects the reduced velocity and this will give them the surplus capacity to do the production support.

However, if the production support load is inconsistent then it is going to be a challenge regardless of whether you are using velocity or tracking time.

2

Understanding Velocity

How would a team plan for production support in a velocity-based sprint planning model?

"Velocity" is often used in story-point based estimation processes, but is not mandated by the Scrum framework. That said, a Sprint is simply a time box where the team has a fixed amount of time and effort to expend on whatever activities are accepted into the Sprint.

The goal with velocity is for it to be a relatively stable metric over a sliding window of time. It essentially represents the team's capacity to do work. In development, a stable velocity allows the team to make reasonably accurate predictions about the capacity available to the team to perform work during the Sprint, and to roughly estimate lead time for Product Backlog items.

How "Support Work" Impacts Team Capacity

Work is work, and all work consumes capacity during the Sprint. The problem you have is that "support work" tends to fall into one of two categories:

  1. A reasonably stable percentage of the team's available capacity.
  2. Unpredictable ad-hoc work that can't be effectively estimated ahead of time.

When Support Can be Planned, or Represents a Stable Level of Effort

In the former case, you can simply subtract the amount of time the team typically devotes to support from its available capacity for other work. For example, if a team can usually deliver 20 story points per Sprint and you reserve 7 points per Sprint for support work, then you only have 13 points of capacity remaining for development work.

If the support work can be planned during Sprint Planning, then I wouldn't treat it separately. Just treat it like any other work, with the same estimation process and level-of-effort allocations by the team. However, if the work is unplanned, then you need to treat it as slack in your process that you keep in reserve for the average amount of support work that the team has to deal with.

When Support is Unpredictable

Support that can't be planned, or that varies widely in size and scope, is generally a poor fit for Scrum. If you can't delegate support to a dedicated support process, then you will be forced to accept that support will consume team capacity that may be needed to meet the Sprint Goal.

Think of this as standard schedule or resource risk. You have a limited amount of time and resources each Sprint. If you can't plan for support activities, then you risk:

  1. Missing your product development Sprint Goal whenever support requests take capacity away from essential development activities.
  2. Missing your support service level agreements (SLAs) whenever essential development activities consume more time than remains for support.

In either case, TANSTAAFL. You have limited time and capacity; it's up to the organization to determine how to allocate those limited resources.

Regardless of which activity takes precedence, the general approach to managing unpredictable levels of support within a Scrum process include one or more of the following:

  1. Under-committing instead of over-committing on development.

    By ensuring that you have a lot of slack in your development process, you reduce the likelihood of missing Sprint Goals and requiring an Early Termination and a return to Sprint Planning. It may introduce more lead time from Product Backlog to delivery, but this is likely to be a necessary trade-off.

  2. Capping support work.

    By limiting the amount of support work that can be introduced into the current Sprint, you effectively apply a Kanban-like work-in-progress (WIP) limit to prevent support work from swamping development capacity. By ensuring that this is clearly communicated as part of your working agreements with stakeholders, it sets everyone's expectations while preventing an excess of Sprint Goal failures.

  3. Treating Early Termination of a Sprint as an acceptable business risk.

    If support is more important than development, then the organization (not just the Scrum Team) must accept the inherent risk to estimates in prioritizing unplanned support work over planned development. Whenever support work jeopardizes the Sprint Goal, the Product Owner will likely need to terminate the Sprint so the team can re-plan and re-estimate once the support work is complete. If the team or the organization has determined a priori that support work takes precedence over development work, then it must also accept that development work may be delayed.

It's All Just Project Risk

Risk can only be mitigated, accepted, or transferred. If you can't mitigate the Scrum Team's scheduling or capacity planning risks, or transfer them to a more appropriate team or process such as a dedicated support team, then the risks must be accepted by someone with sufficient accountability and authority.

Whether or not they choose to accept it, senior leadership always owns the risk once properly informed. Once the team has done its own due diligence to evaluate the process and define the available options, it's up to senior leadership to determine how they want to manage that risk.

1

The best predictor of today's weather is yesterday's weather. Velocity-based sprint planning, as you call it, works like that.

If the team capacity and sprint length don't change, if the team does the same job of splitting the stories and estimating them like they did in previous sprints, then you can make a forecast that in the next sprint you will more or less have the same velocity as you previously had.

If team capacity gets reduced for some reason, like people being in vacation, or having to work on things outside the sprint (like production support or incidents), then you can expect your velocity to also decrease according to that.

If you need the team to do production support then that reduces their capacity which reduces their velocity. You now get a new velocity value that you can use to do velocity-based sprint planning.

This works the same if you use hours instead of velocity. You plan with fewer hours in the week going forward, because some hours need to go to production support instead.

So basically, you carve out a portion of the sprint in time/capacity/velocity/whatever for production support. You can estimate how much you need for that moving forward, and then you can measure each sprint if that was enough or if you need more/less of the sprint to dedicate to production support.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.