We spoke about Optimal Planning, so now let’s dig into the deviations from it. The first one is if the Backlog is not ready.
If the Backlog is not ready, it means that it is not in a ready state as we have described previously. It means that we simply cannot take User Stories from the top of the Backlog one by one into the Sprint. Instead, we have to refine the User Stories and prioritize them before they enter the Sprint.
An unready Backlog can have several consequences:
- The team’s precious (and expensive) time is wasted if the Product Owner is setting up the Backlog order at the start of the Planning prior to letting the team take User Stories into the Sprint.
- The team loses trust in the Product Owner.
- The team cannot forecast development; they cannot get ready for what is waiting for them in the following Sprint. It is true that in an ideal case, each User Story is sized to be deliverable within one Sprint, so each one can stand alone. But development is a continuous process, and Developers need to be able to consider what comes before and after each User Story.
- There is no visibility or predictability for Stakeholders. If we do not have the Backlog ready before Planning, Stakeholders do not know what they can expect at the end of the Sprint. They do not know which part of the product the team will be working on and what the team’s priorities are for the current Sprint.
What do you do if your Backlog is not ready?
I would start refining the User Stories during the Planning. The Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. As we are running two-week Sprints, our timebox is four hours maximum.
That means that you have time to put your Backlog in order and prepare the User Stories into the Ready state—at least for several days if not for the whole Sprint.
If you do not manage to fill your Sprint capacity during that time, you can do another Refinement session the following day and refine more User Stories as long as your Sprint capacity is not full. Plus, if your Backlog is not ready for the current Sprint, you must make sure that it will be for the next one to avoid this situation from repeating. Ideally, you want to get your Backlog ready for two future Sprints and your development plan set for three months as mentioned in our previous article.
I described how to resolve the issue of when your Backlog is not ready, but it is much better to avoid this situation altogether. To do so, the Scrum Master must make sure that the Product Owner has the Backlog ready for Planning. The Product Owner has to work with the product Backlog regularly—even on a daily basis if necessary if it the nature of the product requires it—to ensure that the Backlog is ready for the Sprint Planning.
So, this is it for the topic of the Backlog not being ready. Next time we will write about when there is forced capacity.
Thank you for reading,
Have courage and be kind.