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



  • 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?



  • 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.


Log in to reply
 

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2