Myth 10 – In Scrum, There Is No Planning

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.

Myth: In Scrum, there is no planning

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.

We are aware that this myth has already been addressed quite a few times – most recently by Stephanie Ockerman from Scrum.org. But we feel that it is important enough to address it again in this series.

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 how the Development Team will deliver the work. This plan is usually captured in a decomposition of work for the first days of the Sprint;


• During the Daily Scrum, the Development Team plans work for the next 24 hours. How will they work together towards achieving the Sprint Goal? Who will do what? What issues need to be tackled? The resulting plan is captured in how the team distributes work and collaborates. If a team uses a Scrum or Kanban Board to visualize work, this can be updated during the Daily Scrum to reflect this plan;


• During the Sprint Review, the Scrum Team and invited stakeholders inspect the work that was done during the Sprint. Based on what was learned, the attendees collaboratively decide on the next things that could be done to optimize value (‘What’s Next?’). This plan is then captured in an updated Product Backlog and (possibly) a Sprint Goal as input for the next Sprint Planning;


• During the Sprint Retrospective, the Scrum Team inspects how they worked together as a team. Based on what was learned, the team plans potential improvements in collaboration and product quality and how to implement these improvements. The resulting plan is captured in an updated “Definition of Done” and a limited number of improvements to implement during the next Sprint;


• The Product Owner is responsible for ordering the Product Backlog in a way that it optimizes the value it generates for stakeholders. This can be done in a myriad of ways and is done throughout the development of the product. The resulting plan is captured in how work is ordered on the Product Backlog;


• The Scrum Master serves the organization by planning Scrum implementations within the organization. This is not solely the responsibility of the Scrum Master; he or she works with other Scrum Masters, Product Owners, and others to make this happen;


• The Development Team plans on how to best deliver high quality, working software. They do so by considering technology, infrastructure, architecture, design, performance, and usability. This necessarily requires a team to anticipate on a likely (near) future, given their experience and what they know at this moment. The resulting plan is captured in suggested work for the Product Backlog, work on the Sprint Backlog and the Definition of Done;

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 endeavour. 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;


• Product development is a very complex, highly unpredictable endeavor. This means that a lot of planning is required, as our plans change continuously. Scrum Events may feel wasteful to some, but they are the minimal moments where this planning takes place;

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 unable to deliver working software to production (at least) every Sprint, or if this is not desired for other reasons, the Product Owner will need a roadmap or release plan that gives stakeholders a sense of what to expect at what point in times. 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 Sprint Goals for upcoming Sprints. 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.

Tips

• 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;


• Although it is merely a tool, we are fans of Roman Pichler’s “Product Vision Board” as a simple way to capture the product vision. We like to fill in the canvas with the entire Scrum Team (often also with stakeholders present);


• When working with departments or teams that require plans, e.g. a marketing plan or a testing plan, don’t reject them out of hand. Help them understand that product development is highly unpredictable, and work together to find the simplest way to plan ahead;

Closing

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?

Co-written by Christiaan Verwijs & Barry Overeem. Visuals are by Thea Schukken.

Source: B2C