2

I noticed this:

In the real world, people do change the end-date for Sprints.

In this Answer.

But I've never experienced a need for that, myself. Or maybe I have, didn't recognize it, and missed an opportunity!

So... when/why would a Sprint ever need to have its end-date extended?

NB: I'm not talking about having Sprints of varying lengths, e.g. to accomodate holidays. I'm talking about when one is in the middle of a Sprint and decide to extend its end-date.

  • 3
    Every single example I can imagine is an anti-pattern. If you're asking why people might employ an anti-pattern, then this probably becomes an infinite list-generating question. There are never valid reasons for doing this unless you're permanently changing your Sprint length to increase the size of the time box. – Todd A. Jacobs Apr 29 at 13:31
  • @ToddA.Jacobs False premise, then, I guess. I (mis)understood from your Answer that there are valid reasons to extend a Sprint. I also couldn't think of any, hence this Question. – Sarov Apr 29 at 13:36
  • I see the quote you're referring to. Taken as a whole, it says that people do, but it's a project smell. The tl;dr goes on to talk about how it may be acceptable to move dates up (often introducing slack), but not to extend the Sprint to accomplish more work. Extending the current Sprint shortens the following Sprint, which is a no-no for multiple reasons, including breaking a predictable cadence for at least two Sprints with potential knock-on effects beyond that. – Todd A. Jacobs Apr 29 at 13:47
  • @ToddA.Jacobs Okay; that makes sense. Thank you. – Sarov Apr 29 at 13:48
  • 2
    @ToddA.Jacobs Hmm. Since I misunderstood before, might be a good idea to answer here, in case someone else has the same misunderstanding? – Sarov Apr 29 at 16:32
1

Sprints are a management tool. As with any tool it can and should be bent to meet the actual demands of the organization. The sprint goal is a forecast, what the team thinks it can deliver within the given time. Typically adjustments are made to scope not the time. The reason for this is that it gives better information for future analysis.

A simple example of when you might want to extend a sprint instead: last sprint of a project (moving it from one stage to another, disbanding or shifting the team) and a story is expected to be incomplete. Normally you would remove it from the current and move it to the next sprint/backlog, but there’s not going to be a next sprint.

Extending the sprint to give it enough time to be done, makes sense in this case.

0

As per the definition, the sprints should be of fixed length. This provides good momentum and adds discipline to the team. The Sprints are at times extended when for a week or few days. If the team is working on tight deadlines and a release is planned with the tasks in the Sprint. Due to some:

  • Technical complexities
  • Scope creep or requirement change
  • Unplanned Holidays in the team

In this scenario, the release is the highest priority and the team has clarity on the stories and the tasks they have to work upon. Since, they were already working on them. In this case, during the Sprint planning meeting, the focus of the team will be on tasks in hand and the not the new stories they have to pick for the upcoming sprint. So, I prefer to extend my sprint by a few days, a max up to a week. If it has to be extended for more than a week I ensure, we plan the next sprint and pull the incomplete tasks in this sprint. The release, in this case, is done in the mid of the sprint.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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