The card wall or scrum board is one of the most well used artefacts in Scrum/Agile. I for one prefer physical card walls than digital tools for many reasons. I like the physical awareness of a card wall and the simplicity of people swarming around the board to visually see workflow and it also encourages the interest and the presence of those who need to support the team such as the product owner. That being said I’m not totally against tools if they are used well and adhere the scrum principles. This includes not as a remote reporting tool and not as an excuse not to engage with the team.
Overtime the card wall’s change with the team, sometimes to reflect changes in the workflow sometimes to simply refresh the trams avatars. For a while I’ve been thinking of changing the layout of the scrum board and try and make it a little more fun and interesting as well as being different to the usual straight line column layout. From this came the following board layout which seemed to be a big hit with the team and other scrum teams nearby.
What I liked about this design is that it follows a natural bullseye like focus on the centre which is “Done”. It physiologically makes “Done” a target which is good to support the sprint goal. We use the channels/lanes to done such as “Ready”, “In Progress”, “Done“. I also like that it leaves gaps around the board where we have positions our team values and definition of done. I’m sure there are variants you could do around this structure to emulate a dart board using points which would be interesting.
All in all I think it looks a lot more fun. As soon as we moved to this the team wanted to change the avatars to super hero’s, so now we have named it the “Super Hero Scrum Board”.
Let me know what your thoughts. If you have an interesting scrum board feel free to send me the image or link and I’ll post them here.
Other Scrum Boards
How This Works
To Do outside of the circle, In Progress in the red circle, In Test in the blue circle and Done in the green circle. The board is divided into into segments for the 9 days in the sprint. A story is then placed in the relevant segment for when the team thinks it will move into test e.g. a developer starts a story and based on the tasks and what they have on they believe it will be ready for testing on Monday of week 2 so they place it in that segment. This really helps to highlight very visibly when stories slip and creates a good debate amongst the team. It also highlights when the team can bring in extra stories.
What are the two columns to the left and the ones on the right? Release backlog then sprint backlog on left? Deployment flow on right?
Hi,
The two columns on the left are x2 backlogs. One of them is for the Android board on the left and the other for the iOS board on the right. The ones on the right (eight of the octagon) are a combination of bugs (red cards) and ideas/suggestions for improvement. These have been captured but not reviewed/qualified for the backlog yet. Beyond these on the right the columns are for a higher level board which capture more of an epic level, release state of various clients including iOS and Android.
Hope that makes sense. We no longer use this board now and have drastically changed it.
Hi!
We are Kyiv team and we have a picture of our scrum board that will fit perfectly into “Other Scrum Boards” part of your post.
Here is the link with the picture http://postimg.org/image/9ginuwoln/
If you like it, please, update your post!
Thanks in advance!
Hi Kate, thanks for sharing your board. It looks unique and interesting. Could you explain a little on how it works for the benefit of other readers?
Thanks
Craig
Hello everyone.
I would like you explain more about the levels of the spider’s web in the board before the DONE. I am guessing you are using “Doing and Test/Documentation).
Sincerely
Ezequias Rocha
Thanks for asking. The lanes in our case changed over time with the workflow. The number was related to priority and each lane which included, development, ready to test, Test and then done. This was all subject to the quality constraints expressed in the teams definition of done and the expectations for each stage.