Building your Sprint Backlog / Scrum Board

Hi :)

Today a practical tip for building a Sprint Backlog aka Scrum Board.

Why should we have a board?

The board main function is to allow team to visualize remaining work (tracking) and facilitate daily synchronization (Re-plan).
Everyday the team gets together, looks at the board (which contains the committed work) and the team re-plans it’s day – What should we do today in order to accomplish our goal?

Because of this, Scrum Boards should be:

• SIMPLE – don’t add to much columns and stuff not needed
• BIG – Everyone sees it, knows where it is and just by looking knows where we are (regarding the team goal)
• ACCESSIBLE – everyone can see it and update it – by everyone can update it I mean the team (it’s their plan, they own it)
• FLEXIBLE – should be easily improved and adaptable to team needs
• INTERACTIVE – appealing people to touch it and play with it (example, by moving cards from one column to another) – if you touch it and name it , you own it – yes, tasks are like puppies.
• VISIBLE – the kind of : you can’t avoid it when entering the room – a good way of keeping questions answered without pressuring or interrupting the team

Paper or electronic ?

I say: something real you make with markers – so paper or whiteboards.

I can give you at least 3 reasons to stick with a physical board rather than using some electronic version:

1.  Electronic boards are accessible, but they are not visible (unless you can afford a big touch screen and display it in the middle of the room)
It’s true that everyone can access a drive or tool, but it’s not something you see just by entering the room. You have to log in, or search inside a folder, so it’s “Hidden”.

2. Electronic appeals to individuality – paper leads to collaboration

If you have a tool:

– you’ll update your tasks before the stand up for the sake of speed – with this you loose interaction

– or you’ll do it during the stand up- with this you’ll increase the time of the daily stand up (and create waste time)

If you use paper, you can speak while you move or edit it. Everyone around you, listening, will also see the task you are talking about

Just FYI, Science :), that Lovely Lady, says there are 3 learning styles:

a) Visual Learners (say around 60% people)
b) Auditory Learners (around 30% people)
c) Kinesthetic (tactile) Learners (around 10% people)

for more details check Neil Fleming’s VAK/VARK model and here .

This means that if you use a real board on the wall, people will not only listen but also SEE what you are talking about, and as you move your tasks through the board, you’ll also touch, perceive the tasks as something material, something that exists.
So with a simple board on the wall you can reach everyone’s attention.

3- There is nothing easier and simpler than paper/ boards to work with, update, improve erase, add…

By using a tool you are bound to what they have, or in case it’s your own tool, you’ll need to implement extra functionalities (and test it, and train people, and…) – while you are getting the budget or permission for this, I’ve meanwhile created zillions of boards with my team ;>.

So my advice is Stick with paper or whiteboards. Use it, improve it, reach the best possible solution. Then, if still you want your own electronic gadget, then… go for it and good luck :).

My board as an example

I made a draft of the board we use. – Sorry but I just can’t take pictures of our walls due to product confidentiality reasons. So if you like it/ find it useful you can just reproduce it in big size
(Extra Tip: don’t make it toooooooo big, else as it will look ‘empty’, everyone will feel tempted to add more tasks than those that can be handled).

If you get back to the basics, Scrum boards have only 4 columns: User stories, Not started (tasks), Ongoing (tasks) and Done (done done, no buts-> done as in ready to go live).

Although I love simplicity, I’ve faced teams where QA was a bit forgotten. So we had to make this visible in order to deal with it.
These teams had no QA experts and developers would run away as much as possible from testing. When having just Ongoing column, tasks just stayed there in a kind of limbo or would go to Done without being really done.
So we split ‘”Ongoing” into DEV and QA.
Having these columns was the way we found to show exactly what was under testing and when this column grows bigger everyone knows it is time to jump in and do some testing.

You can have it or not, it’s up to you and your team. Some teams just create testing tasks and take them through the flow-> Not started->Ongoing-> Done. – Been there, done that – Works perfectly, but only if you have someone caring about QA inside the team, else, again, everyone will delay those tasks as much as possible.

My advise is: don’t get influenced by anyone, except by your team : Do what your team needs and then keep improving it. Target simplicity and transparency and all will certainly go ok.

Let me know if I can help you building your board or just share your own with me ☺ I appreciate new ideas!