La risposta citata dalla Guida Scrum (non più di un mese di calendario) potrebbe non essere sufficiente.
La vera risposta è: dipende...
Prima di tutto devi considerare la capacità di pianificazione della tua organizzazione - orizzonte di pianificazione.
Per esempio, se avete Sprint di 2 settimane, sarebbe bene che l'orizzonte di pianificazione della vostra organizzazione sia da qualche parte intorno alle 4 settimane.
Quello che voglio dire è che se qualche nuova idea nasce durante il primo Sprint e non è così urgente da dover cancellare lo Sprint (il vostro attuale obiettivo Sprint è diventato irrilevante) allora fate la domanda se la vostra organizzazione è in grado di aspettare fino a 4 settimane -1 giorno (assumendo, quell'idea nata nel primo giorno del primo Sprint) con la ricezione di questa caratteristica fatta? Se va bene e non dovete cambiare l'obiettivo dello Sprint al momento, allora due settimane di Sprint dovrebbero essere sufficienti. Naturalmente ci potrebbero essere delle eccezioni una volta ogni pochi Sprint quando i cambiamenti sono veramente urgenti e bisogna ripianificare il lavoro - ma le eccezioni non dovrebbero accadere in ogni Sprint. Se non va bene allora provate uno Sprint di una settimana.
Scrum favorisce un ritmo sostenibile. Stiamo prendendo una parte del caotico ambiente di sviluppo di un progetto/prodotto e lo mettiamo in una scatola magica e pacifica chiamata Sprint dove lo scopo potrebbe cambiare ma l'obiettivo principale dovrebbe rimanere lo stesso.
Quindi scegliendo la lunghezza dello Sprint prova a pensare a quanto è brava la tua organizzazione nella pianificazione. Non significa che non dovreste allenare/insegnare alla vostra organizzazione a pianificare meglio se stanno cambiando tutto in continuazione. Significa solo che dovreste considerarlo prima di iniziare a fare qualcosa che sarà inaccettabile per la vostra organizzazione e risulterà nel rifiuto di Scrum prima ancora che inizi a funzionare davvero.
A Pragmatic Coders di solito lavoriamo in iterazioni di 2 settimane, ma in alcuni progetti non usiamo affatto Scrum. Kanban con WIP limitato funziona meglio in alcuni casi.