When I was a scrum master I wasn’t satisfied with the typical scrum board design. This has columns for each status. Each story card would move from the Not Started column, then into In Progress, then into the In Test column, before finally arriving in Done. 80% of scrum boards I’ve seen follow variations of this basic formula and by and large, it works pretty well. But in the spirit of continuous improvement, my scrum and I developed this concept and made it even better.
It’s ok, but it’s not great
The typical board I just described is great for showing overall status and ownership by sticking an avatar on the card. But it has some shortcomings.
- It doesn’t show the original size / number of story points / estimate of any card.
- It doesn’t show you at any moment in time how much of that original estimate is left to do and how much has been done. This makes it really hard to create a meaningful burn down.
- It doesn’t show you where the effort in each story lies. Some stories require lots of development but not much test, and some the opposite.
- When something’s In Progress it’s a bit of a black hole. You can’t see at a glance who’s doing what or how near competition it is.
- It doesn’t take into account the impact unscheduled work has on the sprint. Un-ignorable production support issues for example.
You can get around some of these short comings by writing on each card, but then each card gets covered in numbers that change all the time and need to be scribbled out and re-written. Messy.
Our improved design
So with this in mind, we set about coming up with a new board. They key thing for us was to have a board that showed not just the status of each card, but also the amount of effort remaining on each card, separable by skill-set. This is what we came up with. (Press ‘Start Prezi’, then the forward >> button. Feel free to go full screen if the letters are too small.)
The cards are arranged down the left of the board and don’t move during the sprint. Each column represents a day in the sprint. Each story therefore has a cell for each day.
Each cell has four corners. Each corner is allocated to a role in the team, and the amount of remaining effort required from that role, for that card on that day. Top left is for development, top right is test, bottom left is sys admin, bottom right is UAT. The big number in the middle of each cell is a sum of all the corners and gives an overall view of progress. When this is zero, it means the card is done. Zeros inevitably evolved into smiley faces after a while!
At a glance, the board looks like lots of numbers. But when you understand what each number means it’s very easy to track the progress (or lack of it) of each card see how much work remains. This data can easily be put into burn down/up charts.
A focus on delivering stuff, not just doing stuff
What I really liked about this board layout and the behaviour changes it prompted was the real focus on delivery. The scrum was no longer a narrative about what we were working on but more about what we had to do to ship the all the stories at the end of each sprint. It fostered a sense of accountability and a real goal in each sprint to get each card down to zero estimated effort remaining and released to live. Consequently we delivered quite a lot. A hell of a lot in fact.
The board and the re-estimation of each card became the focus of the daily stand-ups. The “what did you do yesterday?” and “what are you doing today?” questions turned into “How much work is left on the card you were working on yesterday?” and “which card you are you working on today?”.
The size of our story points were roughly comparable to 1 person-day, which made it very easy to see if someone had a good productive day or not. If someone was able to reduce the remaining effort on a card from 2 to 1 in a day, that was good. If they only got it down to 1.75, they didn’t have a great day and they can explain to the scrum the problems they faced. (Or fess up that they were slacking!) Or this might mean the person made a full days worth of progress on the card, but in doing so learnt the original estimate was optimistic and should have been 0.75 days bigger. Either way, they could explain that in the stand-up and get the support they needed.
Curing context switching
Another rule we set ourselves was that each person was only allowed 1 avatar each. The scrum members used to complain about context switching and I’d look at the board and see the same person working on five cards. We pretty much solved context switching wastage overnight by only giving each person one avatar which they could only put on one card. This also made it obvious when someone was context switching because they’d have to go up to the board to move their avatar.
Not purely developer focussed
Because we also got estimates (and therefore daily involvement in the stand-up) from sys admin people and UAT people the scrum didn’t feel like it was operating in a developer focussed bubble. UAT was part of the process of getting stuff live, and it was acknowledged the sys admin type work didn’t just magically happen sometime between finishing development and going live. Consequently these activities got planned, tracked and delivered with the same rigour as the development and test activities.
Tracking status stickers
In addition to the estimate updates, we also used status stickers.
Blue – Card has been de-fuzzed (3 way meeting between the dev, tester and BA to review the story, make sure they all understand it the same and agree how it will be developed and tested. Some of the most valuable 10 minutes spent on the card in the whole sprint.)
Red – Card has outstanding defects.
Turqiose- Defects have been fixed, need re-testing
Yellow – Testing signed off
Green – UAT signed off.
These stickers built up into a little multicoloured snake that told the story of how easy or problematic each card was. After a series of stories that had lots of defects and kept bouncing back and forward between dev and test, we created a rule that if a card had more than two red stickers it needed re-de-fuzzing. This nipped ping pong testing and bug fixing in the bud.
A central part of planning and stand-ups
The board became and intrinsic part of not just the daily stand-up but also planning. The sprint planning session was where the cards were put on the board and first set of estimates added. It was therefore easy to size each sprint and take in no more than we thought we could deliver to live by the end of the sprint. Keeping an accurate track of the numbers made it easy to see what our velocity in the previous sprint was and not accept more work than that in the next sprint.
Handling and tracking unplanned work
The board has an area for unplanned work. If we had to pick up some support ticket for example, a pink card would be stuck on the wall and the amount of effort that was sunk into it would be totted up in each corner. Even though this wasn’t planned work, it was still work and could be used to calculate the velocity the team was capable of, comparable with the amount of planned work we actually delivered. This was really very useful in one scrum where the business owner was simultaneously chucking unplanned work into the team, and complaining he never got much value delivered. This showed him why!
A clean start every sprint
A final advantage of this layout was that at the end of each sprint it would be completely cleaned down. All the cards would be removed and all the numbers wiped off. This made each sprint a nice clean fresh start with all the sins, frustrations and problems of the previous sprint wiped away. This felt nice. Any carry-over would be re-estimated as if it were a new story.
Disadvantages of this board
- If you have a non-standard scrum board, you spend a bit of time explaining how it works to people!
- The conversation in stand-ups naturally become about tasks and progress, rather than about people and activity. Some people found this impersonal, and felt like they were just a resource delivering work.
- Some people didn’t like the delivery focussed nature of this board. They felt it was burdensome and they didn’t like their progress being measured so visibly or so mathematically. (Although those that complained the most about this tended to be the least productive.)
- The board lacks the visual impact of cards moving from swim lane to swim lane.
- Some people argue the level of detail shown on my board belongs in Jira, or whatever card management tool you’re using. It would be lovely if it was in there, but in my experience getting people to update statuses and estimates in a tool is a constant battle. Getting someone to give a number once a day in a stand-up is much easier, and other people can see, hear and use that information.
- The design requires a physically large board to fit everything on. Because each card has it’s own row it’s not especially scalable either, so you can’t just cram more and more cards on to the board. But you shouldn’t be doing this anyway!
This board design won’t work for everyone. But it did work very well in three scrums I have run and I’d recommend you give it a try. If it doesn’t work for you, switch back to what you were using before, or try something else. If it does work for you, try and improve it further! Let me know how you get on.