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.)

  • 3
    What's the definition of planning vice the definition of forecasting? I admit that it is subjective, but this feels like an X:Y question where the answer is hidden in the definition of the terms.
    – MCW
    Commented Nov 20, 2020 at 14:48
  • @MarkC.Wallace I'd say that planning is usually associated with commintment to the plan.
    – Daniel
    Commented Nov 20, 2020 at 15:09
  • 2
    Regardless of your framework or methodology, if you've ever achieved 100% adherence to an initial plan you might win a Nobel prize. "No plan survives contact with the enemy!", which in this case is the cone of uncertainty inherent in large or complex projects.
    – Todd A. Jacobs
    Commented Nov 20, 2020 at 15:41
  • 1
    "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" Then none of you, neither you nor the person requiring it, has understood Scrum at all. I suggest starting fresh and reading the guide again.
    – nvoigt
    Commented Nov 21, 2020 at 14:26

3 Answers 3



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.


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.

  • Thank you, @Bodgan. When we talk to a customer and say "planning" this is usually understood as "planning and of course commitment to the plan". Using this understanding can we say that there is no planning in Scrum?
    – Daniel
    Commented Nov 20, 2020 at 15:07
  • 1
    Forget Scrum for one second. Consider work. Do you plan out to do some work today, this week, this sprint, this release, etc, or do you just work on "whatever"? Planning is one thing. Commitment to the plan is another. There is commitment in Scrum: to sprint goals, to the product goal, to the definition of done so that you build a proper increment, etc, but less to the plan. Why? Because reality today tends to contradict your plan from last week. When you insist on respecting the plan you might end up ignoring today's reality. Adapting is far more important than sticking to an obsolete plan.
    – Bogdan
    Commented Nov 20, 2020 at 15:18
  • And to answer the question Using this understanding can we say that there is no planning in Scrum?. No, you cannot. Planning is one thing, sticking to the plan and respecting a commitment to THAT plan is another.
    – Bogdan
    Commented Nov 20, 2020 at 15:20
  • Usually people do very shallow planning of the day work, week work etc. When we talk about planning in the sense of project management we mean a detailed plan, which can be followed and adhered.
    – Daniel
    Commented Nov 20, 2020 at 15:31
  • 1
    Is that shallow planning adequate enough? In other words, does it get the job done? Do you deliver what you wanted to deliver? Did you meet your goals? If yes, then did you really needed more detailed plans? If there are problems, issues, or failures and you think shallow planning is at fault, then yes, you need more careful planning. But working on very detailed plans does not guarantee that things will go according to plan. And when things don't go according to plan, you will realize that spending all that time on planning was a waste. It's a matter of balance: just enough planning.
    – Bogdan
    Commented Nov 20, 2020 at 15:42

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.