The Sprint Will Hold! ... or How to Deal with Sprint Overload

As you probably experienced, sprint overload can severely affect the team. Team members may stop taking the plannings seriously, start being stressed, and rush – which often leads to omissions. At some point, micromanagement becomes indispensable, and the team loses credibility.

The problem is way too hard for the “stop doing it” advice to work.

But, luckily, when properly managed, the sprint overload problem can be solved effectively.

Ready for the story of a team that struggled with the overload for months and beat it in 6 steps? Then let’s dive in.

<span class="colorbox1" fs-test-element="box1"><p>Project: Business Intelligence - insurance</p><p>Team: 6 Ppl.</p><p>Framework: Scrum</p></span>

“We still need to do it” so… let’s stuff sprint’s backlog like it was a holiday turkey!

Our team had an issue: sprint plans were constantly overloaded with tasks that couldn’t be possibly delivered by the end of the sprint.

Stuffing sprint’s backlog, like it was a holiday turkey – the more the better – is a strange and dangerous way of planning, yet it happens way too often.

Not to cause any misunderstanding: every sprint plan should utilize as many resources the team has for the sprint as possible. The problem starts to occur when you plan over your team’s capacity by 50%, 100%, or even more.

Sprint overloads often happen because:

• high business pressures make teams feel they have no choice but to accept and deliver all tasks, or else they will face serious consequences,
• teams estimate too optimistically — either to please the stakeholders or because they weren’t trained enough,
• Product Owners are afraid of the underuse of the available resources (time, people’s skills, etc.) and potential budget waste.

Does overfilling the sprint’s plan magically stretch the time you have for it? I wouldn’t count on that.

Sprint overload consequences: how fake plans fail?

Unfortunately, constant sprint overload quickly translates into such thinking:

• A team is not treating plans seriously.
• They don’t commit to plans.
• And they aren’t credible when they form them.

As a consequence, stakeholders and the Product Owner don’t perceive the team’s plan as credible. They maintain pressure on the team, treating these plans as the only way to make sure that no one is without a task (scary sounds).

If plans can’t be committed to, what’s the incentive for each team member to push as many PBIs (product backlog items) to DONE, before the sprint ends? Limited or none. The team is focusing on doing instead of delivering, and neither real velocity nor capacity are known.

Solution? Always the same: to stop doing that. But it’s not as simple as it sounds.

6 steps to stop overloading once and for all

Our Scrum Master decided to deal with the overloading problem effectively, and once and for all.

The plan was created, and the first step was to talk to the whole team and the Product Owner. But, let’s not get ahead of ourselves.

Eventually, it took 6 steps to get out of the overloading trap. Here they are:

Step 1: Build a shared understanding of a problem

Scrum Master started with coaching the whole team and the Product Owner on what was happening when they were planning way over capacity. The problem was that the team was ruining its credibility. Their plans couldn’t be trusted, which prompted micromanagement both from the Product Owner and stakeholders. If they were to plan a very important sprint, they wouldn’t know how much they could actually deliver.

Step 2: Use velocity readings to create a tangible plan

Velocity readings were most probably lower than the team’s possibilities, but they were treated by the Scrum Master as a baseline to which the team should plan the next sprint. He very strongly asked not to plan any single point over the team’s current velocity. Although this meant that the team would surely underdeliver, the most important idea behind it was to create a tangible plan and deliver it completely.

Step 3: Focus on daily meetings

During the sprint, Scrum Master strongly focused on daily meetings and on verifying if team members were concentrating on closing tasks, rather than opening new ones. To do so, he was pointing out the tasks that were not mentioned by anyone, that had to be reviewed, tested, or released, yet no one picked them for that day – and asked to pick them prior to new ones.

Step 4: Open new tasks only when nothing else is possible

In the second half of the sprint, even if there were no tasks to review, test, or release, he asked team members to do pair-programming when possible, and to open new tasks only when nothing else was possible.

Step 5: Recalculate velocity

The team delivered the whole sprint plan and they had to take some more from the product backlog in the last days of the sprint. Velocity grew a bit and was recalculated.

Step 6: Repeat, gather data, and learn

The same process was repeated for a few sprints until the team had real data about their velocity, and they learned how to plan based on it.

Results

After several sprints, the situation has stabilized. The team’s plans were deemed credible, which lowered any micromanagement to a minimum. Stakeholders had a much clearer understanding of what was possible to achieve with the team over time, and they wouldn’t pressure the team as much as their increments met their plans.

Scrum Master coached the team to always plan just a little bit over capacity and to always have some spare tasks, no must-haves, for the last days of the sprint, to avoid the need to make additional planning sessions with the Product Owner.

Dealing with Sprint overload and planning – Tips from industry experts

Every project, team, and case is different. 

Just because one approach proved successful for multiple teams doesn’t make it a universal solution. 

In this domain, practical hands-on experience is key.

That’s why we asked 3 highly esteemed experts about what they think about dealing with Sprint overloads and effective planning.

Question 1: In your experience, what’s the best approach to take when dealing with Sprint overload?

Gagik Sukiasyan, Group Sr. Manager, Software Engineering at Adobe says:

<blockquote><p>I think it’s best to start with detailed capacity planning alongside velocity planning. For example, the teams I work with, make use of a spreadsheet-based calculator to get a better understanding of our allocation and available capacity. Once we've measured our capacity and velocity, our product owners make sure the total of story points in our Sprint backlog is only slightly higher than the teams’ average velocity.</p></blockquote>

<span class="colorbox1" fs-test-element="box1"><p><strong>Bonus resource:</strong></p><p>Gagik Sukiasyan has kindly shared his spreadsheet template under the link below — make sure you check it out.</p><p>Download "Velocity and capacity planning calculator"</p><p>More information on how to use the calculator can be found here.</p></span>

Paweł Huryn, Product Leader and Author, shares:

<blockquote><p>It's essential to realize that Product Backlog items selected for Sprint are not a commitment. The only goal the Scrum Team should focus on is the Sprint Goal. Developers should inspect their progress towards it on a daily basis.</p><p>The Sprint Goal must provide flexibility so that Developers can negotiate with the Product Owner on the best way to achieve it, if necessary.</p><p>In my opinion, achieving Sprint Goals on a regular basis is one of the best measures of a team's health. Mistakes will happen, but as time goes on they will learn to plan their work better and better. Proper use of the Sprint Retrospective is key.</p></blockquote>

Kevin Bendeler, Product Leader at Heroes Corp and Product Owner Digital Enterprise & User Experience at Alliander, thinks:

<blockquote><p>It's fundamental for Product Owners to avoid Sprint overload. A good rule of thumb is not to take on extra work in the sprint without dropping something else. It's critical this new work contributes in a more significant way to the sprint goal than the work that's exiting the sprint. Finally, the work that's being scrapped needs to not have started. You'll lose momentum by stopping work that's already started and lose even more through context switching.</p></blockquote>

Question 2: If you were to give your top 3 tips for effective Sprint planning, what would they be?

Gagik Sukiasyan, Group Sr. Manager, Software Engineering at Adobe says:

<blockquote><p>My advice is to divide planning into four main stages:</p><ol><li>The product owner presents the sprint backlog and describes the next increment the team should aim to deliver.</li><li>The team looks at their velocity and capacity readings to understand their capability.</li><li>The team breaks stories into sub-tasks and assigns them hourly estimates. Then, chooses the subtasks to include in the sprint.</li><li>The team and the PO once more look at the Sprint goals, adjust them to the tasks they have taken, and commit to delivering that scope.</li></ol></blockquote>

Paweł Huryn, Product Leader and Author, shares:

<blockquote><ol><li>Leaders lead with vision. So you need to start with WHY. Why is this Sprint valuable? What value will it create for the customers and the business? How will it contribute to a larger vision?</li><li>Let Developers pull the work instead of pushing it into the Sprint. In particular, Developers have the right to reject the top Product Backlog Items if they are unsure of their scope or if they can implement them.</li><li>Velocity, if used, is an internal metric. It should never be shared outside the Scrum Team.</li></blockquote>

Kevin Bendeler, Product Leader at Heroes Corp and Product Owner Digital Enterprise & User Experience at Alliander, thinks:

<blockquote><p>Most Planning sessions revolve around the work. The outcome of the sprint is then defined as the result of the work. This way of working inevitably leads to failed sprints because every change means you fail your desired outcome. That's no way to live.</p><p>As a product owner, you want an outcome. So make it abundantly clear to your team what that outcome is. That's your start. The work will flow from that outcome. You can, of course, order your backlog in a way that reflects that outcome, but you should be in a constant conversation about how best to achieve it. That means a planning session can be short, and the team remains flexible throughout the sprint. Without losing sight of the ultimate goal.</p></blockquote>

Next challenge: how to form daily plans

This article taught us that plans in Agile, although commonly deemed secondary, are, in fact, as important as in the Waterfall approach – only formed for the short bursts of work.

But when you already know how to plan the whole sprint adequately… Daily plans and meetings emerge.

How to form daily plans to avoid conducting “status meetings”? Looks like another challenge.

However, that’s a subject for another article, so stay tuned! Sign up for our newsletter to be informed about the release.