A recurring Scrum myth I see in my training and coaching is that there is no planning in Scrum. Unfortunately, this myth can lead to two negative consequences.
-
The people in organizations responsible for budgets, product management, sales, and marketing may be unwilling to try Scrum.
-
Scrum Teams may not be effective in their use of Scrum.
The reality is we plan A LOT in Scrum.
We just plan differently to optimize effectiveness.
In Scrum, we emphasize the activity of planning over the plan itself.
We know the plan is going to change. And this mindset honors the agile value of adapting to change over following a plan.
In Scrum, the activity of planning is collaborative.
The Sprint starts with Sprint Planning, and the entire Scrum Team participates. This is a collaborative negotiation to determine a valuable outcome the team wants to achieve. The Development Team creates the Sprint Backlog, identifying what will be delivered and a loose plan for meeting that valuable outcome.
The Daily Scrum is a collaborative planning session for the Development Team to inspect progress and adapt the plan to meet the Sprint Goal.
The Sprint Review is a collaborative session to gather input needed to help plan the next Sprint.
The Sprint Retrospective is a collaborative session to enable and plan for continuous improvement.
In Scrum, the people doing the work own the plan.
The Development Team owns the Sprint Backlog. They create it, and they can adapt it. This ownership means the plan will reflect the current reality, incorporating input from the most knowledgeable people. For release-level planning or forecasting, the entire Scrum Team owns this. It requires a collaboration because of the distinct accountabilities of the Scrum Roles.
Planning in Scrum is part of every Event.
In every Event, we are both inspecting and adapting. That is the essence of planning. If we don’t see the adaptation happen during a Scrum Event, it is time to revisit the Scrum Team’s understanding of the purpose of the Events.
Furthermore, the Scrum Framework is just a framework. It encourages Scrum Teams to apply complementary practices where relevant to further assist with planning, including release planning and product backlog refinement techniques. Development Team members choose how to do their work, and they may have planning discussions throughout the Sprint.
In Scrum, the way planning is done reduces waste.
A plan is out of date a minute after you discuss it. Therefore, we keep the plan lightweight and make it easy to update the plan. Some ways that we reduce waste related to planning include:
-
We minimize time spent analyzing things that may never happen. The further something is in the future or down the ordered list of priorities, the less time we spend trying to gather details.
-
We minimize time spent analyzing to an impossible level of accuracy. There is a point where our gains in accuracy no longer outweigh the time spent to get there. We accept that the complexity and unpredictable nature of software development make it impossible to have a perfect plan.
-
We incorporate meaningful feedback every time we plan. By doing the work, by building software, we learn the most valuable information for helping us adapt our plans.
In Scrum, we still recognize the inherent unpredictability in complex software development.
By being honest about this, we can be transparent about the current progress and likely completion dates. This helps us build trust. This enables us use an empirical process to enable business agility, to make difficult decisions, and to do professional work.
In summary, planning effectively is an essential part of Scrum. I have experience working as both a Project Management Professional (PMP) in the traditional delivery environment as well as working as a Professional Scrum Master (PSM) and Coach in an agile delivery environment. I argue that when we do Scrum well, planning in Scrum is more effective.