Adopting Story Points as a measurement tool is now one of the anti-patterns in the Scrum world nowadays. However, many product teams are still using this. The majority of them, even worse, emphasise the accuracy of their plan by comparing the estimated story points with the actual completed story points. They’re afraid of carrying over the unfinished Product Backlog Items and upsetting the stakeholders.

The more time the team spends in planning, the less time they can work on the actual items. Their overplanning creates an illusion that they know everything about the upcoming Sprint. When it deviates, they feel nervous and only think of fulfilling the estimated story points. In the next Sprint, they put even more effort into planning.

Is carry-over acceptable?

Before we discuss this question, let’s read the Scrum Guide. The Sprint Backlog is a plan for the Developers. It is a real-time picture of the work that the Developers plan to accomplish during the Sprint. As the team learns more day by day, updating the Sprint Backlog throughout the Sprint is expected. Note that the Developers commit to the Sprint Goal rather than the Product Backlog Items selected during the Sprint Planning. This mechanism provides flexibility to add, change, or drop the product backlog items as long as it doesn’t violate the Sprint Goal.

Does carrying over violate the Sprint Goal? It depends on how the team defines the Sprint Goal.

Ideally, the team should define a Sprint Goal that provides the flexibility to change the selected Product Backlog Items. Unfortunately, many teams, no matter whether they have been using Scrum for a long time, still define “finishing all the selected Product Backlog Items” as the Sprint Goal. If that’s the case, carrying over does violate the Sprint Goal. But why does finishing all the selected Product Backlog Items bring value to the customers? Could we carry over some selected but still bring value to the customers? Zero carry-over mindset would only bring the team to a Feature Factory instead of building a value-driven team.

Instead of overemphasise having a very “accurate” plan on selected Product Backlog Items (contradictorily, using Story Pointing by gut feeling), let’s focus on defining a Sprint Goal that provides the Developers with a direction to make things that bring value to the customers. You might not have to discuss or select any Product Backlog Items during the Sprint Planning. All you have to do is define a Sprint Goal. Once you have it, the team will collaboratively decide what and how to do next.

Accept that you won’t know everything until you work on it. Stop over-planning. Make a humble plan and adjust it when you learn more during the implementation. If this transition is too difficult, try shortening the Sprint length. It forces you to deliver values and get feedback more frequently. The shorter the feedback loop is, the more you can adjust your plan.