Sprint Length - Question from Scrum Open Assessment

A business event can be any discrete point at which resources outside the team are necessary to inspect and adapt progress. Such events can be market-driven (e.g. analysis of survey feedback), enterprise-driven (e.g. strategic planning), or technical (e.g. integration with the work of other teams).

Thank you Ian! May I ask the source of this information? Sounds like I need to go through it.

Have you taken the PSPO open assessment? I think it would be beneficial to do so. It helped me a lot in prepping for the PSM1 because it goes over a bit more of the planning and forecasting; which would help with this question. 

The method I used for questions with answer selections that were not 100% clear was to eliminate the answer choices that are absolutely wrong. Then compare the remaining answers and select the one that would best fit within the framework of Scrum.

May I ask the source of this information? Sounds like I need to go through it.

I'd struggle to give you another source. This is just how I explain "business event" when going through the open assessment with students in class. The term itself is not defined in Scrum. However you might want to go through Chapter 15 of Mike Cohn's "Agile Estimating and Planning" on iteration length, managing uncertainty, and outside feedback. Also review the Nexus Guide regarding integration dependencies between teams.

My advice is to note the wording "synchronize the development work with other business events". A business event in the context of choosing sprint length ought to be understood broadly so dependencies are accommodated.

My problem with the "... synchronize with other business events." option is that these will most likely have unpredictable, and so undefinable, dates, times and recurrences. As a sprint HAS to has to be of a set and consistent length, adding an unpredictable or guesstimated element to its definition seems to go against the principles of Agile and Scrum. I've been interpreting the Scrum process as being based on feeding back what you already know, and what you learn in an iteration/sprint, back into the process for the next sprint. So I could not see how guesses about unknowable possible future events could play a part in it.

I will seek out "Agile Estimating and Planning" Chapter 15, and the Nexus Guide to discover how this element can be successfully incorporated.

The Scrum Guide describes elements that should be included in the Sprint Review.

The final two might give clues as to how often it makes sense to have a Sprint Review, and so could help in deciding Sprint length.

As a sprint HAS to has to be of a set and consistent length, adding an unpredictable or guesstimated element to its definition seems to go against the principles of Agile and Scrum.

The greater the uncertainty you have to deal with, the shorter inspect-and-adapt cycles may need to be. The sampling rate ought to be sufficient to establish empirical control of the process.

Thanks for the replies Simon and Ian.

I think I see what you are both saying here. Scrum being fundamentally empirical means that the Product Owner can use the knowledge gained from previous projects' Sprint Reviews to fairly accurately define a Sprint time-box that will "synchronize with other business events" going forward.

Is that a reasonable interpretation of what you have written?