Scrum: 19 Sprint Planning Anti-Patterns

TL;DR: 19 Sprint Planning Anti-Patterns

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 forecast 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 available capacity. Maybe, someone from development team will not be available 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 II 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 forecast 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 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 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 II altogether. (Skipping the sprint planning II 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 II 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. (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).

Download the ‘Scrum Anti-Patterns Guide’

The ’Scrum Anti-Patterns Guide’ is another free ebook from the Hands-On Agile series of practical guides from the trenches. It covers more than 100 scrum anti-patterns that hold your scrum team back.

Download your copy of the “Scrum Anti-Patterns Guide” now…

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 forecast 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 I, 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 such kind 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.

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 member 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 forecast 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. Read More: The Dangers of a Definition of Ready.)
• 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 forecast 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 forecast. 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 forecast on behalf of the team.)
• 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 voice hence needs to be heard.)

Conclusion

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.

Related Posts

16 Stand-up Anti-Patterns Threatening Your Transition to Scrum

28 Product Backlog and Refinement Anti-Patterns

Do you want to read more like this? Well:

• ?? Join 7,968 peers and sign-up for my weekly newsletter
• ?? Follow me on Twitter and subscribe to my blog Age of Product
• ?? Or, join 910+ peers of the new Slack team “Hands-on Agile” for free…