Two Simple Ways (and One Hard Way) to Tidy Up an Unusable Scrum Board
Is Your Board Unusable?
Does your team’s board have too many tickets? Do you have too many tickets? Does your team wind up rolling tickets over end of every sprint?
This is not how project boards are supposed to be, but is something I have seen one too many times. It is usually not the Project Manager or Scrum Master’s fault.
There are a lot of reasons for this. Your team could be empowered to go over your head, for instance. A higher authority stakeholder could be changing your goals mid-sprint while demanding nothing be derailed.
The Goal Of A Sprint
First we need to make sure everyone is on the same page of why teams do sprints and use boards at all.
Sorry Kanban people.
You measure in sprints to commit to an amount of work over a short period of time, to measure output against reality.
Your team wants to know, based on the backlog and emergent work realities, how long will it take to ship and entire product.
This is frequently not how boards and sprints are used. Sprints can get interrupted for many reasons, but if you do it too much, the whole effort will fail to deliver any value.
So what do you do?
Tidy It Up
If blowing it up is too much, it might be time to tidy up.
Get back to basics. Throw out the old shirts you don’t wear, so to speak. Get rid of the pants that you like but that don’t fit well.
Look at your columns. You really only need the classic three.
To Do, Doing, Done.
I can hear some folks out there. The development doesn’t like that. QA wants its own column, just for starters, and To Do gets so long we need a Sprint Backlog and a Selected column!
Do you though?
If your tickets are a manageable number, you don’t need all those extra tickets. Which makes the board easier to read.
Limit Tickets Per Sprint
Finally, you should be tracking how much the team can get done via all the standard methods. Burn down charts, sprint reports, etc.
But are you limiting the sprint planning to that? The active sprint should have a total of that number of tickets. Far too often I see sprints started that can never, in any reality, be completed.
There is no reality where Dr. Strange sees these sprints with this many tickets and story points being completed.
So limit the tickets.
This is also a chance to plan for previously mentioned emergent work. If you know your team completes 400 story points in a sprint, then go export your data and figure out how much comes from story points that went into the sprint after the sprint started.
One you know that number, let’s pretend it is 150, then you only plan for 250 story points of work for the team.
Blow It Up?
Typically if you’re in the situation of having a board that is nearly useless, you don’t have the authority to run it yourself, or you wouldn’t be in this situation.
However it could be time to propose blowing the whole thing up. Tear it down. Burn it to the ground.
If the ticket accrual has gone for multiple sprints, blowing it up provides a few values, so let’s cover two.
First, it enables all stakeholders to discuss what is the actual goal of the project. If the backlog is not indicative of the final release, this is an opportunity to dig in and realign around the reality of the situation. It is fair to say that no plan survives contact with the enemy, in this case the enemy being the real world.
Second, you get a chance to reset the team itself. If you’re blowing up the backlog, the team has been failing more sprints than it has been completing. The emotional burden of this on your team should not be underestimated.
The emotional burden on you, as well, should not be taken lightly.
Blowing up the backlog is a very expensive thing to do, however. Someone, maybe you, maybe the Product Owner, maybe the business owner themselves will have to dig in and commit to potentially days of planning work.
This can be a hard thing to do. They will want development to keep going. Why should the team stop? How could they not know it would take this long? Aren’t they professionals?
I have heard it all, and likely so have you.
You should really try to Tidy and Limit before you blow up your project, but don’t let it ride too long. I can’t tell you how long, but I generally give a new change to process two full sprints. One full sprint to get through the biggest pain points, another to see how it goes once you’ve accomplished that.