Teams That Finish Early

One of the sections I taught during my Scrum@Scale training was Scrum PLOP. Yeah it's a weird name, but it is an extremely helpful resource for Scrum teams. Scrum PLOP stands for Pattern Language of Programs and is a set of resources and patterns that are helpful for successful Agile teams. I want to take a brief moment and talk about one of the patterns that, at first might seem counter-intuitive, but if implemented can be a powerful practice for your team.

Teams That Finish Early Accelerate Faster

Successful scrum depends on teams that are working at an infinitely sustainable pace. But successful Scrum is about more than just delivering work in a given sprint, it’s about developing enough understanding of work in the backlog to be able to successfully and confidently commit to work in a sprint.

In short, the pattern states:

“Take less work into a Sprint (than the previous Sprint) and aim for a less ambitious Sprint Goal."

This might seem counter-intuitive to a happy customer. But, teams that have enough bandwidth in a spring to think about what’s coming next, to work on improving their skills, and handle the inevitable interruptions are able to accelerate their development over the long time.

Don’t believe me? There is data behind this, check out Jeff Sutherland and Igor Altman’s paper titled “Take no Prisoners: How a Venture Capital Group Does Scrum”. This details work performed by Openview Venture Partners in which they noticed that teams that finished a sprint early accelerated faster. They had time to clearly think about what they were doing, remove impediments, and bring more into the backlog from next sprint.

This pattern is helpful if your team is struggling to complete sprints, is struggling to refine a backlog item enough that they feel confident in committing to it during a sprint, and pairs naturally with a couple of other patterns that I'll discuss in upcoming posts (Interrupt Buffer and Yesterday's Weather to name two).

How can we make this happen?

When I coach teams around this pattern, I encourage them to do a detailed tracking of where they spend their time in a given sprint. If they are struggling to complete their sprint goals, then we dial back their next sprint and perform the measurement again. The goal is to make sure the team is completing their sprint goal with adequate time to handle interruptions, refinement, and continuous improvement. Once the team finds a commitment level that allows them to complete each of these things, we make sure they are frequently inspecting and adapting to find ways that allow them to take more into a sprint while having time for the other team goals.

In short, start small, make sure the team has effective ways of inspecting where they are spending their time (I say team, because this is a team goal, not something management is dictating or monitoring). Once the team has clear empirical evidence, it performs a series of experiments (mainly decreasing what they take into a  sprint) and adapt once they see the results of these experiments.

AppCon 2019 How Do You Practice Refactoring Code?