How to handle when planned work is blocked and a developer has capacity to take on a new user story that may be too big

Question

Assume the following situation. All but one user story planned in a sprint is completed.

The remaining user story is blocked.

A developer would like to take on work in the highest priority work in the backlog that has been estimated.

Unfortunately, the story is bigger than the time remaining. Ideally, the developer would like to make an early start on work that will be planned for the next sprint.

What is the proper way to handle this situation?

Should the user assign the unplanned work to the next sprint? In this case, the active sprint does not include all the work that is actively being worked on (ideally, we want the active sprint to be the source of truth of what developers are working on)

If we assign it to the active sprint, then we will most likely have a spill-over. Everyone would prefer not to do this unless there is a straight forward way to distinguish spill over from planned work vs spill over from unplanned work.

What is the standard way for handling this situation?

Answer 1

Welcome to PMSE!

Good question. It may be a duplicate but I could not find it so I will answer. I can tell you how I coach teams to handle it.

Unfortunately, the story is bigger than the time remaining. Ideally, the developer would like to make an early start on work that will be planned for the next sprint

I coach to bring it into Sprint. Personally I believe that velocity is only useful as a measure over time. The velocity of a single timebox is not that important. Teams focus on it too much.

The real value will be in mitigating some of the deeper organisational clues which we can discuss briefly here.

Can the story be broken down further?

Can the story be broken down using one of the many story-splitting techniques? If so; break it down and take a portion into the sprint as a distinct, smaller story.

Do you have a 1-point bucket?

In the future, encourage developers to throw basic engineering tasks into an Epic or a bucket called the 1-point bucket. This is a constant supply of minor, niggling, low-priority or low value stories that can be used as a filler when developers are not ready to take on a substantial piece of complex work.

The 1 point bucket also serves as a store of work for junior or apprentice developers or new team members getting familiar with the technology such as a system architect trying to learn Python etc etc.

Can the developer contribute to the Sprint Goal without another story?

Before taking on another story, have you exhausted the ways that the developer can contribute to the current Sprint goal. Can they pair program, debug or test?

Can the developer make the next Sprint a success?

Can they improve the CI/CD pipeline? Do you have a support queue that needs cleared? Does the Product Owner need support? Can they refactor some aspect of the previous Sprint's? Is their a technical debt register to be investigated and planned? Is their another skill they can learn?

These are just some of the activities that a developer can use to add value to a team before taking on a large user story in the current Sprint