A company builds a home robot with firmware, an app, and injection-molded housings. As the company adds a second Scrum Team, leadership debates whether Sprints should be longer to match the slower cadence of hardware certification cycles. What does the Scrum Guide say about choosing a Sprint length in this situation?

The Scrum Guide sets a one-month maximum for a Sprint and frames the purpose of that cap as limiting risk to a calendar month, while leaving the actual chosen length to the Scrum Team based on what lets them inspect and adapt often enough. A hardware certification cycle running longer than a Sprint doesn't change that guidance; it just means a certification-dependent Product Backlog item may span multiple Sprints before it can be called Done, which is a normal outcome the Definition of Done and forecasting handle, not a reason to lengthen the Sprint itself. Matching Sprint length to the certification cycle conflates the cadence of inspection with the cadence of one specific dependency, and would slow feedback for every other kind of work the team does. Mandating identical lengths across teams the moment a second team forms invents a rule; the Guide does encourage aligning Sprint length across teams sharing a Product Backlog to simplify coordination, but that's a practical scaling consideration, not a mandate the Guide states. Letting the Product Owner set length unilaterally around a launch date misassigns a decision the whole Scrum Team makes together. Caveat: aligning cadence across teams is a common and sensible scaling practice, but it is not one the Guide requires. Operational check: when planning a new team's cadence, ask whether the proposed length still allows inspecting the Product Backlog and the Increment at least monthly, not whether it matches any one supplier's calendar.