The perfect ingredients to fail your Sprint Planning

No Sprint Goal

Why would a team start a Sprint without a goal? There are many reasons; I will share the ones that led me to that:

• Everything is a priority: once we don’t define the priority, everything becomes a priority. This scenario blocks us from establishing a goal to achieve, in other words, a north star to follow;
• Being a yes Product Owner: by saying yes to all requests, Sprint Backlog items lack coherence, and it becomes impossible to set Sprint Goals. What are we doing? Only pleasing the stakeholders and forgetting about the big picture; maximizing the value;
• Lack of product vision: how does this lead to not being able to set Sprint Goals? Without a clear direction through your Product Vision, it’s not possible to set clear Sprint Goals that force you to focus. Therefore, the direction is unclear or nonexistent.

The scenarios I mentioned cannot be used as excuses to skip the Sprint Goal. I failed, then I learned. The Sprint Goal is our lighthouse, our north star, that will lead the Team in a single direction, will ensure that we collaborate towards a common goal. By not having a Sprint Goal, we will have a group of people working together in different directions, which is not a team, if everyone is following a different path, there won’t be many chances to collaborate.

A Sprint Goal serves to promote self-organisation and creativity. It establishes the ‘why’ so the Development Team can work out the ‘how’. Therefore, a great goal could be like an open question that the Development Team aims to answer with the next increment.

Sjoerd Nijland, The Sprint Goal

If you are still not convinced about it, Christiaan Verwijs wrote an article clarifying this myth, that says the A Sprint Goal is Optional in Scrum. By reading it, you can understand how disastrous a Sprint can be without a goal.

Without a clear shared goal, and feeling the pressure to complete a Sprint Backlog full of unrelated items, there is no obvious incentive to collaborate. Instead, you are likely to see members of the team picking up ‘their own’ items from the Sprint Backlog and starting work on that. Self-organization will be limited and members will remain (or become increasingly) specialized in particular kinds of items;

— Christiaan Verwijs

Fuzzy Goal

The fuzzy Sprint Goal is a tricky thing that happened with me by not being able to define a clear focus. What is a fuzzy goal? A goal described with the word and on it by using that the Team is divided, and the Team doesn’t have a bright north start to pursue.

Let’s explore one example: “This sprint exists to allow our customers to find their products through the search and to allow them to sort the results as it best fits them.”. Within this Sprint Goal, where should the Team focus? Once we have a goal that doesn’t foster collaboration, the Sprint is a great candidate for failure. The Product Owners must ensure they don’t break the Team into micro-units.

Willem-Jan Ageling shared some issues that happened in scenarios like the one I described.

One of my teams had a couple of issues that were closely related:

the Development Team members did not work together to finish the items on their Sprint Backlog. Typically someone would finish her/his part and then would push the item to the next person.

items didn’t have any connection with each other. The team worked on many topics at the same time.

the team had a hard time to finish everything that they pulled to the Sprint Backlog. Often they didn’t even come remotely close to finishing what they planned.

the Daily Scrum was a status meeting only, hence ineffective.

— Willem-Jan Ageling, Scrum — The power of a great Sprint Goal

Also, the Sprint with a fuzzy goal is typical if the Product Owner falls into the trap of becoming feature-driven. It is extremely dangerous, since the focus should always be maximizing the value for the organization and not maximizing the number of features delivered. Be careful.

Product Owner defines the Sprint Goal alone

The Goal of the Sprint must be set collaboratively among the whole Scrum Team (DEVs + Product Owner + Scrum Master). However, some Product Owners do that alone, which includes me at the beginning of my career. What are the problems if the Product Owner comes to the Sprint Planning with the Goal already defined?

• The Development Team might be resistant to commit to something which they don’t have the chance of building together;
• It will limit the creativity of the Team, because it is already defined what they should do;
• The Development Team might not engage during the event.

As Product Owners, we must be crystal clear with our focus. We need to come with a clear objective to the Sprint Planning. Then, together with the whole team, we will craft the Sprint Goal; this will generate commitment and foster collaboration.

The Product Owner is responsible for maximizing the value of the product and he/she manages the Product Backlog. You might think that the Product Owner determines the Sprint Goal. This is not the case. During Sprint Planning the Product Owner suggests the objective of the upcoming Sprint and proposes which Product Backlog Items will help achieve this objective. But the suggested objective is NOT the same as the Sprint Goal.

— Willem-Jan Ageling, Scrum — Who determines the Sprint Goal?

No Backlog prepared

One of the most horrible experiences I’ve ever had in the Sprint Planning was when I came with an unprepared Backlog. The event took many hours to finish, because we needed to refine the product backlog items, discuss a lot around it. In the end, the Team was tired and not engaged in the event anymore. That’s not the way of starting a Sprint Planning, but why does that happen?

• Not enough backlog refinement sessions: the Team is not investing the required time to get the Product Backlog Items refined, so that they can be part of the Sprint;
• Change of direction: either the product vision changed abruptly, or the Product Owner changed his or her mind about the next objective. In this case, the Product Backlog Items available are not relevant to the new direction.

The Product Owner should not come to the Sprint Planning without a prepared backlog, meaning that the top items are not refined in a level the Team can start working on them. To achieve this level, we need to have the Backlog Refinement Sessions as much as necessary; the Scrum Guide suggests 10% of the available time. I have explored different scenarios. My favorite is a weekly one-hour session for a two weeks sprint.

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

— Scrum Guide

Product Owner comes with new PBIs

Sometimes, during Sprint Planning, the Product Owner comes with a last-minute idea, however, instead of keeping it, he or she decides the idea should be treated as a priority and want to squeeze into the Sprint! Which causes confusion and most probably disagreement with the Team.

If the Product Owner decides to do that, the Team will think it is fine to do the same; then, at some point in time, the Sprint Planning will be the moment to write new Product Backlog Items, refine, estimate, and eventually put into the Sprint Backlog. I believe that is not the moment to create new Product Backlog items. However, the Sprint Backlog emerges during Sprint Planning, thus if something emerges during Sprint Planning (of course related to Sprint Goal), then it’s fine.

Last minute changes: 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.)

— Stefan Wolpers, Product Owner Anti-Patterns

Product Owner forces the Team to over commit

It is ubiquitous for a Product Owner to work under pressure, meaning that stakeholders are always pressuring him or her because they want more features. However, the Product Owner must be able to handle this scenario by saying no to what is not a priority, therefore, setting the expectations. Unfortunately, this is not always the case; thus, the Product Owner tends to pressure the Team to commit to more.

Once the Product Owner takes this dangerous path of forcing the Team to commit to more Product Backlog Items than they are willing to commit, the Sprint tends to fail, false expectations become a reality, and the Team works under pressure. We must avoid starting the Sprint this way. Instead, the Product Owner must listen to the Team, and respect their capacity, and even better not plan 100% of it.

A lot of teams feel the urge to maximize their velocity each Sprint. Did we do 50 Story Points last time? Let’s try to push ourselves to do 55 Story Points this Sprint.

Then the Sprint ends and only 10 Story Points were finished. Everybody was focused on being busy instead of making sure the work flows from left to right on the Scrum board as quickly as possible.

— Maarten Dalmijn, 6 common mistakes when doing Sprint Planning

Wrap up

The Sprint Planning is crucial for the success of a Sprint; if this event fails, the Sprint will most probably take the same direction. Therefore, we have to ensure that:

• The product backlog is prepared for the Sprint Planning, meaning that the Product Backlog Items are ordered, and the ones on the top are refined to a level the Team can start working on.
• The Product Owner has a clear objective for the Sprint.
• The Sprint Goal is crafted together by the whole Scrum Team.
• The Sprint Goal is a north star that foster collaboration and ensure the Team is not broken into micro-units.
• Only discuss new ideas during Sprint Planning, when they have a strong connection with the Sprint Goal.