Kanban Guide for Scrum Teams - Sprint Planning Question

Why plan a sprint when the work is unknown?

Think of it the other way round. Why plan a Sprint if the work is known? You wouldn't then need a Sprint with a Sprint Goal to aim for: you'd just do the work.

A Sprint Goal can be any coherence which gives the Developers a reason to work together at all, rather than on separate initiatives. It could be a feature, or a commitment based on predictability and flow. Everything else in the Sprint Backlog is a forecast of the work currently planned to achieve the Goal.

Planning would still valuable. It provides an opportunity to discuss and evaluate issues, identify potential testing enhancements, and refine support tasks. In short, planning helps bring clarity to incoming work.

Planning also fosters teamwork, ensuring the team works collaboratively rather than individuals tackling PBIs in isolation.

For the sprint goal, keep it "high level"—for example, improve user experience, complete customer ABC’s upgrade, or enhance the stability of the calculation engine. The goal should focus on broader outcomes rather than individual PBIs.

That said, every team should use the method that works best for them. However, avoiding planning simply because PBIs are unrefined and arrive randomly is actually an argument for planning—to bring structure and understanding to the work—rather than a reason to abandon it altogether.

Always just an opinion.

The Kanban Guide for Scrum Teams isn't sometrhing that is designed to help teams if their PBIs "arrive randomly and are unplanned". On the contrary, the Kanban Guide for Scrum Teams "does not replace or discount any part of The Scrum Guide. It is designed to enhance and expand the practices of Scrum." That is, there is still an expectation of an ordered and refined Product Backlog where Product Backlog Items are ready for selection at a Sprint Planning after they have been refined enough for the team to assert that they can be Done within one Sprint. It is also designed to have a Product Goal and a Sprint Planning to craft a Sprint Goal and select Product Backlog Items to move the product closer to the Product Goal. The Kanban Guide adds additional structures - flow metrics, four Kanban practices, and techniques for using these metrics and practices to improve the existing Scrum events.

If work is so unknown that you can't maintain a Product Backlog and a Product Goal and plan Sprints with a Sprint Goal, then Scrum, with or without the additions of the Kanban Guide for Scrum Teams, probably isn't a good fit for your context. And in a case like this, perhaps something closer to a continuous flow model would work. There are teams out there, especially those that are interrupt-driven, where maintaining a Product Backlog, a Product Goal, and planning Sprints isn't a good fit. However, once you stop dropping or changing the key elements of Scrum, avoid calling your approach "Scrum".

That’s a valid concern, and many teams struggle with planning sprints when work is largely unknown or unpredictable.Even if the work is unknown, you can set a sprint goal based on discovery.

If your work is so unpredictable that sprint planning seems pointless, you might consider:

• Kanban instead of Scrum: If work is highly reactive, moving to a continuous flow model might be better.
• Spike sprints: If unknowns are frequent, running dedicated "spike sprints" (focused on research/discovery) before committing to actual development can help.

There are some great answers above, but I wanted to chime in. You may want to check out complexity models aligning with decision-making, such as Cynefin or Ralph Stacey. Scrum thrives in the realm of complexity, where more is unknown than known. Where absolutely nothing is known is chaos and disorder, and as others have stated, Scrum might not be the best tool.

Everything in Scrum can be traced back to one concept: empiricism. Decisions are based on facts and validated learning. Nothing is assumed to be valid until proven otherwise. Every Sprint can be used as a short feedback loop—the shorter, the better. Scrum is best used for product discovery, not for feature factory work where unrelated issues roll into the queue.