If you’ve ever been a Developer on a Scrum Team, you’ve probably experienced this moment: you’ve completed all of the work you originally planned for the Sprint, and there are still a few days left. What now? It might seem like a good idea to just pull more work into the Sprint, but that sometimes causes more harm than good.
I once worked with a Scrum Team that ran into this exact problem. On paper, it looked great: Developers were getting through their planned work early and grabbing new PBIs mid-Sprint. But over time, we noticed a troubling trend.
When we reviewed the Sprint Backlog during the Sprint Review, more and more of the items in the Sprint Backlog at the end of the Sprint were only partially done. They didn’t meet the Definition of Done and therefore weren’t part of the Increment.
The cause? All that mid-Sprint “bonus work” was getting started but not finished.
As a result, we were carrying more and more half-finished work by the end of Sprint, and this limited our Agility. It made it harder to change direction every Sprint. We weren’t delivering in small, valuable Increments anymore—we were just piling up partially completed tasks. The mess compounded every Sprint, and the team’s ability to deliver predictably took a hit.
Something had to change.
The Team Agreement: A Smarter Way to Use Spare Capacity
During our Sprint Retrospective, the team decided to create a simple, clear agreement for what to do if a Developer finished early. Instead of automatically pulling more work into the Sprint, they would walk through this check list before deciding whether to pull in more work - or not.
Here’s the list they came up with:
Do any teammates need help?
Completing work that’s already in progress strengthens the Increment and avoids adding more half-finished items.
Are there any production support requests that require attention?
Many Scrum Teams support customer requests themselves during the Sprint.
Is there refinement work to be done?
Could you help the Product Owner and Developers clarify upcoming Product Backlog items, so the team is better prepared for future Sprints?
Is there quick technical debt you can address?
Look for something that can be fully completed—built, tested, and meeting the Definition of Done—before the Sprint ends.
Would training benefit you or the team?
Is there a course, a skill gap, or a tool you could learn that would help the team deliver more value in the future?
Can you explore process improvements?
Take this time to reflect upon your own work. Is there a better way to accomplish it?
Does the Scrum Master need any help?
Ask the Scrum Master if there is any help that they might need. For example, you may be able to lead the upcoming Sprint Retrospective.
Is there any work in the Product Backlog that you can complete to Done within the Sprint?
If so, great—but only if it can truly meet the Definition of Done by the Sprint’s end.
Go home early.
If you get through all of these steps (and yes, it does happen), then maybe you should just go home early. After all, there may be other days where you need to work late, so this may be your chance to balance the scales.
Why This Works
This approach helped solve the team’s “half-done work” problem because it put finishing above starting. It recognized that delivering small, Done Increments each Sprint is more valuable than starting more work that won’t be finished in time. It also encouraged Developers to invest in team health, quality, and overall readiness.
Bottom line: If you finish early, be thoughtful about where you are spending your time and resist the urge to just start the next thing.
*****
Rebel Scrum is the host of the annual Scrum Day Madison conference. The theme for this year's conference is Small Steps to Big Value.