“Let’s extend the Sprint until we finish all PBIs”

We are not done, we ‘ll extend the sprint until we are done.

Two days before the end of the Sprint and the Scrum Team (basically the Product Owner and the Dev Team, assuming that your Scrum Master has some idea about the framework and is not a complete imposter) asks for a “Sprint extension” (sic) in order to finish the user stories it committed (sicⁿ) to.

Sounds tempting. Very tempting. Especially if you are new to the Scrum framework and you have only worked with classical software development models so far, such as Waterfall, Do-As-I-Say methodology or Darth Vader process (aka your delay annoys me).

Question: But why is extension a bad idea?

When someone suggests the extension of the Sprint, is like trying to extend the weekend so that you can be ready for Monday’s work. In other not-so-diplomatic words you are just fooling yourself. The Sprint is a time-boxed event within which we are able to inspect and adapt ourselves and provides transparency over the state of the increment. By losing this inspection-adaption-transparency perspective, the Sprint will be turned into a predefined methodology full of “Musts” and “Shoulds”.

22uhwn.jpg

Question: Fine, but scrum emphasizes a product oriented approach, not a process oriented one. So, why should we stick to the process and not adjust it as we see fit?

What you say seems to be right but it is ultimately wrong. By adjusting the Sprint length as you see fit in order to feel less anxious about the Sprint Review you are not only fooling yourself (I need to emphasise the latter) but you also cause some other issues like:

  • You harm the team’s velocity, as we will not be able to measure the team’s ability to turn PBIs into working software within a time-boxed event.
  • As a result, you harm the delivery forecast which I suppose will not result in satisfied customers
  • Furthermore, you make the PBI management harder, because PBIs are usually estimated to be finished within one Sprint. Therefore, by constantly changing the Sprint’s length you jeopardise the empirical spirit of the Scrum team.
  • The team gets accustomed to this bad habit and they lose the “sense-of-urgency” (Oh well, don’t bother too much, the Sprint will be extended)
  • Lastly, the Sprint as we already mentioned is something neutral. A container for all other events. After all, Scrum is a framework and NOT a methodology with deadlines and milestones.

22ujuf.jpg

Question: But if we really need to extend the Sprint?

The Scrum team (PO, SM, Dev team) should decide this. And when is the best time to make such a decision? Correct, the Sprint Retrospective. The decision should be based on the volatility of the market and on the frequency you need to receive customer feedback.

Last but not least: If you think that you will not be able to deliver all PBIs, it is fine as long as you achieve the Sprint Goal. Keep communication between Dev Team and Product Owner always open. Maybe the Product Owner will be able to remove some of the PBIs.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s