Regarding sprint period extension?

When an event's time-box expires, the event is over. The Sprint is an event that does not get extended. A "done" Increment of product is due by the end of the Sprint. When the 10 days are up, a new Sprint starts.

Scrum Guide: The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

How does keeping to a time-box help a Development Team? And how do consistent durations help them? Why do you think the Scrum Guide prescribes the rules of the game listed above?

In addition to what Chris Belknap said, I'd be curious as to why you think that you need to extend your Sprint. In Scrum, timeboxes are fixed and do not get extended, but something probably happened to trigger the thinking that it should. Understanding what that event or situation was and addressing the root of the problem may be beneficial.

Imagine that I have to extend the timebox for Sprint 1. So do I have to decrease the number of days from the next sprint.

As quoted to above by @thomas & @Chris , sprints are TIME-BOX. Once time-box expires the new sprint begins. Its like a race , if you fail to finish in time , you fail but time is not extended. But this gives the team an opportunity to inspect the failures , learn from it and improve in the next.  

Extending Sprint 1 is wrong on so many levels, many mentioned above. But the one that makes me cringe is that you are on your first Sprint and already wanting to modify Scrum to meet your needs.  Does not bode well for the rest of your journey into Scrum.  

End the Sprint and focus the Retrospective on what work you were able to accomplish and why you weren't able to accomplish what you thought you could.  What did you learn? Just from your question I would suggest you should be able to learn something about how you forecast work and most likely something related to the refinement of the work undertaken. 

I'm going to assume that you are the Scrum Master and suggest that you have an opportunity to learn that you don't do anything related to the work being done but focus on the way the team works together.  If you are the Product Owner, again you do not something like extend a sprint. In fact, no one extends sprints.  However a Product Owner can decide to cancel a sprint if conditions warrant and the Scrum Guide details how to handle that event aht should really be rare. 

I believe you could get much better advice if you were to explain why you felt a sprint needed to be extended.  Many of us can provide input/opinions on why it is a bad idea and what you could focus your team on inspecting due to the situation. 

Imagine that I have to extend the timebox for Sprint 1.

Imagine you didn't do that, because you valued the transparency and discipline that comes from proper time-boxing. What would the impact then be on current organizational practices, and on the perceived need for organizational change?

Imagine that I have to extend the timebox for Sprint 1. 

I echo all of the previous feedback.   Through your question, you stumbled on a treasure trove of valuable insight and advice - congratulations!

I would only add a few more questions in response to your question:

Assuming that you were thinking of extending the sprint duration in order to meet the Sprint Goal and/or complete the sprint forecast, what would you base the new duration on?   If you extended it from 10 days to 12, what data/evidence are you basing the new duration on?   And what would your decision be if for some reason the targeted sprint result was not achieved under the revised duration?   Would you propose extending it again?

Everyone here has provided excellent suggestions - and here are my two cents :)

Consider Sprint is a 100 m race (instead of time-boxed it is distance-boxed). Irrespective of who is running it - we don't alter the length of a sprint to 120 (extend) or 80 (early finish).

If someone doesn't achieve first position or second or third (sprint goal) for that matter - they go back (retrospective), train harder (improvement) and perform again (sprint).

Regards,

Adwait Vaidya.

I read a lot of valuable considerations, and wish do add another perspective.

Structuraly changing the duration of the sprint is something that must be allowed if it is for adaptation purposes, but only in these terms. If the team learns that the characteristic frequency of the dynamic of the service/product it's working on is not compatible with sprint duration, it may try to adapt it. For example if the team is working on a website wich responds to weekly and even daily frequencies, it may discover that monthly sprints are too long for the team to be able to adapt effectively, and may decide to move to shorter sprints. Structurally.

Having put aside the question of structural change, the sprint duration should not even be considered for extension (or compression for that matter).

The sprint's cadence is the space in which the team operates. it's not a constraint or a container. It's like the beating of day and night, the cycle of the seasons.

If you party all night and do not sleep enough, do you extend night? No, you can't!

If you do not harvest before fall, do you extend summer? No!

It's as simple as that.

A sprint is not a short project, the team should not be frustrated* for not achieving goals. The Review is the window to look back at whatever value was realized (increment) and to look at the future, in order to adapt the journey. Feeling not enough value was delivered? The Retro is there for you!

*(just a little bit of sense of urgency to improve maybe)

Best,

Luca