I get most of Scrum. However, I can't get my head around what to do with work in progress at the end of a Sprint.

If we are working in a swarm, we can defer the end of a Sprint, or bring it forward if we don't think we have enough time. However, when working as individuals or in pairs, not every one finishes at exactly the same time. Therefore some people will be sitting around, or producing work that cannot be finished.

As a developer I hate it when I am halfway through my 7th bit of work, and the Sprint ends. If the unfinished work is selected for the next Sprint, all is good; but if not, then I feel disheartened. Even worse is when it is selected in a later Sprint. (This seems to go against the low work in progress philosophy).

In the past I adapted our practice to focus on low work-in-progress, and regular review (but no Sprints). I later realized that this was Scrumban.

Am I missing something? I would like to get a better understanding of pure Scrum. (I know we are supposed to adapt it, but understanding it first is also a very good idea).



Don't plan or start work that won't fit into the Sprint. Decompose any remaining work further until it fits within the current Sprint, or let the team figure out what backlog items to descope for the remainder of the Sprint while still meeting the Sprint Goal. Then reallocate any excess slack to process improvement.

Any work that remains incomplete at the end of a Sprint is re-estimated and placed back onto the Product Backlog as future work to be re-prioritized. The Scrum Guide says:

All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.

So, unless work is related to the Sprint Goal, or to continuous process improvement, tail-packing work into the Sprint is often a wasted effort. Don't do that.

What's Missing: Goals and Slack

Am I missing something?

Yes. What you're missing is the focus on a Sprint Goal. The Scrum framework requires a central coherence to tie all the work of the increment together.

The goal of a Sprint isn't to complete lots of tasks. The goal of the Sprint is to deliver the Sprint Goal!

Once you shift your focus to a coherent goal, the tail-packing issue you're experiencing is surfaced as waste (in a Lean sense) and quite likely a variant of the 100% utilization fallacy. It also highlights that much of the team's work is not cross-cutting enough, and that your team itself may not be sufficiently cross-functional or self-directed enough to address continuous improvement issues when they truly have nothing else to do.

"Idle" time is very rarely actual waste in the Lean sense. Downtime and slack are essential to agility, and provide essential opportunities to improve tooling, testing harnesses, equipment, or other aspects of the team's process and infrastructure. Skimping on slack is often one of the key predictors of suboptimal performance for queue-based frameworks, and Scrum is no different.

Alternatives to Tail-Packing

It's worth mentioning that in 20+ years of Scrum and other agile practices, I've rarely seen excess slack to be a real, long-term problem for teams with a healthy inspect-and-adapt process. Instead, I've generally seen teams that struggle with having a reliable product delivery cadence improve by adding slack and avoiding tail-packing.

Rather than tail-packing your work, the team should generally plan to gently undershoot their capacity for the Sprint. This will generally result in a modest amount of slack that can be repurposed to evergreen quality and process work, or (as is more often the case) simply result in better quality as team members repurpose excess slack for code (or product) reviews, testing, documentation, and Sprint demos.

Some teams also put evergreen backlog items into the Product Backlog so that Sprints that radically undershoot capacity can peel off additional work. You can also work with the Product Owner to move up Backlog Refinement to decompose additional work that can fit into the remaining time box. In cases of truly egregious amounts of excess slack, the remaining time can be spent on workshopping better estimation techniques to improve Sprint Planning and Backlog Refinement in the future.

Another way to avoid tail-packing is to increase swarming, self-direction, and cross-functional activities within the team. Rather than tasking work out to individuals, working as a group on features rather than tasks often yields better results. It puts more eyes on the work, and creates a better environment for collective ownership of the increment than task-oriented assignments.

In Scrum, the whole Scrum Team is responsible for meeting the Sprint Goal. They aren't just responsible for their own tasks! If the team has not yet met the Sprint Goal, but aren't saying to one another:

I've finished X earlier than tomorrow's Daily Scrum; can I help you finish Y today?

then you don't yet have a mature agile team. If there's work remaining on the Sprint Backlog, it's usually best to complete all current work-in-progress before starting a new work item. Even when not, the whole team should be coordinating dependencies for the Sprint Goal at least daily, which makes what work should be done next self-evident when discussed as a group.

Use the Retrospective

The Sprint Retrospective is where this issue ought to be discussed as a team. Discussions about how to estimate capacity better, how to collaborate more effectively, or how to optimize the teams process should be done at least once per Sprint in order to provide a tight feedback loop.

If you have extra time within your current Sprint, use some of that slack time to examine your processes and discuss alternatives. Time spent improving your process pays large dividends over a long-running project, and even small improvements paid early on can represent a significant return on investment through the magic of compounding efficiencies.

| improve this answer | |
  • 3
    Can you explain what the term "evergreen" means here? I'm not familiar with it. – Erik Apr 17 '19 at 10:53
  • 1
    @Erik In context, "evergreen" means recurring or never-ending. Chores, clearly-defined process improvement tasks, and non-functional optimizations typically fall into this category, but there are certainly others. Some practitioners believe in making all work visible, which means making sure the work is reflected on the backlog rather than remaining invisible or being bundled into roll-up tasks. Abuse of evergreen stories can definitely be an anti-pattern, though, as can abuse of any process or practice. YMMV. – Todd A. Jacobs Apr 17 '19 at 14:29

As you say, not every team member will finish the planned work at the same time. But as long as you don't overload the sprint then there is a good chance they will all have finished by the end of the sprint.

The question is, what does a team member do if they finish early?

Some possible suggestions:

  • Help other team members that are still working on sprint backlog items.
  • Take a look at the top of the product backlog and see if there is any preparation that can be done for the highest priority backlog items. This should help with sprint planning and backlog refinement.
  • Work on tackling technical debt.
  • Add automated regression test coverage.
  • Learn new things. Perhaps read a book about a promising new technology.
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.