As per title, who is in charge of the decision?
I am tempted to say that the dev team should chose it, but then again there are considerations about stakeholders to be made and management in general (how long can they go without changing their mind, how dynamic is the market etc.)
Therefore I would say the PO should also have a role in deciding how long the sprint should last.
What do you think?
The Scrum team decides the length of the Sprint (dev team + PO + SM). They do the actual work, so they choose the duration of the time-box they feel more comfortable with in order to produce a product increment.
With that being said, there are of course all sorts of other things happening in the company that may influence what decision the Scrum team makes. You mention some of them in your question. If that happens, the team can always change the sprint duration. You don't need to keep the same length all throughout the project. You start with whatever works for you, then inspect and adapt.
Maybe you start with two weeks but stakeholders might want to have a shorter feedback loop, so you switch to one week sprints. Or maybe you work in some complex domain and the PO might want to have more "meaty" increments, so maybe they suggest three week or four week sprints. But then maybe you see that a greater iteration length introduces too much risks or assumptions, so you go back to something shorter.
It's a good idea to retain a constant sprint length throughout the development of your product (helps with planning, forecasting, etc), but if you realize that a different length would be more beneficial (for whatever reasons) you can switch. You are not stuck with one sprint length forever.
The entire Scrum Team collectively decides the optimum length for their Sprints. No one outside the Scrum Team should be defining the Sprint length, although they may certainly have an impact on defining success metrics that influence the team's decisions.
Deciding on an optimal Sprint length rests on a number of factors:
Framework requirements.
The Scrum Guide says that a Sprint may not be longer than one calendar month. That's the upper bound. The lower bound is selectable, and will depend on other factors.
Typical size of Product Backlog Items (e.g. user stories).
Each item that is ready for Sprint Planning must be sized to fit within a single Sprint. Smaller stories are more agile, but smaller stories may not accomplish as much. It's usually best to right-size the story size to fit the Sprint and optimize for INVEST criteria.
Backlog item complexity.
While complex work can benefit from shorter inspect-and-adapt cycles, it's also true that some complex work simply won't fit into very small time boxes. You need to right-size your story size and Sprint length to accommodate the optimum level of decomposability, interdependencies, and delivery time to meet your typical Sprint Goal each Sprint.
Sustainable cadence.
The Scrum implementation (especially the cadence of its events) should be predictable for the team and its customers/stakehodlers. The cadence must also be sustainable for the full life of the project. It's important to pick a Sprint length that will work indefinitely and that won't require constant rejiggering to meet changing requirements.
Stakeholder availability.
One-week Sprints place a lot of demands on stakeholders to feed the Product Backlog and attend Sprint Reviews. The Scrum Team members are also stakeholders, and very short iterations don't allow much flexibility for sick days, family emergencies, or organizational demands outside of the product development cycle.
Optimum feedback cycles.
Shorter Sprints provide more inspect-and-adapt opportunities in a given period of time. However, that comes at the cost of an increased frequency for Scrum events, and thus more framework overhead.
Generally speaking, shorter projects require shorter iterations because the project needs faster inspect-and-adapt cycles. For example, a three-month project with only three Sprints is unlikely to provide sufficient empirical control or process-improvement opportunities.
On the other hand, shorter iterations create more process overhead and reduce the amount of work that can be accepted into each Sprint. It's very much a trade-off, and the whole team needs to weight the pros and cons based on the product schedule and complexity.
Industry practice is 2 week long sprints. However, you can change it by consensus. Sprint Retrospective is an opportunity to inspect and adapt. It is meant to bring up issues faced by the team and look for ways to improve.
However, here are some key points to keep in mind regarding sprint length:
Most importantly, when you change the sprint length, team rhythm will be impacted and you will have to develop new metrics all over again. So, change if there are overwhelming reasons and there is team consensus.
