At the very start of a new robotics product line, leadership wants every architectural decision for the next two years of hardware and software locked in during a single upfront planning phase before any Sprint begins, and a Scrum Master is asked whether this fits how Scrum expects design to work, so what is the accurate answer?

Scrum is built around empiricism, which assumes that not everything worth knowing can be known in advance — some of the most important information about what will and won't work only becomes clear once the Scrum Team starts building, testing, and getting feedback from real Increments. Architecture and design are explicitly expected to be emergent under this model: early decisions provide a starting direction, but they are expected to evolve as Sprints reveal constraints, opportunities, and mistakes that could not have been predicted with confidence at the outset. Locking two years of architecture in before any Sprint begins assumes a level of certainty that is rarely available this early, especially for a product spanning hardware and software, where physical constraints and integration realities are often only discovered through actual attempts to build and combine the pieces. Splitting the answer by hardware versus software, or reframing the objection around Sprint length rather than the planning approach itself, both miss the core issue, which is whether the design is allowed to keep changing as new information arrives, regardless of which component or how long the exercise takes. Some early architectural thinking is reasonable and often necessary, but treating it as permanently fixed removes the team's ability to adapt when reality disagrees with the original plan. A practical check after several Sprints is to compare the current architecture against the original two-year plan — meaningful drift is evidence the process is working as intended, not a sign that something went wrong.