No acceptance criteria listed on user stories
This will keep the team from really committing to the sprint backlog. If they have no clear idea on how to demo a user story, how the product owner will decide whether or not a story is really done, the team will have no way to feel confident about the commitment they are making. This will frustrate the team, as well as be the cause for large amounts of re-work, because the stories will be implemented to the best of the team’s abilities and knowledge and will not be exactly what the product owner or customer had in mind. We usually see this when the product owner does not spend enough time on grooming the backlog together with the stakeholders.
Assigning tasks and stories to specific people
The goal of the sprint planning is to form a plan of action with the entire team, so they are sure they can commit to the sprint backlog. In order to do this, the team will split the user stories into several tasks they will need to do, to fulfill all acceptance criteria and get the story to done. Trying to fill up each team member’s agenda during this meeting will not only result in an overly long sprint planning. It will also be a complete waste of time doing this. Because the moment something changes (someone gets ill, needs to be home for some other reason, is required in an unexpected meeting or anything else) your entire plan that you probably spent about 2 hours on to put together falls apart. The concept of the self-organizing team is that they pull work into the sprint as well as pull work into their own agenda when they have the time for it.
Product owner is not available during this ceremony
The team can’t commit to stories when they are not sure about the problem they need to address. This is why the product owner is required during this meeting to answer questions about the user stories that will potentially be pulled into the sprint. The second reason why it’s so important the product owner is there is when the team suggests a small priority change in order to fill up their sprint capacity. I’ll explain with an example. Let’s imagine we have a scrum team that has an average velocity of 31 story points. They already have committed to 26 points of stories and the next story in the product backlog is one of 8 points. The team is not ok to add this to the sprint backlog, but they still have some capacity left. So they look to the next story, which a 5 point one. So they propose to pull this one into the current sprint and leave the bigger story for the next sprint. They can only suggest this, only the product owner can decide to do this or not.
Using the numbers instead of collaborative knowledge
In many cases we see that people are becoming too focused on the numbers: story point estimates & velocity! Instead of evaluating the complexity at hand, people make an abstraction with the numbers at hand instead. This will generate frustration, stress, overwork, underperformance and a lot of other side effects. Calculations will always be wrong as estimates are given on “story” level and velocity is measured with hindsight, during the sprint planning we are in a different situation. We discover new information while splitting the story into tasks/activities and have to take this into account while estimating what is possible for the next upcoming iteration. We also know that every iteration there is a different capacity available, some people take holidays or have other meetings or trainings scheduled and thus the situation and competence of the team to get things DONE in an iteration changes each time. In order to address all of this complexity one has to use the team’s collaborative knowledge to agree what is possible for next iteration and can not use the calculated velocity. Only this way the overall planning (where you do use the calculations based on estimates and velocity) can become reliable.