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.
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>
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:
Does overfilling the sprint’s plan magically stretch the time you have for it? I wouldn’t count on that.
Unfortunately, constant sprint overload quickly translates into such thinking:
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
Get actionable product building tactics in your mailbox, monthly.
No previous chapters
No next chapters