Bitter Scrum: A Task Board Gone Wrong

I remember reading Bruce Tate’s books on Java and EJB, which were all about anti-patterns, years ago and enjoying them. It was refreshing to read about how NOT to apply certain technologies. While there were plenty of books out there on how to do great things with Java and EJB (stop laughing), many of us using those technologies also found some not so great things we could do with them.

In much the same vain of Bruce Tate’s books, I give you a Scrum anti-pattern. Most Scrum teams will use a daily task board, either real or virtual. The task board contains a Sprint’s user stories and the associated user story tasks in the form of cards. It’s normal to see a few columns across the board along the lines of, “To Do”, “In Progress”, “To Verify”, “Done”, etc. The idea is for a team member to put his name on a task card and then move the card into the appropriate column. This is done throughout the day and especially at the daily Scrum. Below is an example of a Scrum task board.

Pretty simple. Below is the task board gone wrong. The difference is subtle and deserves an explanation as to why this is wrong.

Notice the extra column, “Today’s Work”. Having additional columns isn’t an issue, but this particular column presents a problem. The way the team uses this task board is to move tasks to “In Progress” when they’ve started work. But, since the team will sometimes start a task but then need to start on something else, the team decided they needed a column that showed what was in progress currently, thus the “Today’s Work” column. For example, in the daily scrum yesterday, Joe said he’s going to get Task A done. Joe moves this task to the “Today’s Work” column. Today, Joe tells the team in the daily scrum that he needed to start work on Task B for another story to help it keep moving forward, so he moves Task A to the “In Progress” column and makes sure Task B is in “Today’s Work”, as he didn’t finish that task yet. The problem is that we have impediments hiding under the “In Progress” column now. Rather than Joe saying that he was impeded from completing Task A, he moves it to a column (“In Progress”) that makes it seem like all is fine. All might be fine, but how do we know? It would be better to mark Task A as impeded. Joe could then make it clear to the team why he made the decision to not complete Task A in order to start on Task B. Everyone would see that Task A is in progress and it’s impeded (as opposed to simply “in progress”). The Scrum Master can help the team tackle this impediment.

Impediments aren’t inherently bad, but hidden impediments are. The task board gone wrong makes it far too easy to hide impediments while also making it difficult for the team to tackle properly. We all struggle with identifying impediments, so it’s important that we make sure our management tools are setup to help us make impediments visible and hard to miss.