Scrum: 19 Sprint Planning Anti-Patterns
In this post, a Scrum Master discusses what to do, and what not to do, while participating in Sprint planning sessions with your Scrum team.
Join the DZone community and get the full member experience.Join For Free
Scrum’s Sprint planning is a simple ceremony. Invest upfront during the product backlog refinement, and you will keep it productive. Avoiding the following 19 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 shippable product increment of the next Sprint. The idea is that the development team’s commitment reflects the product owner’s Sprint goal. Also, the team needs to come up with a plan on how to accomplish its commitment (or forecast if you prefer that term).
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 available capacity. Maybe, someone from the development team will not be available for the next Sprint. So, one or two tasks will have to go back to the product backlog.
Or a valuable new task appeared overnight, and the product owner wants this task 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 2, the team breaks down the first set of Sprint backlog items into subtasks.
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:
Sprint Planning Anti-Patterns of the Development Team:
- The team members do not determine their availability at the beginning of the Sprint planning (good luck with making a commitment in this situation).
- 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 ceremonies, 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-utilized, its performance will decrease over time. This will particularly happen in an organization 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. Overutilization 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 2, 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 estimates sub-tasks. That looks like accounting for the sake of accounting to me. Don’t waste your time on that.
- The development team is skipping the Sprint planning 2 altogether. Skipping the Sprint planning 2 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 2 is also a time well-suited to consider how to reduce technical debt.
- The development team does not come up with a plan to deliver on its commitment collaboratively. Instead, a ‘team lead’ assigns tasks to individual team members. I know that senior developers do not like the idea, but there is no ‘team lead’ in a Scrum team. Read More: Why Engineers Despise Agile.
Sprint Planning Anti-Patterns of the Product Owner:
- The product owner cannot provide a Sprint goal, or the chosen Sprint goal is flawed. An original sprint goal answers the “What are we fighting for?” question. It is a negotiation between the product owner and the development team. It is focused and measurable, as Sprint goal and team commitment go hand in hand. Lastly, the Sprint goal is a useful calibration for the upcoming Sprint.
- The Sprint backlog resembles a random assortment of tasks, and no Sprint goal is defined. If this is the natural way of finishing your Sprint planning 1, you probably have outlived the usefulness of Scrum as a product development framework. Depending on the maturity of your product, Kanban may prove to be a better solution. Otherwise, the randomness may signal a weak product owner who listens too much to stakeholders instead of prioritizing the product backlog appropriately.
- Unfinished user stories and other tasks from the last Sprint spill over into the new Sprint without any discussion. There might be good reasons for that, for example, a task’s value has not changed. It should not be an automatism, though, remember the sunk cost fallacy.
- The product owner tries to squeeze in some last-minute user stories that do not meet the definition of ready. Principally, it is the prerogative of the product owner to make these kinds of changes to ensure that the development team is working only on the most valuable user stories at any given time. However, if the Scrum team is otherwise practicing product backlog refinement sessions regularly, these occurrences should be a rare exception. If those happen frequently, it indicates that the product owner needs help with prioritization and team communication. Or the product owner needs support to say ‘no’ more often to stakeholders.
- The product owner pushes the development team to take on more tasks than it could realistically handle. Probably, the product owner is referring to former team metrics such as velocity to support his or her desire (this would be an opportunity for the candidate to step in and address the issue).
Sprint Planning Anti-Patterns of the Scrum Team:
- The Scrum team has variable Sprint cadences. For example, tasks are not sized to fit into the regular Sprint length. Instead, the Sprint length is adapted to the size of the tasks. It is quite common to extend the Sprint length at the end of the year when most of the team members are on holiday. However, there is no reason to deviate from the regular cadence during the rest of the year. Instead of changing the Sprint length, the Scrum team should invest more effort into sizing epics and user stories in the right way.
- The Scrum team regularly takes on way too many tasks and moves unfinished work simply to the next Sprint. If two or three items spill over to the next Sprint, so be it. If regularly 30-40 percent of the original commitment is not delivered during the Sprint, the Scrum team may have created a kind of ‘time-boxed Kanban’ (maybe this is the right moment to ask the Scrum team whether moving to Kanban might be an alternative).
- The definition of ready is handled in a dogmatic way, thus creating a stage-gate-like approval process. That is an interesting topic for a discussion among the team members. For example, should a valuable user story be postponed to another Sprint just because the front-end designs will not be available for another two working days? My suggestion: take it to the team. If they agree with the circumstances and accept the user story into the sprint — that is fine.
- The development team is not rejecting user stories that do not meet the definition of ready. This is the opposite side of being dogmatic about the application of DoR: not-ready user stories that will cause unnecessary disruptions during the Sprint are allowed into it. Laissez-faire does not help either.
- The Sprint commitment is not a team-based decision. Or it is not free from outside influence. There are several anti-patterns here. For example, an assertive product owner dominates the development team by defining its scope of the commitment. Or a stakeholder points at the team’s previous velocity demanding to take on more user stories (“We need to fill our free capacity”). Or the ‘tech lead’ of the development team is making a commitment on behalf of the team. Whatever the reason is, the candidate should address the underlying issues.
- The development team is not participating collectively in the Sprint planning. Instead, two team members, for example, the tech and UX leads, represent the team. As far as the idea of one or two ‘leading’ teammates in a Scrum team is concerned, there are none, see above. And unless you are using LeSS – no pun intended – where teams are represented in the overall Sprint planning, the whole Scrum team needs to participate. It is a team effort, and everyone's voice, hence, needs to be heard.
Scrum’s Sprint planning is a simple ceremony. Invest upfront during the product backlog refinement, and you will keep it productive. Most of the beforementioned sprint planning anti-patterns are simple to fix. Just take it to the team.
What Sprint planning anti-patterns are missing? Please share with us in the comments.
You can download the complete guide to Scrum anti-patterns here: Agile Transition — A Hands-on Manual from the Trenches
Published at DZone with permission of Stefan Wolpers, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.