Yes, Scrum can work without Sprint Planning!

When I started working as a Product Owner, I was mainly using Scrum as a framework for the software development process. With the dev team we followed all the ceremonies as prescribed, but one thing we always kept in mind was that having an Agile-Lean mindset is something far more important than following Scrum.

One day during a painful and long Sprint Planning session, a developer asked me why the team had to commit to a business value that should be delivered by the end of the sprint? Does commitment make us work faster or more efficiently?

I was ready to start explaining how it gives us focus and motivation and predictability, but I suddenly realized that this does not mean anything if we cannot prove that it really makes the team more productive. So, we decided to test what will happen to the team productivity if we don't commit to a sprint scope.

On the next planning meeting as agreed we did not commit and there was a sudden immediate effect. The planning meeting ended in 15 minutes! The reason was that without commitment, the whole Sprint Planning became an unnecessary event, because new tasks can be added from the backlog into the sprint at any point in time. At the end of the sprint, I happily noticed that sprint velocity was higher than usual without any other change.

I continued working like this for years and I also assessed the approach with different Scrum teams in different states of their maturity and till now it always worked well. I will not go into more details on this topic, so I will just summarize the main benefits which I noticed by not doing Sprint Planning:

• One less meeting for the developers and as we know most devs hate meetings.
• No more under-commitment during sprint planning, so the team is free to have the velocity they are really able to achieve without fear of failure.
• We stopped thinking about the average team velocity to try to predict what can be the scope of the next sprint, so we removed by default this "anchor".
• There was no more investigation who is available and at what percentage for the next sprint in order to try to balance the commitment.
• Discussion should we add additional tasks into the sprint at the end of the sprint becomes irrelevant.
• The velocity of the team became more realistic, so the forecasting improved.
• Incidents can be handled without impacting a predefined sprint scope.
• More flexibility for the PO if there is a sudden change in priorities.
• Less stress, distractions and more focus on the main thing - team productivity. This was proven by the increase in velocity.

One important thing that needs to be highlighted is that the refinement meetings became more important, because tasks should be completely ready to be worked on after refinements. As POs we have to ensure that all the requirements are clear and refined with the team, because without sprint planning any task that is in the top of the backlog can be taken into the sprint at any point in time. The top of the Backlog needs to be filled with enough tasks which are refined, estimated and ready to be worked on at any point in time.

So my advise is if you do Sprint Planning meetings and those are long and stressful for the team be brave and try to do couple of sprints without them. The Kaizen process will never fail if the focus is to solve real problems.