20 Sprint Planning Anti-patterns

TL; Dr: Scrum Master Anti-patterns

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

The Purpose of the Sprint Planning

Scrum’s Sprint Planning aims to align the Developers and the Product Owner on what to build next, delivering the highest possible value to customers. First, the Product Owner points to the team’s Product Goal and introduces the business objective of the upcoming Sprint. The Scrum Team then collaboratively creates a Sprint Goal, considering who is available and the target the team shall accomplish. Next, the Developers forecast the work required to achieve the Sprint Goal by picking the right items from the Product Backlog and transferring them to the Sprint Backlog. Also, the Developers need to create a plan on how to accomplish their forecast. 

No longer mandatory since the 2020 edition of the Scrum Guide is that the Scrum team agrees to tackle at least one high-priority improvement issue from the previous Sprint Retrospective.

The Scrum Guide characterizes the Sprint Planning as follows:

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.

The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Scrum Team may also invite other people to attend Sprint Planning to provide advice.

Basically, the Sprint Planning answers three questions:

1. Why is this Sprint valuable? (The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.)
2. What can be Done this Sprint? (Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence. Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.
3. How will the chosen work get done? (For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value. The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.)

Source: Scrum Guide 2020.

Suppose the Scrum Team has been successfully utilizing the Product Backlog refinements to create and maintain an actionable Product Backlog. In that case, the Sprint Planning consumes much less time than the eight hours the Scrum Guides lists for a month-long Sprint. Basically, the Developers 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 Scrum team can handle that in ten to 30 minutes before moving on to the decomposition tasks and the initial planning of how the Developers intend to accomplish the work of the Sprint.

Sprint Planning Anti-patterns

There are mainly three categories of Sprint Planning anti-patterns. They concern the Developers, the Product Owner, and the Scrum team:

Sprint Planning Anti-patterns of the Developers

• Capacity? The Developers overestimate their capacity and take on too many tasks. (The Developers should instead consider everything 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.)
• What technical debt? The Developers do not demand adequate time to tackle technical debt and bugs and preserve the quality standard of the product. Instead, they fully embrace the feature factory, shipping one new feature after the other. (My rule of thumb is that the Developers shall consider allocating up to 20 % of their time to fixing bugs and refactoring the codebase. A high-quality tech stack is at the core of being able as a Scrum team to adapt the following steps to lessons learned and recent market trends. Technical excellence is a prerequisite of any form of business agility; preserving this state is a continuous process that requires a steady and substantial investment. Read more: Technical debt and Scrum.)
• No slack time: The Developers do not demand 20% slack time—or unplanned capacity—from the Product Owner. (This overlaps with the Sprint Planning, creating Sprint Goals, and the team’s ability to forecast. However, it cannot be addressed early enough. If a team’s capacity is always utilized at 100 %, its performance will decrease. Everyone will focus on getting their tasks done. There will be less time to support teammates or to pair. Minor issues will no longer be addressed immediately. And ultimately, the ‘I am busy’ attitude will reduce the creation of a shared understanding among all team members why they do what they are doing.)
• Planning too detailed: During the Sprint Planning, the Developers plan 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. Scrum is not a time-boxed form of the waterfall planning practice.)
• Too much estimating: The Developers even estimate sub-tasks. (That looks like accounting for the sake of accounting to me. So don’t waste your time on that. Remember: the purpose of estimating is to identify misalignment among the Developers regarding the What and How of items from the Product or Sprint Backlog. Read more: Estimates Are Useful, Just Ditch the Numbers.)
• Too little planning: The Developers skip planning altogether. (Skipping planning is unfortunate, as it is also an excellent opportunity to talk about how to spread knowledge among the Developers, where the architecture is heading, or whether the tools are adequate. For example, the team might also consider who will be pairing with whom on what task. The Developers’ planning part is also well-suited to consider how to reduce technical debt, see above.)
• Team leads? The Developers do not devise a plan to deliver their forecast collaboratively. Instead, a ‘team lead’ does all the heavy lifting and probably even assigns tasks to individual Developers. (I know that senior developers do not like the idea, but there is no ‘team lead’ on a Scrum Team.)

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 Product Goal and overall product vision. (A serious objective answers the “What are we fighting for?” question. It is also a negotiation between the Product Owner and the Developers to a certain extent. The objective is focused and measurable, as the Sprint Goal and the Developers’ forecast go hand in hand.)
• No business objective, no Sprint Goal, just random stuff: The Product Owner proposes a direction that resembles 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 composing and 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 have not been refined. (Principally, it is the prerogative of the Product Owner to make such kinds of changes to ensure that the Developers work 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 ordering the Product Backlog and improving team communication. Or the Product Owner needs support to deal with pushy stakeholders.)
• Output focus: The Product Owner pushes the Developers to take on more tasks than they could realistically handle. Probably, the Product Owner is referring to former team metrics such as velocity to support their desire. (This is also a road to becoming a feature factory and deserves attention from the team’s Scrum Master. It violates the Developers’ prerogative to pick Product Backlog items for the Sprint Backlog and Scrum Values.) 
• No preparation: The Product Owner does not invest adequately in continuously refining and actionable Product Backlog in collaboration with the Developers. (The Product Backlog needs to represent the best possible use of the Developers’ time 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, 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. (The Sprint length is not static but adjustable to offer the Scrum team the best balance between being up-to-date with customer needs while having sufficient, uninterrupted time to focus on meaningful work. When the learning curve is steep, Sprints are short. Once the Scrum team becomes more educated, Sprint lengths might expand. Also, it is pretty common, for example, to extend the Sprint length at the end of the year when most of the team members are on holiday. However, changing the Sprint length flexibly 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 the appropriate sizing of tasks.)
• Over-commitment: The Scrum team regularly takes on 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 Developers meet the Sprint Goal, so be it. On the other hand, 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 putting 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 exciting topic for 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, suppose the “definition of ready” is used as a checklist, rejecting everything that is not 100 percent covered. In that case, you are reintroducing waterfall through the backdoor, only this time it is the Developers doing that.)
• No standard for considering Product Backlog items ‘ready:’ The Scrum team does not have a shared understanding of what a “Sprint-ready” Product Backlog item requires. (This is the opposite side of being dogmatic about applying a “definition of ready.” So now, the Developers select unsuited work items that may cause unnecessary disruptions during the Sprint, possibly even endangering achieving the Sprint Goal, into the Sprint. 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 Developers by defining their 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 Developers makes a forecast on behalf of everyone else.)
• Planning ignored: The Developers are not participating collectively in the 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. They hence need to guide the Scrum team’s effort during Product Backlog refinement to provide an appropriately prepared, actionable Product Backlog before the actual Sprint Planning. At the same time, the Developers are 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?

Besides being complicit in the Sprint Planning anti-patterns sketched above by not addressing them, I can think of one Sprint Planning anti-pattern that directly falls into the responsibility of the Scrum Master. Despite the changes to the Scrum Guide in 2020, addressing an important improvement issue from the previous Sprint Retrospective every Sprint is still an important step to help the Scrum Team improve continuously. Therefore, failing to support the Scrum team in that matter constitutes a Sprint Planning anti-pattern in my eyes.

Conclusion

Sprint Planning is a core event, defining how your customers’ lives will improve with the next Product Increment and 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-management, and Scrum’s built-in checks & balances.

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

Watch the Video on Sprint Planning Anti-patterns

The video of the Sprint Planning Anti-Patterns webinar is available on Youtube: