I recently took a short course on the Scrum Alliance website to fulfill part of my Scrum Education Units (SEU) requirement called “How Successful Teams Limit Work In Progress”. This course really resonated with me because the anti-patterns that they discuss in the course are all things I have experienced on software teams. In Scrum, the main idea is to pick up a ticket and move it all the way across the board until it has reached Definition of Done. On high velocity teams, what I have experienced is people trying to juggle several tickets at once, where they are all in various stages of “In Progress” (some of them haven’t actually been started), and then at the end of the sprint, about 25% of those tickets will carry over to the next sprint. The Scrum Alliance course talks about how this method of working actually results in less work completed rather than more.

Nevermind the challenges of context switching between all those tasks for the person who is working on all of them, but the strain this puts on the rest of the team members is tremendous. It’s a really frustrating experience to be looking for a ticket to pick up next and see it fly off the “On Deck” column, only to sit in “In Progress” for the next sprint or two. Or when there are dependencies between tickets and your ticket is now blocked because someone else is has 5 things “In Progress”.

There will definitely be times when it’s appropriate to work on a couple things at once, but the idea is to limit the number of things in progress so tickets can be all the way complete and across the finish line. This helps protect the sprint goal, ensures other tickets are available and unblocked, and creates a fluid, sustainable Scrum process.