Does it make sense to use Scrum when the dates for sprints constantly change?

Question

Does it make sense to use Scrum when the dates for sprints constantly change?

Our team uses Azure DevOps with Scrum. We have multiple codebases to maintain. However, since things are usually rather chaotic with some team members getting constantly pulled off to work on "other things", the dates are constantly getting messed up. Not only are members (usually 1 or 2) getting tasked with other things, but the end dates get pushed due to "other priorities" that come up that might affect the entire team.

Options being considered:

1. Lower capacity on that sprint for the members that constantly get pulled off, to accommodate the "flux" of other demands that crop up?
2. Once a sprint starts and something comes up that will push the release date, then adjust the end date on the sprint iteration.

In a way it makes me wonder if we simply need to use a spreadsheet to keep track of "stuff to do" and tag one field with a "release #" for those updates getting into the release build. That is a management call however. If we continue with using Scrum, there is no way that any dates, analytics could ever be accurate, could they? Azure DevOps then becomes used as simply a Git repo and an over-complicated "task" list?

Answer 1

In the context of Scrum, a Sprint is a timebox. It has a start and it has an end. Once a Sprint starts, it's timebox is fixed - it will end when it is scheduled to end. There is no concept of adjusting the end date of the Sprint because things come up.

Based on this and the problems that you're describing, I do have some suggestions.

First, I would decouple the notion of your release cadence from the Sprint cadence. At the end of a Sprint, you have a "potentially releasable Increment of "Done" product". However, there is no constraint that the team cannot produce a potentially releasable Increment of "Done" product at any point within the Sprint. There is also no constraint that a release is done only at the end of a Sprint. If, during the course of a Sprint, the team produces a potentially releasable Increment of "Done" product, the Product Owner may choose to release it. Whatever the most recently completed potentially releasable Increment of "Done" product is at the end of the Sprint is the input to the Sprint Review - this may be something that is already released, the Sprint Review is simply the formal event scheduled to align the stakeholders and the Scrum Team with the next steps by sharing lessons learned and feedback.

Second, I would address the problems with people being pulled off. It's well known that context switching not only slows down progress, but can reduce the quality of work. Consider some of the principles of Agile Software Development and Lean Software Development. Is this context switching consistent with giving motivated individuals the environment they need to get the job done? Is this sustainable development and can it be maintained indefinitely? Is this introducing unnecessary waste (partially done work, task switching, waiting, handoffs, extea cognitive load) that can be reduced or eliminated?

I don't have enough information about your organization and teams to say for sure if it makes sense to continue using Scrum. However, I would consider introducing some metrics from Kanban in order to get some more insight into the impact of this context switching that is happening. I'd look at cycle time for work items, from the time that they are started to the time that they are "done". I'd look at work item aging, or how long a work item spends at each stage in the process. I'd look at work in progress and how many work items are at each stage at a given moment in time. I'd also look at some kind of quality metrics - how defects are found that are associated with different work items requiring rework and try to correlate it to cases of context switching or a lot of WIP.

Answer 2

Where do the competing priorities come from? Can you track them on a common backlog in "Scrum of Scrums" fashion and find a common Product Owner who could help set consistent priorities?

Scrum emphasises fixed time-boxed iterations. The idea is to fix the length of a sprint and then stick with it so that the team and stakeholders can have some confidence in the regular cadence of delivery. Certainly this works better if the team availability is relative stable. If team availability is unpredictable then you can reduce the amount of work taken into the sprint backlog each time. You can make the problem visible through a burn chart and try to get key stakeholders to support the case for better resourcing.

You could try shortening the fixed length of sprints if that helps make it easier to predict your team's availability. Don't change the size of a sprint too often though and avoid lengthening a current sprint just because the forecast goal isn't going to be done on time.

If Scrum really isn't a good fit for your organisation then maybe Kanban would be more appropriate. Kanban is more about managing and monitoring flow rather than fixing iteration.

Answer 3

1 Lower capacity on that sprint for the members that constantly get pulled off, to accommodate the "flux" of other demands that crop up?

Yes.

But report this clearly so the impact is understood. The potential for this exists on every team. Among other things, people get sick. Scrum can't control this but it can show the impact and how the team adjusted for it.

2 Once a sprint starts and something comes up that will push the release date, then adjust the end date on the sprint iteration.

No.

The end of a sprint isn't a release date. It's a presentation date. What's presented should be releasable. In the worst case scenario what you present is the same thing you presented last sprint. Which should have been releasable.

The point is, regardless of what happened you're making the situation very clear at fixed points of time. You're not hiding the situation and begging for more time. You're saying this is what we have now.

Answer 4

From what you write it would seem Scrum is not a good match for your team's work. Yes, you could cut down the sprint's capacity of your team, to accommodate the unforeseen tasks that crop up. But that would only be helpful if the amount of distraction is somewhat constant across sprints (which is probably not the case). Repeatedly shifting the sprint end is probably depriving you from all benefits Scrum might offer, as others wrote.

Maybe Kanban is more appropriate for you. You have your tasks visible, and some could have a release tag. You are not concerned about sprint starts and ends, just being transparent what everybody works on. Distractions could be added as tasks to the board so everybody is aware of them, and could be weighed against existing tasks for priority, to the point where you push tasks back to the backlog.

I have no experience with Azure DevOps and if it supports Kanban style work. But in general, analytics would still be possible, reporting about your progress on release-relevant work, even averaged across certain time intervals. Forecasts would not be possible, so you couldn't possibly predict when all work for the next release is done. But that you can't anyway, given your situation, right?!