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

Overfilling the sprint’s plan won’t magically stretch time and the team’s capacity. Even though it’s a commonly known truth, human beings tend to be too optimistic, which leads to major problems. We’ve been through that, solved that problem, and have a validated list of tips on how to cope.

readtime

TL;DR

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.

Next challenge: how to form daily plans

This experience also teaches 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.

Adam Machlejd
github
Scrum Master & Agile Coach
Olga Gierszal
github
Editor

Read next

No items found...

Get actionable product building tactics in your mailbox, monthly.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
brainhub rates and rerences

Bye, waterfall. Hello, BizDevOps.

Join 1,200+ other tech leaders and get monthly insights on how to:

  • build superior products that users love
  • release software fast, often, and within budget
  • avoid tension between product and engineering teams
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

By submitting, you agree to receive our BizDevOps newsletter.