As we mentioned in the article A Scrum Master’s To Do List (Part I), a pre-requisite for Sprint Planning itself is to have a Product Backlog ready. Without it, you can hardly plan anything and even if you do, I know from experience that planning without having User Stories ready for a Sprint is very difficult and exhausting for everyone involved.
In previous articles, we described the different modes of Planning that we support in ScrumOne, but we try to stick to the first one, Capacity Chosen, which I would like to further explain in this article.
At Planning, we always start by checking the capacity of the team; that is, identifying who will not be available during the Sprint because they are, for example, on leave. We wrote about this in detail in the article Planning Rules Rule! Once capacity is confirmed, the Product Owner suggests a Sprint Goal for the next Sprint and Developers start planning the Sprint. (The Team should not hear about the suggested Sprint Goal for the first time at Sprint Planning, however, since the Product Owner presents the plan for the next Sprint to the Stakeholders during the Sprint Review and the Product Backlog should contain refined User Stories for at least two Sprints ahead.)
The Developers usually take individual User Stories into the Sprint based on their priority in the Product Backlog and the intent behind the Sprint, from top to bottom. Usually, the "higher" the User Story is, the higher its priority. The Team takes the amount of work that they should realistically be able to deliver at the end. Based on what is discovered during the Planning, the Product Owner and Developers can collaborate on adjusting or completely changing the Sprint Goal and the order of User Stories. Once the Developers pull the work into the Sprint, the whole Team should confirm the Sprint Goal, as this is something they will be working towards together.
And that is it! We have completely covered Planning, but have even more interesting topics to write about. See you soon!