Sprint Planning and Some Anti Patterns

Sprint planning is the first ceremony teams do during the sprint. It is intended to set the context for the sprint, that, with the team at the center.

So, here’s what happens during a sprint planning –

——————————————————————————-Sprint Planning Begins

  • The product owners presents his/her wishlist to the team
  • The team looks through the items on the list, has a conversation with the product owner, on items that need clarification.
  • The team, based on empirical information, picks up items that they think will be able to finish within the sprint

———————————————————————————-Sprint Planning Ends

Simple, isn’t it?

Well, not really

Get into one the sprint planning meetings for a team that’s new to Scrum, and you will realize how simple, “Simple” really is.

For teams that are beginning to Sprint, Planning meetings can be a bit of a challenge, especially teams that are used to do longer delivery cadences, “High Level Design” document, “Low Level Design” document, Risk and Mitigation Plan documents, and what not.

It’s likely that, during the first few sprints, teams might find it difficult to derive value out of the Sprint Planning meeting. Its natural and acceptable, if such teams overcommit or under commit for the first couple of sprints. (Of course, the focus is to Inspect and Adapt effectively, not have a perfect planning meeting, which might not serve the product goal) The team needs to gets into the pulse of understanding how much of work the team can accomplish within a sprint. Until that happens, the onus lies on the Scrum Master to facilitate the ceremony effectively, and guide the team efficiently

What I am going to talk about today, are a few patterns that may lead to an in-effective sprint planning meeting. These are patterns “to-watch-out- for” for Scrum Masters.



  1. Product owner or Manager driving the outcome of Sprint Planning Meeting

Teams that are purely business driven often face this challenge. We see the team members walking into the team room for the Sprint planning meeting, and the meeting starts with the Product owner or the Manager saying “These are the stories that we need to get done by the end of the Sprint”. Thuddddd!!! The list then gets slapped on to the team, and the team is left wondering what to do. How do you think it feels being on one such team? Well, I wouldn’t blame the Product owner. He/she is purely driven by business.

As a Scrum Master, what can you do here? Well, educate the product owner. As a team, it’s only so much you can do. Anything beyond the team’s capability would be costly on the quality. Imagine owning a product that’s “On-Time” but not “On-Quality”


  1. Improper Slicing of stories during Planning Meeting

I could not stress more on the need to have all stories split rightly. By that I mean, a vertical slicing of the user story, not a Horizontal Slice. Close your eyes and imagine your favorite pastry, with multiple layers of cake and cream. Do you see yourself eating it? You always take a bite through all the layers, corrects. That’s when it feels like heaven. You would not imagine eating the creamy layer first, then, moving on to the cake.

Well, why not do the same thing during the sprint planning. When attempting to break down user stories, it’s necessary to break it down into vertical slices – pieces that cut through all the tiers of the application. If teams do not make a conscious effort of this, the team will end up creating separate tasks for UI development, writing the services, for validating the code etc. The only solution is to make a conscious effort towards rightly splitting the story.


  1. Unclear commitment

Teams sometimes come out of the Sprint planning meeting, without having made a commitment to the items that get into the Sprint Backlog. A Sprint Backlog is the list of Items that the team is confident about finishing by the end of the sprint. Without this conscious commitment, the team loses its drive during sprint execution. The product owner is not aware of what the team intends to complete by the end of the sprint. Its easy to work through this. Having a Sprint Goal for every sprint, brings in the element of commitment within the team as well as the business stakeholders. Having a Sprint Goal or a Sprint theme, also helps teams to prioritize items within a Sprint Backlog.

For those of us who are in love with cricket, we are aware of the Duckworth–Lewis method. This method takes into account the fact that, the team batting second already has a target of a goal to reach. Having a goal, always helps things put back on track.


  1. Over-Analysis during Sprint Planning

Teams, sometimes, get into a mode of Analysis Paralysis. It’s easy for teams to get carried away, and start to rip open the code, look at code possibilities, even try out a small Spike, all during the sprint planning meeting itself. Ok.. so, why will it be a problem? Well, not only does it lead to a situation where no outcome is achieved, it drains people out. A discussion with no outcome tires the mind. This can happen partly because, the story that was brought for discussion was not clear yet.

What can the Scrum Master do in such a situation – Simply, point to the clock. The sprint planning meeting is time boxed for a reason.

Stories that lead to team asking one question after another, probably needs grooming.


These are some of the most common anti patterns that I came across during my experience. Feel free to share yours.