Myth or Fact: “There is no Planning in Scrum (or Agile)”
We are launching a new series titled “Myth or Fact”. This is the first post in the series. This series will take up topics we generally hear professionals quoting as a fact.
We will analyse such topics and determine whether the mentioned topic is a myth or a fact.
So stay tuned as we will be discussing all kinds of topics related to Scrum, Agile Frameworks, Scaling Agile, Agile Transformation, Leadership, and everything related to Agile.
Today we will talk about “There is no Planning in Scrum (or Agile)”.
Scrum Teams or people new to Agile get the impression that there is no planning in Agile.
Well, this is a misconception. You must have heard the quote by Dr Eisenhover, “Plans are useless, but planning is indispensable”. This quote summarises the mindset of honouring the Agile value of adapting to change. In other words, we are not married to our plans.
The fact is that we plan a lot in Scrum.
It is just that our approach to planning is different.
We plan to optimise effectiveness. Let me share three points (pieces of evidence) to explain how Scrum deals with the activity of planning.
Point No 1: Every event in Scrum is a collaborative planning session. In the Sprint Planning event, we create our Sprint Backlog, a plan to achieve our Sprint Goal. Daily Scrum is an event to inspect progress and adapt our plan, i.e. Sprint Backlog, to ensure that we are on track to meet the Sprint Goal. Sprint Review allows us to gather feedback to help us plan the next Sprint. Sprint retrospective enables us to plan for continuous improvement.
The best part is all the above events, aka planning sessions, are collaborative as they involve the entire Scrum Team.
Point No 2: Scrum is an open framework. Therefore Scrum allows Scrum Teams to apply complementary practices wherever needed to assist in planning. Scrum Teams are free to include Release Planning and Product Backlog refinement techniques. Ordering the Backlog to deliver the maximum value is another type of planning. We can create a product roadmap from an ordered backlog instantly. But that is the topic for another video.
Point No 3: Scrum allows you to deal with the fact that a plan is out of date in a minute after you discuss it, and this is why Scrum has built-in ways to reduce waste related to planning. For example, it is a common practice to have items at the top of your Product Backlog described in sufficient detail so that the developers can pick them up in the next Sprint and start working on them. At the same time, the item in the middle and lower can stay with high-level details. The reason behind this practice is to stop Scrum Team from spending time analysing things that may never happen.
Another example, for all Scrum events, there is a Timebox. Ever wondered why there is a strict timebox for every event? By working in a complex and unpredictable environment, there comes a time when what you gain in accuracy is far less than the time invested in getting there. Hence Scrum events limit the time we spend analysing and planning.
Bonus Point: There is a reason why most people new to Scrum fall prey to this misunderstanding there is no planning in Scrum. The reason is that when we refer to plans in Scrum, instead of focusing on a “document”, we focus on “shared understanding”. For example, it is pretty standard for teams to have their Sprint Backlog on a Task Board with different colour stickies, but it is not mandatory. The Sprint Backlog can be in any other format as well.
I hope now you understand that not only do we do planning in Scrum, but we also do it in such a way as to reduce wastage.
As they say, Agile is about Individuals and interactions, so please let us know what you feel or think about today’s topic. Please share with us if you have previously heard this myth – “There is no Planning in Scrum (or Agile)”. And if yes, then how do you typically respond to it?
Also, share with us if there are any other myths that you have encountered that you would like us to verify for you.
FAQ
Ans: A Scrum team should conduct a retrospective at the end of each sprint. This allows the team to regularly reflect on their work and identify areas for improvement.
Ans: There are several metrics that can be used to measure continuous improvement in Scrum, including:
- Velocity: The amount of work completed in each sprint. Increasing velocity over time can indicate that the team is improving their efficiency and productivity.
- Defects identified: The number of defects identified in each sprint. Reducing the number of defects can indicate that the team is improving the quality of their work.
- Cycle time: The time it takes for work to move from start to finish. Reducing cycle time can indicate that the team is streamlining their processes and becoming more efficient.
Ans: There are several ways to encourage continuous improvement in Scrum, including:
- Encouraging an open and collaborative team culture
- Providing resources and support for continuous improvement efforts
- Making continuous improvement a priority and allocating time and resources accordingly
- Recognizing and rewarding team members for their contributions to continuous improvement
- Creating a safe and supportive environment where team members feel comfortable proposing new ideas and experimenting with new approaches.
Ans: Yes, continuous improvement can be applied to any area of business or organization. The principles of continuous improvement, such as identifying areas for improvement, involving the entire team, and making small, incremental changes, can be applied to a wide range of industries and functions.
Ans: Continuous improvement is focused on continuously identifying and addressing areas for improvement within a business or organization. Continuous delivery is a software development practice that involves automatically building, testing, and releasing software changes as they are made. While both practices involve continuous processes, they are focused on different aspects of software development.
