Our Story Board is Better Than Yours

May 25, 2009 by Janusz Marcin Gorycki

I have decided to take a break from my usual bi-weekly musings about high-level, theoretical subjects and devote this post to something more concrete. I would like to show you how our story board that we use for sprints looks like. This may be of interest to both newbies and advanced users. The former will have a chance to see how this sort of a thing looks in practice, the latter will be able to compare with their own story boards and share their opinions, praise or criticize (in a constructive manner of course).

The subject is also interesting because it gives insight into the evolution of our team, its dynamics, its priorities – I think it is safe to say that our story board is a reflection of who we are and what sort of a project we are working on.

Let me start with a disclaimer: this story board is not “by the book” – it is not exactly the type of board that is described in Scrum handbooks. It started that way. But over time it has evolved, mutated, adjusted itself to fit our needs. “By the book” solutions are good in theory only, day-to-day reality requires you to be more inventive than what “the rules” require.

The photo above shows our board midway through the current sprint (which is going to end on May 26th – around the time this post will be published). You will notice some obvious differences from “the standard”

• the board has four columns instead of the typical three
• the two inner columns are quite narrow compared to outer ones
• there is no sprint burndown chart in sight

All three items above are our conscious choice and are there for a reason.

If you look closer (maybe the photo's resolution is not enough to notice that), you will also notice that there are no tasks on the board – just stories and bug reports. A big no-no according to “the rules” – yet, this is what works for us and I will explain later why.

Let's start from the first one – what is the fourth column? The additional, non-standard column is the third one from the left – it is called “Testing”. Stories go there after they get “finished” by whoever on the team happened to be working on them (it could be one person or a pair). This column reflects our “Definition Of Done” - our definition is “The Story Is Done When Somebody Other Than The Implementor Says It Is Done” (your “Definition of Done” is probably different, but this is what we use). The “Somebody” can be anybody on the team, but they must not be directly involved in the implementation of a given story. For bugs, ideally (but not necessarily) this should be the reporter of the bug. A word of warning - the existence of this column is a potential bottleneck – it used to happen that cards would sit in this column and nobody would bother to pick them up and test a story or a bug fix, moving it either right (“test passed”) or left (“test failed”). Therefore, during one retrospective, it was decided that after each daily standup, all cards in “testing” column must be dispositioned by noon of the same day, otherwise nobody is allowed to pick new tasks to work on. This sort of a setup gives us a quite tight first-line QA, that is fast enough to catch quite a few errors before they show up during the sprint demo, or "in the field".

The second interesting fact – two inner columns (“In Progress” and “Testing”) are quite narrow. They are meant to fit just a few cards. This is by design. You are not supposed to start working on some story or a bug fix until you are done working on the previous one. So the inner columns are usually occupied by just a few cards – most of them should be either in the left-most (“Not started”) or right-most (“Done”) column.

Next fact – we have no burndown chart at all. Why? Well, there used to be one, but it turned out this chart was quite meaningless. See, sprint burndown chart requires having time-based estimation of tasks required for implementation of every story. We used to do this – we used to split stories into tasks and estimate effort for tasks. But, either due to the fact that the work on our project consists mostly of “fighting with nature” and “charting the unknown”, or maybe simply be cause we suck badly at time estimations and at splitting stories into tasks, invariably midway through the sprint our initial tasks (both the estimations and task definitions themselves) turned out to be completely out of sync with reality. So one day we decided to stop doing it. Instead, we are splitting our stories in sub stories, in such a way that typically a story we accept for implementation is just 0 to 3 point big. Which incidentally is an order of magnitude less than our typical sprint velocity (around 12-15 story points per two weeks). So these days, we are able to estimate where we are at in each sprint by just glancing at the distribution of cards on the board – they are mostly of the same size, co number of cards in each column gives us metrics that are sufficient for us.

Now about the cards themselves. We print them straight from JIRA, using a nifty plugin that we have created. Take a look at the card on the right – decently looking, isn't it? Now, most of our cards that are the “original” ones (scheduled during the sprint planning) are printed. But, if we happen to find a bug in whatever we have done during the sprint, we pin a hand-written card to the board and treat it just like the rest of them (and of course file a bug report in JIRA, to be fixed during the current sprint). There are quite a few of these hand-written cards on the photo.

The last thing for today – big piece of paper in the lower-right corner. It contains “the rules of standup” – what question you should answer, what topics to cover and what not to talk about. In case somebody strays from the subject, it is very easy to discipline them by just pointing them to “the rules”.

So there it is, our story board. It is better then your story board obviously – for our team. Your story board, with its own quirks and specifics, will be better than ours for you.

Permalink