Duration of Sprint

Don't you think that the optimum length of a Sprint should also take into account technical constraints visible to the Development Team? Also, might consistency in Sprint length be useful? 

The Scrum Guide says:

Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.

So given that Sprint Planning takes place after the Sprint has begun, when might be an appropriate time to decide on a change, if you find your Sprint length isn't sufficient?

Hi,

Thanks for your feedback, it is more clear now !

Best Regards

So given that Sprint Planning takes place after the Sprint has begun, when might be an appropriate time to decide on a change, if you find your Sprint length isn't sufficient?

I'd look at this the other way around. First define your time box, then identify what can be done within that time box. Sprint planning allows the team to discuss what is possible within that time and how to bundle that up into a common goal.

The complexity comes from things like technical constraints. As an extreme case, if I know it will take at least a day to create a releasable product, then a 1 day sprint would be a mistake.

Also, you'll want to ensure that you have enough time to successfully meet a goal that adds value. To do this I'd want sprints long enough that we can complete multiple PBIs and still have some slack.

All of this means that soliciting input from the entire scrum team to adds a lot of value, even if your time box is defined before the actually planning starts. If the time box needs to be adjusted, I'd usually do that as an action item from the retrospective.

Hi, 

I have a query here. "Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened". On other hand we read  "A new Sprint starts immediately after the conclusion of the previous sprint. What if in the previous sprint all tasks finish before time. in this scenario, Does that particular development team wait or they can add additional tasks to it after consulting the product owner since adding tasks will impact 1) prioritized product backlog & 2) sprint goal which can not change during a particular sprint. 

They can do whatever they want or think best with the remaining time, as long as the Sprint Goal has been met and will not be subsequently compromised.