Can sprints's lenght vary in the same product backlog construction?

Mael,

While the guide states that sprint length should not exceed one month, the widely accepted standard around sprint lengths is in weekly increments, not in day increments. Teams usually work in 1, 2, 3, or 4-week sprints. This helps to create a rhythm from sprint to sprint (similar times/days for sprint ceremonies) and dramatically reduces variability. A common custom is to also schedule a mid-week beginning/end of sprint, to accommodate typical holidays that occur on Mondays or Fridays, and again reduce variability around rescheduling.

Your question is basically asking whether variability in sprint length is a good practice, which it unfortunately isn't. That doesn't mean you are "stuck" with your initial sprint length, but you should have very sound reasons for wanting to either shorten or lengthen the sprint duration.

Why did you initially select a 30-day (4-week) sprint length, and why do you want to now reduce it to a 15-day (2-week) sprint?

I would say once should put serious considerations and account all parameters while deciding the length of the sprint and it should remain intact during the scrum cycle for that product.

A number of factors need to be considered before deciding on a sprint's length. Its definitely no advisable to change the duration sprint to sprint but, for a new team, I would recommend running 2-3 sprints with a length that the team considers right initially and validate. If the team think the length is not optimal, please feel free to adjust and try that out. You may not have to adjust more than once to find the right duration.

> Do you think that is possible that the scrum team can have
> a new agreement so the next sprint has 15 days

It's possible, but it isn't necessarily a good idea. It's generally better to improve the Definition of Done, so better quality is delivered, than it is to reduce a timebox and observe a lesser standard.

Hi folks!

Thanks for your replies. All the answers were very useful to our team. We are just adopting scrum, and this point came up in a meeting. We were worried about not do anything that could put scrum framework adoption in risk in our company.

Thanks all of you once more,
Bests.

There are many reasons for consistency in the time box for Sprints. Some have already been mentioned and there are a few others that come to mind. Remember that Scrum is founded on empirical process control theory. Changing the Sprint time box means adding a variable which affects predictability. If the results of changing the length are not what is expected, then determining correlation versus causality is more complex.