0

Sprint Goal is a sacred thing in scrum - it's the main priority of the sprint, and all developers shuold work together towards achieving it. Failing to achieve it is bad, and shouldn't be allowed to happen.

What should happen however when that is assured and there is still spare dev power in the team? That is a possibly common occurrence (given you would err on the side of achieving Sprint Goal while planning), and I couldn't find anything in scrum guide detailing what to do.

  • You could add a new task they pick up to the sprint - but that is scope change, one that carries a serious risk of becoming a spillover
  • You could let the developer just pick up a story that's not part of sprint - but than how do you track the work, that story does not show up on the sprint board, has no bounds on when it should be achieved and generally seems to be outside the system
    • you could only let devs pick stories that can be finished in the sprint goal - at the risk that last one-two days of the sprint there will be no such stories.
2

If, during the Sprint, after selecting enough Product Backlog Items for the full Sprint, the team has met the Sprint Goal and all of the selected Product Backlog Items are Done, it's up to the team to decide what to do.

I'd be hesitant to pull more work from the Product Backlog. The ordering of the Product Backlog may change as a result of the Sprint Review, which would make any unfinished work not only "spillover", but also waste if it's not done. If this is selected, the Product Owner can help pick something that is likely to still be at the top of the Product Backlog at the next Sprint.

I'd focus on things that can help the team's performance. Refining work in the Product Backlog. Process improvements that need the Developers' attention. Identifying and quantifying technical debt that may be too big to just fix. Finding ways to improve the Definition of Done, which may require some kind of technical enablement to make it efficient. Learning new skills to become more cross-functional.

4
  • First two paragraphs is what was done. It is up to the team what to do now, that's what I'm seeking advice on. So do I understand your last two paragraphs correctly - you recommend not taking any work from the backlog and focus on administrative tasks like investigating and preparing new stories, or just self-learning?
    – Deltharis
    Nov 19 at 11:04
  • I think the last two paragraphs are the most helpful here. Nov 19 at 11:41
  • @Deltharis I can edit out the first part. From the question, it wasn't clear if the Sprint Planning only included what was necessary to reach the Sprint Goal or if the Sprint was planned close to capacity. But yes, my ideal would be to focus on "administrative tasks". Not only are some of these (refinement, learning) valuable, but having slack can help the team keep productivity up in the long run. Get away from the PBI factory and to where delivering value is important.
    – Thomas Owens
    Nov 19 at 11:57
  • 1
    @Deltharis, what is best to do depends also on how much time is left. If all work went extremely smooth and there are multiple days left in the sprint (or at least ample time to finish one of the next tasks on the product backlog), then it makes very much sense to pick up that next task. If there is less time, then it would be more efficient to work on some administrative work. Nov 21 at 11:08
1

There are lots of options for using up leftover developer time, including:

  • Tackling technical debt
  • Improving automated regression test coverage
  • Improving documentation
  • Looking at the product backlog to see if there is preparation work that can be done for the next sprint
  • Learning time
  • Knowledge transfer
0

The developers should discuss with the PO what additional work they can take on. One common practice is that during backlog refinement the PO assigns priorities to items on the backlog that aren't yet taken into a sprint. The top priority items are the obvious ones to consider adding to the sprint if the team has sufficient bandwidth.

3
  • My main point in this question is - what if team has spare bandwidth (devs need something to work on), but there is no guarantee that any story from the backlog can be finished with that bandwidth (so taking the story into the sprint is iffy at best)
    – Deltharis
    Nov 19 at 10:59
  • @Deltharis Split the story or create a new item
    – nvogel
    Nov 19 at 11:09
  • That's possible if sprint goal was finished way in front of schedule (suggesting problem in planning). But if what remains is 1-2 days than it's not always possible to split off part of work that can reach definition of done in that time.
    – Deltharis
    Nov 19 at 11:27
0

No stories should come in, and no stories should go out of a sprint backlog after the sprint starts. For utilization of the resources, you can introduce a second, non-binding backlog into the sprint. I name it the "Road Runner's Backlog". When a developer's work is completed, that developer can start working on a story in the Road Runner's Backlog without disturbing any other team member.

To better understand what I propose, you can read my article What Happens When Your Sprint Backlog Is Out Of Items?.

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.