Scrum: 20 Sprint Planning Anti-Patterns

TL; DR: 20 Sprint Planning Anti-Patterns

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.

20 Sprint Planning Anti-Patterns — Berlin Product People GmbH

Diagram source: Scrum.org.

Update 2020-01-26: I rewrote large parts of the previous article, adding new Sprint Planning anti-patterns while removing others, and fixed some bugs as well.

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

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:

  1. “What can be delivered in the Increment resulting from the upcoming Sprint?”
  2. “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.

Cannot see the form?
Please click here

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 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 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.)

    Hands-on Agile: Scrum 20 Sprint Planning Anti-Patterns Slack Time Overutilization

  • 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.)

Hands-on Agile: Join 15,000 peers and download the free ‘38+6-Scrum-Master Interview Questions’ ebook

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 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 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 Product Backlog.

Scrum Master Interview Question: free download of the most popular ebook on Scrum Master job interviews — by Age-of-Product

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.

Join the Hands-on Agile Slack Group

If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

Update 2019-03-27: The Youtube Playlist of the Webinar Sprint Planning Anti-Patterns Is Available

The video of the webinar is available now:

Scrum Sprint Planning Anti-Patterns (0) — Introduction (Hands-on Agile Webinar #5)

Note: If the browser will not play the playlist automatically, click here to watch the Webinar Sprint Planning Anti-Patterns playlist directly on Youtube.

Related Posts

Daily Scrum Anti-Patterns: 20 Ways to Improve

Sprint Planning Checklist

Liberating Structures for Scrum (2): The Sprint Planning

28 Product Backlog and Refinement Anti-Patterns

6 thoughts on “Scrum: 20 Sprint Planning Anti-Patterns”

  1. Hi Jan, I am aware of that argument; nevertheless, I advocate to distinguish both to preserve the checks & balances within the Scrum Team. The Product Owner shall define the business goal; however, not the Sprint Goal. That responsibility belongs to the Scrum Team to avoid that tasks are being imposed on the Development Team.

  2. Hello Stefan!

    Thanks you very much for another great article. I usually read them and they are always very valuable.

    One question if you do not mind. You mention both Sprint Goal and Business Objective. Do we need to distinguish them? Can the Sprint Goal contain the business objective? For me, it would simplify matters, so we do not have two things for the Scrum Team to keep track of.

    Thank you in advance!

  3. thank you for the article.
    i’m not sure i understood the capacity planning diagram, the sum of percentage is over 100%…

  4. Vic, I derived the figures from teams I worked with in the past. They are a startup point, but I recommend that you adjust them over time according to your requirements. A mature application close to sunset may require more bug fixing and less refactoring. If you have the chance to build an application from scratch and you can focus on test automation, reserving 10 % of capacity for bug fixes may be excessive.

    @PO: I value transparency and hence rarely consider adding buffers. (That would be a bit like cheating in my eyes. However, I do understand that it depends on the organization and its culture.)

    If the daily business is volatile, I recommend allocating – similar to slack time – a certain percentage of the capacity to handle these unplannable issues. Such an allocation could also compensate for team members that help out other teams.

  5. Stefan, enjoyed the sprint planning article very much. It is an area I am focusing on now as our teams as not as consistent as we need to be to delivering the forecast. For your diagram, do you collect data from past sprints or just ask the team to come up with numbers like 8% buffer for bugs? I assume you don’t discuss this with the PO or PMO as they could scrutinize these different “buffers”? Do you have any more insight on tasking? Also don’t forget about team members that get dragged into helping other teams and calling that out as part of losing availability as well as surprises in people taking time off which differs from what was known at sprint planning. With small teams, the impact can be larger than expected.

Leave a reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.