Is there planning in Scrum?

Question

As a project manager/scrum master, I has been required to make sure that the team completes the work that was planned for a Sprint and, what is more important, for a Release. Are these demands correct?

It's often said that Scrum has three horizons of planning:

1. Daily planning
2. Sprint planning
3. Release planning

But is it really planning, and not just forecasting? Does Scrum do planning at all?

(Difference between planning and forecasting: planning is usually associated with commintment to the plan. Also looking up a dictionary gives: plan is "a detailed proposal for doing or achieving something". Planning in the sense of project management usually means a detailed plan and schedule, which can be followed and adhered to.)

Answer 1

TL;DR

Scrum is an empirical control process, and therefore "big, upfront planning" is intrinsically an anti-pattern. But Scrum certainly includes a lot of iterative and just-in-time planning, along with a predictable cadence and a set of inspect-and-adapt events when the framework is properly applied.

Scrum Uses Iterative, Just-in-Time Planning

Neither a "forecast" nor a "commitment" provides you with a money-back guarantee. In either case, it's an educated guess as to what is likely to be accomplished during an iteration.

With the 2020 Scrum Guide, the word "commitment" has made a return, but it still doesn't say what you may think it does. For example, regarding forecasting (emphasis mine):

Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these [forecasting practices] do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.

The new guide also contains several types of explicit commitments, including Product Goals, Sprint Goals, and Definition of Done. The commitment to the Sprint Goals says in part (again, emphasis mine):

The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives

In other words, the Scrum Team Developers commit to working towards the Sprint Goal. While doing so, the whole Scrum Team keeps the Product Goal, Sprint Goal, and Definition of Done in mind in the way they attempt to produce the Increment.

Commitments Are Objectives, Not Money-Back Guarantees

None of the foregoing adds up to traditional accountability (pronounced "blame") in the way it's meant under Theory X management. The various Scrum Team commitments aren't money-back guarantees that the Increment will be finished with an implied "or else!", or that the completed Increment is guaranteed to be fit-for-purpose. Instead, it's a commitment to include the various framework goals and artifacts in mind throughout the development process. This doesn't guarantee a successful outcome; it simply guarantees that the iterative, just-in-time planning processes that Scrum's empirical control framework embodies contains measurable goals against which progress (or lack of same) can be measured, evaluated, and acted upon.

Answer 2

Does Scrum do planning at all?

Of course it does. Just because you don't have a stage called "Planning" like in sequential development methodologies like Waterfall for example, doesn't mean there is no planning. Planning just happens throughout the entire life of the product.

When you do backlog refinement, there is planning. When you start a sprint, there is planning. Every they with the daily standup and after it, using fresh information, the team plans how to organize their work to meet the goal.

But is it really planning, and not just forecasting?

[...] to make sure that the team completes the work that was planned for a Sprint and, what is more important, for a Release.

I think there is a confusion here. Are you asking about "commitment"?

There was a change in the Scrum Guide that dealt with this exact issue: Commitment vs. Forecast: A Subtle But Important Change to Scrum. Just because you make a plan, doesn't mean things will happen as planned. We know this from every day life, not just form managing projects.

Agile is about collaboration between everyone involved in building the product, planning things out and adapting to changes in the plan together as work progresses and new/better information becomes available. It's not about management forcing the Scrum team to deliver exactly what was planned at the beginning of the product, release, or sprint. The purpose is to build the right product which sometimes means to ignore the plan you made at the beginning of the project or release when your plan was most likely built on some assumptions.

Answer 3

Of course your team can commit to a plan when doing Scrum. Nothing about Scrum stops you planning for the longer term, in fact the iterative approach arguably makes longer term planning much easier. What Scrum definitely does however, is encourage the team to focus on the current sprint's priorities and allow them to respond to events as and when the plan changes. Longer term plans are often subject to change for sensible reasons that have nothing to do with the team's commitment or ability. That's why it can be better to view plans as a forecast rather than a commitment.