* The appropriate sprint-length must be found, there is a lower-bound by how long you need for developing something with user-value (i.e. demoable), and upper bound the tolerance of your customer (or sales organisation) to wait until requested features will be implemented. Most scrum teams seem to use 2 week sprints which is typically too short unless you are developing simple products like CRUD applications potentially. * If we take 1 sprint-length (1 SL) as a basic time unit, then you need to realise that a new, highest-priority feature will on average take 1.5 SLs to delivery if it really is Priority 1. * teams must really be 90% self-reliant to do everything needed in the sprint. Once you have need to synchronise development across scrum-teams, you loose. basically now value delivery can easily take 2-3 SL OR needs to be carefully planned / aligned for the same sprint ahead of time so you get at a lower-boundary of 2-2.5 SL (> 1.5 SL) for work involving more than one team, easily exploding to 3-4 SLs. deve With these considerations, we quickly get into longer-ranges of planning, especially if you are in a multiple-team kind of situation, that you get easily into when you (a) don't have a dev team deploying to the cloud (b) are developing more-complex software systems with multiple components / services developed by several teams.
The elephant in the room of course is that all of this thais not discussed in your Scrum training, because they mostly outline a happy-path for this 8 person team
disclaimer: I prefer Kanban-style sprint-less work mode overall.