6 min read
August 25, 2022
Adam Ulery
A long time ago, on a Scrum Team far, far away…
There is turmoil at Corellian Engineering Corporation, makers of cargo starships. Scrum Team A-Tano, which recently learned the value of a Definition of Done, is on day seven of a two-week Sprint. One of the developers, Lilly, begins her contribution to the Daily Scrum:
“Yesterday, I completed all the dev work for the hyperspace motivator relay API. It’s ready for testing. All of the remaining tasks this Sprint are in progress, and there’s nothing I can do to help anyone else on the team, so I pulled in a small user story to work on. I added it to the board, and I figure I’ll be done with my work by the end of the Sprint.”
Read More: 5 Reasons Why People Resist Agile Transformations
Inez, the Scrum Master, replies, “Team, is that the best course of action for us to take?”
What do you think the team should do in this situation? Why did the Scrum Master ask Lilly and the rest of the Development Team this question? Is it acceptable for a team to pull new work into the Sprint once the Sprint has commenced?
As Agile coaches, we see this all the time. Scrum team members often wonder what they should do when they run out of work during a Sprint. Sometimes, it’s individuals, like Lilly, who get done sooner than planned. Other times, the Sprint Goal turns out to be easier than the team collectively thinks, and everyone gets done early. So, what should a Scrum Team do when it discovers that there’s more capacity than work planned?
First, Do No Harm
The first thing to think about is the Scrum Guide’s counsel to, “Make no changes that would endanger the Sprint Goal.” The purpose of a Sprint is to create a potentially shippable, “Done” product increment; no team member should add work to the Sprint of any kind that might endanger that effort—whether because it will cause integration issues, because it could break existing functionality, or because it could impact work still going on in the Sprint.
Whatever decision is made, it has to involve the whole Scrum Team—Product Owner, Scrum Master, and Development Team members.
Here are some things a Scrum Team can do when it looks like it is running out of work during a Sprint:
1. Pull a new Product Backlog Item into the Sprint
As a Scrum Team, it’s important to discuss what item from the Product Backlog should be pulled into the Sprint. A healthy Product Backlog will be prioritized and have ready items at the top, which can be pulled into the Sprint Backlog.
The Scrum Team should choose the highest priority item that can be finished within the Sprint timebox. That could be:
The Scrum Team should plan the item as they would during Sprint Planning. This involves tasking the item, estimating the tasks, and agreeing to the order in which tasks are most likely to occur for maximum effectiveness.
The Product Owner should communicate this change to key stakeholders, as needed.
Things to beware of:
Read More: 4 Ways Scrum Helps You Welcome Changing Requirements
2. Sharpen your Axe (or your double-bladed lightsaber)
Team members often feel like time not spent working on product backlog items is wasteful. But there is value in taking some time for professional growth. Team members who experience a little slack time have more options than starting work on new development:
3. Backlog Refinement
Especially if the end of the Sprint is looming—the day before, perhaps—getting more work into the current Sprint is less important than being prepared for the next one. To set themselves up for success, team members can spend time reviewing the higher priority backlog items to make sure that they are sufficiently independent, appropriately sized, and clearly understood.
Scrum Team A-Tano
What does Scrum Team A-Tano decide to do? After the Daily Scrum, the team agrees that there is nothing more Lilly can do to help the team reach its Sprint Goal. They agree to spend a couple hours reviewing their completed work to ensure that it meets Corellian’s quality standards and the team’s Definition of Done.
Once they are satisfied that the Sprint Goal has been met and the work is up to the team’s standards, the Product Owner helps them select a high priority PBI that is small enough for the team to complete within the Sprint. The Development Team immediately begins to work on it. They finish the item according to their Definition of Done with little time to spare at the end of their Sprint.
On the last day of their Sprint, they conduct the Sprint Review, which includes the latest addition to their Sprint Backlog. By upholding their commitment to producing a high-quality product increment without letting work fall through the cracks, Scrum Team A-Tano’s Sprint is successful—and there is temporary balance in the universe.
Interested to see how your sprint reviews stack up? Take our free assessment.
Learn how we can help you scale agile across your organization.
Share this content: