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.

Sarov
  • 14,768
  • 5
  • 33
  • 62
  • 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 '19 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 '19 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 '19 at 13:47
  • @ToddA.Jacobs Okay; that makes sense. Thank you. – Sarov Apr 29 '19 at 13:48
  • It seems like this question is resolving itself as a non-question. However, there is one case I can think of that isn't a serious antipattern: large holidays. For example, if the end of the sprint were fall over the christmas/new years period and no one was in the office, we might end the sprint on that last day most people are there (which may be early) and then start the new sprint when everyone comes back. This is technically a violation of scrum rules, but the mess caused by trying to follow the rules in these cases is more problematic than the small impact of not following the rules. – Daniel Apr 29 '19 at 14:52
  • @Daniel In which case, you'd have two shortened Sprints, not one or two extended ones. :) I think you're describing a good example, but not one of extending a Sprint, which is what the question was addressing. That use case would look more like pushing the Sprint Review and Retro out past the current Sprint, and picking it up after the holidays before starting a shortened Sprint. I can't imagine an example of that being better than moving the events up, and plenty of reasons why that would interrupt flow/cadence. Hence my position that it's an anti-pattern. – Todd A. Jacobs Apr 29 '19 at 16:27
  • @Sarov I think this is a useful question. If you don't think it's answered sufficiently in the other answer, I can see value in answering it here as an X/Y or "false premise" type of answer. I just don't want to do that if you're going to delete the question. :) – Todd A. Jacobs Apr 29 '19 at 16:30
  • 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 '19 at 16:32
  • @Todd Yup. I missed the word "extended". I guess I read through the question too fast. – Daniel Apr 30 '19 at 02:46

2 Answers2

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.

jmoreno
  • 189
  • 5
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.

Anurudh Singh
  • 374
  • 1
  • 3
  • 9