Let us imagine the Product Owner for Scrum Team X has not ordered all the feedback from the Sprint Review in the Product Backlog. She is suggesting to postpone the Sprint Planning considering the work pending at her end.

She thinks it makes no sense to plan the Sprint if the Product Backlog isn’t in a transparent state. Can we postpone the Sprint Planning?

Response Time!

Remember the inputs for the Sprint planning referring to the Scrum Guide, “The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.”

The latest product increment is one of the inputs for the Sprint planning event. The Sprint planning event can proceed as long there are enough backlog items from the Product Backlog qualifying to be clear enough for the Development team and fits into one sprint.

Expecting a living artefact (Product Backlog) to be fully refined and complete is not possible. It is not a requirement to have all the items to be clear enough in order to start the Sprint with Sprint Planning.

The Sprint will start regardless of the state of the Product Backlog, and ought to be planned accordingly.

The Product Owner should help the Development Team to plan enough work in detail for the first one or two days and to frame an achievable Sprint Goal. This is possible with a holistic and thoughtful agenda from the past Sprints’ Sprint Review.

Referring to the Scrum Guide, “The Sprint Review includes the following elements […]The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning”.

How we wrap up the Sprint Review with aspects for the next Sprint matters a lot.

How we wrap up the Sprint Review with aspects for the next Sprint matters a lot.

A draft version of the Sprint goal should be made visible by the PO not only within the Scrum but also with stakeholders for feedback and adaptation. This gives enough focus and trust to kick-start the next sprint with the Sprint Planning.

Scrum Master — Rise to the Occasion!

“The Scrum Master serves the Product Owner in several ways, including:

• Finding techniques for effective Product Backlog management;
• Helping the Scrum Team understand the need for clear and concise Product Backlog items;
• Understanding product planning in an empirical environment;” — The Scrum Guide

Scrum Master should help the Product Owner and the Development Team (if articulating PBIs in the Product Backlog is delegated to the Development Team) with better ways and techniques for effectively managing the Product Backlog.

Moreover, the empirical mindset needed for the Product Owner to start making decisions based on what is known and continuously keep the Product Backlog emerging should get coached by the Scrum Master.

Wrap Up!

“Scrum encourages just enough planning, the important thing is to know the valuable items that can help with crafting the Sprint goal as it is the thing that matters when planning a Sprint. All other details can be identified later. Scrum also encourages flexibility during the Sprint as long as the Sprint goal is met. The Sprint Backlog can evolve as more is learnt during the Sprint.”

– Shweeta, Agile Coach, Here Technologies

Postponing Sprint Planning is definitely not a solution here. Instead, the Sprint Planning time can be utilized for the transparency to be created around this situation and inspect and adapt accordingly.