March 6, 2021


News for Agilists

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.

Photo by Paulius Dragunas on Unsplash

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.

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.

Photo by Kevin Ku on Unsplash

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

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.

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.
Photo by Robert Bye on Unsplash

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

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.

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.

Source link