Top 5 Causes of Sprint Carry Over

Most teams say they are doing Scrum, but they really aren’t. One of the core elements of Scrum is something called the Potentially Shippable Product Increment (PSPI), or getting to Done Done. Having an increment of your code/product potentially shippable at the end of every Sprint is the key to becoming predictable. And becoming predictable is key to being faster. If you can get a PSPI every sprint, your team will realize these three benefits:

1. Predictable delivery which will build trust with your stakeholders
2. Once you are predictable, your team will have measured improvement and gain speed
3. Being “Done Done” at the end of every sprint will enable adaptability and allow the business/ product owner to change priorities as the market demands

The goal at the end of every Sprint is to be Done Done with everything we planned in Sprint Planning. That means developed, tested and bugs fixed. The goal for Scrum teams should be over 80% of all Sprints complete 100% of their goal. Note I did not say every sprint that we only get 80% done and carryover 20%. Most of our Sprints we should get everything done. I find many teams get less than 60% of their plan done, carrying over 40% into the next Sprint.

Let’s explore the top reasons why teams carry over work on a consistent basis.

#1 – No Tasking

Sprint Planning has two parts: What and How. Many teams only talk about the What, the scope. They review stories and determine which stories they will do during the Sprint, but they don’t task them. This is creating a Commitment without an actual Plan. The event is called Sprint Planning, not Sprint Committing. The action of tasking is how we actually create a plan. We encourage teams to create tasks no bigger than a day, which in turn encourages design discussions to actually think through the work before starting. This might prompt more scope questions to get a better clarification of the work. Which ties into our second problem…

[If your teams have a lot of carryover each sprint, it could be a sign you’re not predictable yet. Download the 8 Common Pitfalls of An Agile Transformation to help identify trouble spots and areas of improvement.]

#2 – Don’t Understand the Work Before Planning

I find many teams start the work before they really understand the requirements. How can we commit to a plan with confidence if we don’t really understand what we are committing to? This happens because often Sprint Planning is the first time many of the team members have even seen the story they are to work on. This makes Sprint Planning more of a surprise party than a planning event. And we know how those spontaneous beings we call developers love surprises.

A best practice is to have the team do Backlog Refinement on a regular basis in preparation for upcoming Sprints. The whole team needs to be there so everyone is up to speed on the upcoming work and can ask questions. This also allows the Product Owner time to get answers to the team’s questions, versus getting those at Sprint Planning and not answering until halfway through the Sprint. During the Sprint we will always have scope clarification, but we do not want Scope Change.

#3 – Too many Dependencies

Many teams get into a Sprint and realize they have a dependency on another team and a story gets blocked. This could be due to a couple issues. First, do we have all the people we need to get the work done on our team? Second, should we have even pulled that story into our Sprint?

We want cross-functional feature teams, not component or architectural teams. The organizational team structure will help us minimize the number of dependencies outside the team and redirect them inside the team. If they are inside the team, we are only blocked by each other, which we can manage.

Also, we encourage teams to create a Definition of Ready (DOR). The DOR will help the Scrum Team agree on what state a story should be for us to pull into our Sprint. Some standard items might be:

• The story has been reviewed by the whole team and Acceptance Criteria understand
• There are no open major questions on scope
• The story is sized and no bigger than X
• We do not have any outside dependencies that may block our ability to finish this Sprint

Having a DOR will help the team and PO stay aligned on what is needed get a Story ready for our next Sprint.

#4 – No Known Velocity

You cannot improve what you cannot measure. We encourage teams to size their backlog in story points and measure velocity. Velocity is the average of how many points completed in previous Sprints. This allows the team to use “yesterday’s weather” to predict the future. However, if you do not size your backlog prior to Sprint Planning, then you will not be able to use this a predictive measure. We encourage teams to estimate story point during Backlog Refinement as a full team exercise. Once again, this gets everyone involved and helps prepare the team to plan during Sprint Planning. Once the team can measure velocity, then they can tune their engine. For example, I had a team that planned 20 points and got 15 done, they then planned 20 and again got 15 done. How many should they plan next Sprint? Right, 15. They should do 15 and get predictable and then start trying to do more. You have to go slow to go fast.

#5 – Working in Silos

I see many teams working in mini-waterfalls. Here is a common “bad” practice: A team of 4 developers pulls in 4 stories into their Sprint. Each developer works on their own story for almost all of the Sprint, each working in a silo. When working this way, developers question:

• Why should they break their work down into tasks instead of just having an 80-hour task?
• What’s the point of the Daily Scrum if I am just focused on getting my stuff done?

The goal of Scrum is Shared Team Ownership, where everyone works together with a shared commitment to the success of the Sprint. If we work in silos in a waterfall, we have a high probability of carrying work over into the next Sprint and big items.

Our goal is to prioritize, focus and swarm. This requires us to task early to coordinate who works on what. To be effective at swarming, we want some level of knowledge transfer during Sprint Planning so everyone understands what is involved. Swarming will lead to higher quality, but it also allows us to mark items “Done Done” early in the Sprint. Also, if we are working on Stories in priority order, it will guarantee we get the highest value items done.

Most teams want to move faster, however, if they aren’t predictable, they won’t get there. Team Backlog Refinement and Sprint Planning (with tasking) are the key elements to success. Most teams try to save time by shortening these meetings or involving fewer team members, but that only takes longer to get stories done and leads to be more rework. Remember, Stop Starting and Start Finishing. It is not about how much work you have in progress, it is about how much value you deliver at the end of every Sprint.

If your teams have a lot of carryover each sprint, it could be a sign you’re not predictable yet. Download the 8 Common Pitfalls of An Agile Transformation to help identify trouble spots and areas of improvement.