Scrum Board Awesomeness – Part One!
7 February 2017 |
About a 6 minute read
Scrum keeps everything about a project visible to everyone.
(Ken Schwaber, Agile Software Development with Scrum)
One of the three pillars of Scrum is Transparency – it requires significant aspects of the Scrum process to be visible to those responsible for the outcome. As such one of the most important information radiators when following the Scrum Framework is the Scrum Board. But why use a Scrum Board, what benefit will it add for my team? And what about setting one up, they are so many different ways of organising your Scrum Board, which one will work for my team? Hopefully, this article on the non-functional aspect of delivering change will aide you in achieving this goal. But first;
Why should I use a Scrum Board?
The Scrum board has the mission of visually representing the work that is being done by the team. They radiate progress of the team, delivery against a plan and cleary identify who is tasked with doing what. They are the most complex and versatile artefact in Scrum: a physical task board is a “living” entity that has to be manually maintained. The use of the Scrum board should be standardised and form part of the process.If Scrum boards (and other information radiators) are not an integral part of the project methodology, maintaining them might be perceived as overhead or duplication of work.This results in boards not being updated and becoming out of sync with the work actually being done. An incomplete or stale task board is worthless. As such, using a Scrum Board is essential in seeing the benefit of delivering change using the Scrum Framework, but also beware – enforcing its use on a team who do not understand its benefit can result in it being a hindrance to a teams success. So naturally, the next question has to be:
How do I create an Awesome Scrum Board?
Well in this two part series we are going to outline few simple steps for you to follow! Today we will cover four of these and later this week we will share the rest. At that stage we hope you will have all you need to get going on your first Scrum Board…..Let’s get to it!
1. A Clear Structure
Start Simple! Don’t add too many columns and stuff which is not needed. Keep it clean because if it’s a mess it could give a bad impression. Keep it simple, so that it is easily understandable. The message here is to follow the ethos of Scrum when building your Scrum Board – build a POC or an MVP, gather feedback, see what works, see what doesn’t and iterate! This is no perfect, fit-for-all structure which suits everyone.
Board Framework – Lay out your columns and rows in bold colours (blue tape works well) . Try to create lines that are not easily eroded, but are also easy to replace.
Now for the Rows or Columns
- a column title row – put it on the top and I like to separate this row with a horizontal line of marker or tape
- one row for each story in the sprint backlog
- one row for those retrospective actions
Stories -try to use an index card or larger sticky note. Typical attributes might include: title, description, acceptance criteria, effort size, delivery order (backlog priority)
Tasks – a sticky note or index card for each task the team works on in the sprint.
Have all the necessary bits and bobs!! And, please please please, make sure to use Whiteboard markers and not a permanent one on your Scrum Board – beware those sharpies!!
And finally, avoid smudging, so no left handers please!
2. Make it Personal
Try to make your Scrum Board reflect the identity and personality of your team! No two teams Scrum Board should be identical, they may follow a similar structure but each team should add something which is unique to them.
A few simple ways you could achieve this:
- Pick a Team Name and display it proudly. A team name fosters a sense of belonging and a supportive network. It promotes a sense of collective responsibility and ownership
- Use personal Avatars showing ownership and who is doing what at a glance – it also adds some fun!! Use pictures with name of each member of the team. This will also help to improve the feeling of appartenance to the team, and external parties can easily identify members of the team.
3. A Sprint Goal
The Sprint Goal should be displayed clearly and prominently on the Scrum Board. The Sprint goal supports prioritisation, creates focus and facilitates teamwork – remember the team commits to the Sprint Goal not stories. If trade-offs need to be made, the Sprint Goal should be used to guide you to the best outcome for the team and the customer. Finally, the Sprint goal supports Stakeholder communication. A stakeholder may not be able to appreciate the value and detail captured in each of the stories, but the Sprint Goal should clearly and simply articulate the value which will be added by the team when the sum of the stories in the Sprint are delivered.
4. “Definition of Ready” and “Definition of Done”
This one is very simple – you should be creating and using these crucial artefacts in all your Scrum Events! As such their importance should be reflected on your Scrum Board. Display them on your Scrum Board as a reminder to everyone in the team.
The “Definition of Ready” is a statement by the team which clearly articulates what they need to know before they will consider a story for inclusion in a Sprint. Product Owners, BA’s, and everyone else who might want the team to do something for them should know what details they are expected to provide and the team should be reminded as to what they are asking for! They should not comprise – or at least not always, Exceptions can quickly become the norm.
The “Definition of Done” clearly describes what level of Done the team are committing to bring the stories too in their Sprint. If it says automated tests, then the story should include automated tests before if can be moved to the Done column. It is the standard to which you should hold the team too, and they should not be easily allowed to forget this. As such, get it on the board – “We forgot” is not an excuse
And that is it for Part One! A few simple steps to get us going……if you want to know how to really add that “Awesome! element to your Scrum Board, make sure you read Part Two!
Tech Lead (Reading)
Bring your expert tech knowledge to the table to influence the direction of projects, whilst coaching and your team through engineering best practices.I'm Interested
DevOps Lead (Reading)
Bring your delivery expertise to the table, leading the pack as ambassador on operational requirements, influencing and continuous development.I'm Interested
Programme Lead (Edinburgh)
Bring your expert project knowledge to the table to own delivery of all our initiatives being delivered out of our Delivery Engine.I'm Interested