20 Sprint Planning Anti-Patterns

(Germany)

January 27, 2020

Sprint Planning is a core event, defining how your customers’ lives will improve with the next Product Increment. Learn more on how to improve its effectiveness by avoiding 20 common Sprint Planning anti-patterns.

Diagram source: Scrum.org.

Do you want to get this article in your inbox? You can sign up here and join 24k other subscribers.

Upcoming Scrum Training Classes, Remote Agile Classes, and Liberating Structures Workshops

The Purpose of the Sprint Planning

The purpose of the Sprint Planning is to align the Development Team and the Product Owner on what to build next, delivering the highest possible value to customers. The Product Owner introduces the business objective the upcoming Sprint is supposed to meet, the Scrum Team collaboratively creates a Sprint Goal, and the Development Team forecasts the work required to achieve the goal by picking the appropriate items from the Product Backlog, transferring them to the Sprint Backlog. Also, the Development Team needs to come up with a plan on how to accomplish its forecast as well as pick at least one high priority improvement issue from the previous Sprint Retrospective.

According to the Scrum Guide, the Sprint Planning answers two questions:

“What can be delivered in the Increment resulting from the upcoming Sprint?”
“How will the work needed to deliver the Increment be achieved?”

Source: Scrum Guide, 2017.

If the Scrum Team has been successfully utilizing the Product Backlog refinements to create and maintain an actionable Product Backlog, the Sprint Planning consumes much less time than the eight hours, the Scrum Guides lists for a month-long Sprint. Basically, the Development Team and the Product Owner adjust the previously discussed scope of the upcoming Sprint to the available capacity.

Alternatively, a valuable new task may have appeared overnight, and the Product Owner wants this task to become a part of the next Sprint, too. Consequently, some previously considered Product Backlog items won’t make it into the Sprint Backlog. A good team can handle that in ten to 30 minutes before moving on to the decomposition tasks and the initial planning of how the Development Team intends to accomplishing the work of the Sprint.

Download the ’Scrum Anti-Patterns Guide’ for Free

Sprint Planning Anti-Patterns

There are mainly 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

Capacity? 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 as practices such as Product Backlog refinement, and other meetings to name a few.)
Ignoring technical debt: The Development Team is not demanding adequate capacity to tackle technical debt and bugs during the Sprint. (The rule of thumb is that about 20 % of resources are well-spent every Sprint to fix bugs and refactor the codebase. If the Product Owner ignores the need for this work, and the Development Team accepts this attitude, the Scrum Team will find itself in a downward spiral, turning slowly but steadily into an output-focused feature factory. Its future product delivery capability will decrease. Read more on technical debt and Scrum.)
No slack time: The Development Team is not asking for a 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 do pair programming, for example. 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 into a less collaborative mindset, impeding self-organization. On the other side, slack time will allow the Scrum Team to act collaboratively and focus on the outcome.)
Planning too detailed: During the Sprint Planning, the Development Team plans every single task of the upcoming Sprint in advance. (Don’t become too granular. One-quarter of the tasks are more than sufficient to not just start with the Sprint, but also start learning. The Sprint Backlog is emergent and doing too much planning upfront might result in waste.)
Too much estimating: The Development Team estimates sub-tasks. (That looks like accounting for the sake of accounting to me. Don’t waste your time on that.)
Too little planning: The Development Team is skipping planning altogether. (Skipping planning is unfortunate, as it is also an excellent opportunity to talk about how to spread knowledge within the Development Team, where the architecture is heading, or whether tools are adequate. For example, the team might also consider who will be pairing with whom on what task. The Development Team planning part is also well-suited to consider how to reduce technical debt, see above.)
Team leads? The Development Team does not come up with a plan to deliver on its forecast collaboratively. Instead, a ‘team lead’ does all the heavy lifting and probably even 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

What are we fighting for? The Product Owner cannot align the business objective of the upcoming Sprint with the overall product vision. (A serious goal answers the “What are we fighting for?” question. To a certain extent, it is also a negotiation between the Product Owner and the Development Team. It is focused and measurable, as the Sprint goal—based on the business objective—and Development Team’s forecast go hand in hand.)
No business objective, no Sprint Goal: The Product Owner proposes Product Backlog items that resemble a random assortment of tasks, providing no cohesion. Consequently, the Scrum Team does not create a Sprint goal. (If this is the natural way of finishing your Sprint Planning, 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 ordering the Product Backlog appropriately.)
Unfinished business: 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.)
Last-minute changes: The Product Owner tries to squeeze in some last-minute Product Backlog items that are not ready yet. (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 tasks 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 ordering the Product backlog and team communication. Or the Product Owner needs support to say ‘no’ more often to stakeholders.)
Output focus: 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 is also a road to becoming a feature factory and deserves attention from the team’s Scrum Master. It is violating the Development Team’s prerogative to pick Product Backlog item for the Sprint Backlog as well as Scrum Values.)
No preparation: The Product Owner does not prepare the Product Backlog to provide useful Product Backlog items for selection by the Development Team. (Product Backlog needs to represent the best possible use of the Development Team’s work from a customer value perspective at any given moment. In other words, your Scrum Team’s Product Backlog has to be actionable 24/7. By my standards, that means that you need to be capable of running a meaningful Sprint Planning instantly. Preparing a few basic Product Backlog items an hour before the beginning of the Sprint Planning is not enough.)

Sprint Planning Anti-Patterns of the Scrum Team

Irregular Sprint lengths: 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 or the Sprint Goal at hand. (It is quite common, for example, to extend the Sprint length at the end of the year when most of the team members are on holiday. However, flexibly changing the Sprint length as “needed” is a dark pattern. Instead of changing the Sprint length to accommodate the Sprint Goal, the Scrum Team should invest more effort into sizing tasks in the right way.)
Over-commitment: The Scrum Team regularly takes on way too many tasks and moves unfinished work directly to the next Sprint. (If two or three items spill over to the next Sprint while the Development Team meets the Sprint Goal, so be it. If regularly 30 to 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. If the team considered Scrum still to be its choice, I would recommend to put more energy into Product Backlog refinement and creating meaningful Sprint Goals.)
Stage-Gate® by DoR: The Scrum Team decides that a definition of ready is advantageous but handles it dogmatically, 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 corresponding Product Backlog item into the Sprint — that is fine. However, if the definition of ready is used a checklist, rejecting everything that is not 100 percent covered by it, then you are reintroducing waterfall through the backdoor, only this time it is the Development Team doing that. Read More: The Dangers of a Definition of Ready.)
Ignoring the DoR: The Development Team does not reject Product Backlog items that do not meet its definition of ready. (This is the opposite side of being dogmatic about the application of DoR: unready tasks that will cause unnecessary disruptions during the Sprint—possibly endangering achieving the Sprint Goal—are allowed into it. Laissez-faire does not help either.)
Forecast imposed: 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 the free capacity.”) Or the ‘tech lead’ of the Development Team is making a forecast on behalf of the Development Team.)
Planning ignored: The Development Team is not participating collectively in Sprint Planning. Instead, two team members, for example, the “tech lead” and “UX lead,” represent the team. (As far as the idea of one or two “leading” teammates in a Scrum Team are concerned, there are none, see above. And unless you are using Nexus or 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. Otherwise, transparency will suffer and flawed decisions might be made, reducing value creation and increasing risk.)

Sprint Planning Anti-Patterns of the Scrum Master

The Product Owner is responsible for the business objective of the upcoming Sprint and hence to provide an appropriately prepared Product backlog. At the same time, the Development Team is in charge of selecting the necessary Product Backlog items to meet the collaboratively created Sprint Goal. So, what are Sprint Planning anti-patterns of the Scrum Master, you may ask yourself?

I can think of one Sprint Planning anti-pattern that falls into the responsibility of the Scrum Master: not ensuring that an important improvement issue from the previous Sprint Retrospective to help the Scrum Team improve continuously becomes a part of the Sprint Backlog.

Conclusion

Sprint Planning is a core event, defining how your customers’ lives will improve with the next Product Increment, and to not be taken lightly. Fortunately, most of the beforementioned Sprint Planning anti-patterns are simple to fix. Just take it to the team, respect Scrum Values, self-organization, and Scrum’s built-in checks & balances.

What Sprint Planning anti-patterns have you observed? Please share it with us in the comments.

✋ Do Not Miss Out: Join the 6,500-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.