If you’ve worked at a place that uses scrum (which is virtually ubiquitous nowadays), then you’ve heard of sprints. If you’ve heard of sprints, you’ve also heard the common refrain: “We can’t do this until the next sprint.”
“But it will only take an hour, and the next sprint doesn’t start for two weeks!” you might exclaim in a totally calm and professional manner.
“Those are the rules. Perhaps you need training from the agile consultant.”
“But why? That defies common sense!”
We are here today to answer that question and to provide tips for clearing the logjam when processes break down.
How to Improve Sprint Velocity
Step 1: Recognize If You Have a Problem
This might seem obvious since you saw the title of this article and kept reading, but to some, there’s nothing wrong with these types of conversations. If you don’t get to tell people no, what’s the point of a process anyway?
Let’s clarify: if an important task that is ready to work sits on the shelf, you have a problem. Inventory is one of the 8 Wastes of Lean, and stalled tasks are inventory.
Idle tasks drive up work in progress and cycle time, which slows down the pace of iteration and learning. Strictly locking task scope at the start of a sprint can cause delays and go against the spirit of scrum, which is to prioritize achieving higher-level goals.
When tasks are stalling out, you should take steps to improve your process.
Step 2: Measure Your Velocity
“What gets measured gets improved” is an overused statement, but it applies here.
It’s very easy for the problem of sprint boundaries delaying work to fly under the radar. To see just how big this problem is on your team, you should be looking at how long it takes to start high-priority tasks after they are filed, as well as how much time in-progress projects spend in an idle state.
You can manually look at data from your project management system or build DIY reports from data if it’s easily accessible in a system like Jira. More advanced solutions like Athenian (which provides data on time to fix bugs) and Allstacks (tracks project progress with advanced burndown reports and alerting).
Step 3: Try Sprint Planning
The intent of scrum is not to slow things down, but that can be the result. Sprint boundaries serve as a function for better planning, and forcing means wielding the stick when necessary.
If the marketing team wants a development task turned around by the end of the day for a campaign they’ve been building for a month, then saying no to avoid creating a moral hazard can be a good thing.
In this case, it forces them to inform the development team earlier so that their task can be implemented efficiently without interrupting other work in the future.
However, stakeholders are not the only planning offenders; unplanned tasks often come from within teams themselves.
If a team plans component A and finishes it before the end of the sprint but fails to plan the next component of a project, tough love might help them learn to better gather requirements in the future.
However, there are always going to be tasks that have a hard dependency on prior work, like fixing bugs in a module that is not yet written. Here, the forcing function of scrum forces you to delay work or break the process.
If dependent tasks are shorter than sprints (which inevitably happens), then you end up with a project timeline that looks like this:
Step 4: Adapt Your Process
Low-functioning teams may just throw their hands up and accept this problem as a way of life, but any high-functioning team has encountered this dependency issue and found ways to work around it. Here are some common approaches:
Option 1: Break the sprint
This one is the most straightforward: Just add the next task to the sprint and remove something else.
One downside that this causes is wasted planning effort for the other tasks that get kicked out of the sprint. Also, if you make a habit of breaking sprints, it may diminish scrum’s efficacy as a forcing function for better planning and lead to all the efficiency problems that scrum is meant to avoid.
This can be mitigated by making it clear that only the product owner can break the sprint, and it will only be done for urgent tasks that weren’t knowable in advance (e.g., critical bug fixes) and tasks with hard dependencies on other current sprint tasks.
It’s also important to give teams credit toward their velocity for tasks added after the start of the sprint; otherwise, they will resist this approach even if it is the right thing to do.
Breaking the sprint solves the immediate waiting issue. It is less than ideal but may be necessary for truly unknown-unknown urgent tasks.
Option 2: Work underneath the sprint
Regardless of what process you follow, there are always tasks so small that it doesn’t make sense to file them in your project management system. Things like “write this function” and “change that variable name” are typically handled by developers within the scope of larger tickets.
One way to break a dependency and schedule the next task in the current sprint is to underspecify it. Don’t know what bugs you’ll have to fix at the end of a project? File a “fix bugs for X” ticket and give it a half sprint’s velocity worth of story points.
This approach has all the obvious issues of under-specification. You lose all estimation and visibility into progress toward actual requirements.
Working underneath the sprint may avoid delaying work on a project, but it doesn’t solve the problem; it just sweeps it under the rug.
Option 3: Underfill the sprint
If you’re planning within a sprint and don’t know what tasks will emerge but want to start on them right away, you can leave room in the sprint to add them later. This is a less messy version of options 1 and 2, where you essentially acknowledge that the sprint boundaries are wrong and plan more work mid-way through.
While this is cleaner, it still has some downsides. The extra sprint headroom is undocumented, so it may look like the team is planning to get less work done or there is some space available for that last-minute marketing task!
The team might understand what’s going on if you underfill the sprint, but this approach can create issues due to a lack of transparency.
Option 4: Placeholders
In theory, the best way to plan is to utilize all the information you have — representing uncertainty where it exists rather than excluding low-confidence information. You can achieve this in a sprint by creating placeholder tickets for tasks that are not yet ready to work.
The beauty of this approach is that everyone can see that you intend to do the work, but that work will not begin until the placeholder has been replaced with tickets that meet the specification and estimation requirements of a normal task.
At the end of the sprint, as long as you ignore the original placeholders and treat the tickets that replace them as if they were in the sprint at the start, you can have a normal sprint retrospective and velocity measurement.
Step 5: Reduce Workload
If you eliminate delays from sprint boundaries and still experience long response times or slow-moving projects, your team may have too much work.
This is a topic for another day, but it’s important to recognize that no amount of process optimization can fit a camel through the eye of a needle.
The Bottom Line
Using placeholders mitigates issues caused by other methods of avoiding sprint-boundary delays without sabotaging the benefits of scrum.
However, there are still some fundamental limitations. If the amount of work for actual tasks is different than your best guess placeholder estimates (e.g., more bugs were found than expected), then you may need to add more tasks to the sprint or kick some out. Without a magic crystal ball, there really is no way around this — c’est la vie.
However, teams and managers need to recognize that a bit of uncertainty in each sprint is better than guaranteed inefficiency.
Try minware today
