Myth: In Scrum, there is no planning

Christiaan Verwijs
Jan 2, 2018 · 9 min read

Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology. Instead, Scrum provides the minimal boundaries within which teams can self-organize to solve a complex problem using an empirical approach. This simplicity is its greatest strength, but also the source of many misinterpretations and myths surrounding Scrum. In this series of posts we — your ‘mythbusters’ Christiaan Verwijs & Barry Overeem — will address the most common myths and misunderstandings. The great visuals are by Thea Schukken. Check out the previous episodes here.

If you prefer, you can also listen to us reading this post.

Today we bust one of the more radical myths in Scrum; the belief that plans and planning have no place in Scrum. This myth surfaces in many different ways. One example is a Scrum Team that developed a strong aversion to the words ‘plan’ and ‘planning’, proudly proclaiming that ‘we don’t create plans in Scrum’. Another example is a Scrum Master that refused to have the Scrum Team even consider what might happen in upcoming Sprints. Yet another example is the belief that Scrum Teams aimlessly build products without having an overarching goal or sense of direction. In a more subtle way, the myth also surfaces when Scrum Teams work with more traditional teams or departments that require “plans”. Simply stating that “we don’t use plans in Scrum” is not helpful.

Busting the Myth

The Scrum Guide makes 19 mentions of the word ‘Planning’. ‘Plan’ occurs 9 times. None of these occurrences are in the form of a thou-shalt-not. In fact, a simple reading of the Scrum Guide makes it quite clear that there is a lot of planning going on in Scrum, and that there are quite a few plans generated along the way:

  • During the Sprint Planning, the Scrum Team collaboratively plans the work that will be performed in the Sprint. The resulting plan is captured in a flexible Sprint Backlog and an overarching Sprint Goal that provides focus and direction. Next to the selection of what needs to be done, another topic of the Sprint Planning is howthe Development Team will deliver the work. This plan is usually captured in a decomposition of work for the first days of the Sprint;

This rather lengthy list of examples of planning in Scrum underscores a number of takeaways:

  • In Scrum, planning is clearly not the responsibility of a single role. The Product Owner, Scrum Master, and Development Team are all involved in the planning of work. But they do so from different angles. This is why Scrum has no place for project managers. Traditionally, the role of the project manager is to plan work, process, budget, and execution. Instead, Scrum acknowledges that product development is a very complex endeavor. Planning needs to be a collaborative effort between everyone involved. Only by tapping into the collective knowledge, expertise and creativity of the people doing the work, will we be able to work effectively;

“Planning needs to be a collaborative effort between everyone involved.”

  • Whenever we talk of plans in Scrum, we talk about plans as “shared understanding”, not as “documents”. The Daily Plan that comes out of the Daily Scrum is not a document, but something that often only exists in the heads of the Development Team. It may be visualized on a Scrum Board if the team so desires, but it is not necessary. The same goes for other plans that we mentioned. The purpose of plans in Scrum is to get everyone on the same page on the best course of action, not downloading and sharing that knowledge in the form of a document that can be passed around;

“Whenever we talk of plans in Scrum, we talk about plans as ‘shared understanding’, not as ‘documents’.”

  • Scrum Teams actively look ahead. Although they do so with full awareness that (even the near) future is very difficult to predict, they work together to anticipate what might happen. But the detail of plans they create, and the time they spend on planning, will rapidly decrease as the window moves further into the future;

“Scrum Events are the minimal moments where planning takes place.”

Product Planning in Scrum

A corollary of the myth we’re busting today is that Scrum is more of a ‘happy-go-lucky way’ of building products, without a clear sense of direction or an overarching plan. This equates Scrum to going on a hike while only looking down at what’s right in front of your feet, causing you to get lost in the woods, walk in circles or stumble into a hungry bear.

Scrum is a simple, yet sufficient framework for complex product delivery. It describes only the minimal boundaries. Although Scrum does not describe how product planning should be done in detail — other than expressing it in an ordered Product Backlog — this does not mean that there is no product planning in Scrum.

A Product Owner that is setting up and ordering a Product Backlog, does well to take a broad perspective. Products are never built in isolation. The first considerations come from the company vision and the business strategy. They will inform the Product Owner of what kind of product is needed, what features need to be a part of it and how it will generate value for the organization (the product vision). Because we don’t deliver the product in one go, the Product Owner needs to think about a product strategy; in what (rough) order should features be delivered to stakeholders to generate value as soon as possible and to learn? If a Scrum Team is not releasing their increments every Sprint, the Product Owner will need a roadmap or release plan that gives stakeholders a sense of what to expect at what points in time. Using all of the above, the Product Owner orders the Product Backlog and identifies objectives for upcoming Sprints in a manner that optimizes values. The ordering and the content of the Product Backlog are the result of product planning and this is an ongoing activity that continues as long as the product is being developed.

Let us emphasize again that we are not talking about (hefty) documents when we talk about plans like product strategies, roadmaps or release plans. Most of the Scrum Teams we work with have release plans that consist of a couple dozen stickies on a wall. The same goes for product visions, roadmaps, and product strategies. Often, a good roadmap is no more than a sequence of objectives for upcoming Sprints. In a very real sense, the roadmap is the Product Backlog on its side. In the complex environment of product development, where change is continuous, detailed plans are a form of waste. So we should spend as little time on them as necessary.

“In the complex environment of product development, where change is continuous, detailed plans are a form of waste.”


  • Don’t skip the second topic of the Sprint Planning, the ‘How’. This is where the Development Team creates a plan for how they will deliver the work selected in the Sprint Backlog. We generally find it helpful to ask Development Teams to decompose work for the upcoming days into more fine-grained tasks;


In this post, we busted the myth that there is no planning, and there are no plans, in Scrum. As it turns out, there is a lot of planning going on. The various Scrum Events also generate quite a number of plans, expressed through (amongst others) the Product Backlog, the Sprint Backlog and the Definition of Done. The plans we create in Scrum are different from what we traditionally understand as plans; hefty documents that provide detailed, step-by-step descriptions of what is needed. Instead, the focus is on planning as an activity to create a shared understanding of what to do next.

Although it is sometimes said that “planning is useful, plans are not”. We feel that this reinforces the myth by underscoring that plans are always bad. In this post, we showed that plans are useful, as long as they respect the complexity and unpredictability of product development. A more accurate statement would be:

“Planning is useful. Plans are helpful. Detailed plans are a waste of time.”

What do you think about this myth? Do you agree? What are your lessons learned?

Want to separate Scrum from the myths? Join our Professional Scrum Master & Professional Scrum Master II courses or the Scrum Mythbusters workshop. We guarantee a unique, eye-opening experience that is 100% free of PowerPoint, highly interactive and serious-but-fun. Or check out the previous episodes here.

You can support us by purchasing from our webshop, by joining one of our events or by becoming a patreon.

The Liberators

The Liberators: Unleashing Organisational Superpowers

Christiaan Verwijs

Written by

I aim to liberate teams & organizations from de-humanizing and ineffective ways of organizing work. Professional Scrum Trainer & Steward @

The Liberators

The Liberators: Unleashing Organisational Superpowers

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade