[mdalmijn]

I'm the author of the first book on Sprint Goals (Driving Value with Sprint Goals: Humble Plans, Exceptional Results). I'm not working in game development. However, I do think I can add some insights.

Sprint Planning can be very simple. I've literally started a Sprint with just a goal and a Spike. You can also work entirely pull-based (https://mdalmijn.com/p/are-you-practicing-anaconda-or-hummin...).

The Sprint is supposed to be wholly flexible. The way I describe it, it should be like a pendulum that swings by and you check the progress you've made. That's it.

Yes, it's all achievable without Sprints. The biggest difference is that the Sprint provides intent: what are we trying to achieve, and why does it matter? You could also do that with Kanban together with a goal. If you can't or don't want to set a single objective for two weeks, then you should do Kanban and not Scrum.

"Most benefits attributed to sprints could be addressed through strict WIP limits." -> No. The only difference is that you set an objective. You can use WIP limits and Sprints together.

" If sprints offer any advantages, they aren't for the developers. I've seldom encountered developers who genuinely enjoy sprints or would miss them in a sprint-less model." -> Most developers don't like Sprints because they turn into a push-based batch process, where the goal is to complete all tickets in a Sprint. This usually means you actually complete less work than when you'd use Kanban.

The key to make Sprints work: * Use pull-based approach compatible with WIP limits. As I call it, Hummingbird-style Scrum. * Set a single Sprint Goal. When your estimates turn out to be wrong, which they always will, you know what matters most and you can apply focus on the primary objective.

That's it.