Anti-Patterns: Sprint Planning
Scrum’s sprint planning is a simple event. Try Invest upfront during the product backlog refinement, and you will keep it productive. Avoiding the following sprint planning anti-patterns will help, too.
The Purpose of the Sprint Planning
The purpose of Scrum’s sprint planning is to align the development team and the product owner. Both need to agree on the potentially shippable product increment of the next sprint. The idea is that the development team’s forecast (some teams call this the sprint commitment) reflects the product owner’s sprint goal. Also, the team needs to come up with a plan on how to accomplish its forecast.
If the scrum team has been successfully using product backlog refinements in the past the sprint planning part 1 will be short. The development team and the product owner will adjust the discussed scope of the upcoming sprint to the teams velocity or available capacity. Maybe, someone from development team will not be available next sprint. So, one or two stories will have to go back to the product backlog.
Or a valuable new story appeared overnight, and the product owner wants this story to become a part of the next sprint backlog. Consequently, some other user story needs to go back to the product backlog. A good team can handle that in five to ten minutes before moving on to sprint planning part 2. During sprint planning II the team breaks down the first set of sprint backlog items into subtasks.
Be clear, be confident and don’t overthink it. The beauty of your story is that it’s going to continue to evolve and your site can evolve with it. Your goal should be to make it feel right for right now. Later will take care of itself. It always does.
Sprint Planning Anti-Patterns:
There are three categories of sprint planning anti-patterns. They concern the development team, the product owner, and the scrum team, however in this article I will focus on the Development Team:
Sprint Planning Anti-Patterns of the Development Team:
The team members do not determine their availability at the beginning of the sprint planning.
The development team overestimates its capacity and takes on too many tasks. (The development team should instead take everything into account that might affect its ability to deliver. The list of those issues is long: public holidays, new team members, and those on vacation leave, team members quitting, team members on sick leave, corporate overhead, scrum events and other meetings to name a few.)
The development team is not demanding adequate capacity to tackle technical debt and bugs during the sprint. (The rule of thumb is that 25% of resources are allocated every sprint to fix bugs and refactor the code base. If the product owner ignores this practice, and the development team accepts this violation the scrum team will find itself in a downward spiral. Its future product delivery capability will decrease.)
The development team is not demanding 20% slack time from the product owner. (If a team’s capacity is always over-utilised, its performance will decrease over time. This will particularly happen in an organisation with a volatile daily business. As a consequence, everyone will focus on getting his or her tasks done. There will be less time to support teammates or to pair. The team will no longer address smaller or urgent issues promptly. Individual team members will become bottlenecks, which might seriously impede the flow within the team. Lastly, the ‘I am busy’ attitude will reduce the generation of a shared understanding among all team members. Over-utilisation will always push the individual team member to focus on his or her output. On the other side, slack time will allow the scrum team to act collaboratively and focus on the outcome.)
During sprint planning II, the development team plans every single subtask of the upcoming sprint in advance. (Don’t become too granular. Two-thirds of the sub-tasks are more than sufficient, the rest will follow naturally during the sprint. Doing too much planning upfront might result in waste.)
The development team is skipping the sprint planning altogether. (Skipping the sprint planning is unfortunate, as it is also a good situation to talk about how to spread knowledge within the development team. For example, the team should think about who will be pairing with whom on what task. The sprint planning is also a well-suited to consider how to reduce technical debt.)
The development team does not come up with a plan to deliver on its forecast collaboratively. Instead, a ‘team lead’ assigns tasks to individual team members.
Thank you for reading, the next article will be on Sprint Planning anti-patterns and focusing on Product Owners.
