Hi-Vis Projects: Whiteboards and Post-it notes

In my previous post I talked about the importance of breaking down a backlog of work into manageable user stories. Once a Sprint starts and a development team has agreed to a specific chunk of work, the emphasis falls firmly on the team to deliver.

Programmers, like most people, don't like to mess up. Even more so, they don't like to be seen as the ones who messed up; victims of either blame or a witch hunt. It is essential then that in a fast moving work environment that Agile processes engender that the team as a collective takes responsibility for all the work undertaken meaning no-one get's isolated. In Scrum the method of tracking progress and making sure that problems aren't brewing is by undertaking a task-breakdown for each user story and to make the progress of those tasks highly visible to anyone and everyone. Once each story has been broken down into tasks this collectively becomes known as the Sprint Backlog.

One great way of achieving this is through the use of post-it notes on whiteboards. Each discrete task needed to complete a story is written on a sticky note and placed on a board such as that shown below. As the task is assigned to a team member (or members if pair-programming) the owner's initials are written on the note and they are responsible for it until it is completed. The task moves from "Unassigned" to "Work In Progress" to "Done" and finally to "Signed Off". If at any stage the task cannot progress for whatever reason, it should go into the "Blocked" column.

By having the tasks on a white-board everyone can see at all times a clear snapshot of progress. It's there, almost omnipresent throughout each Sprint. Personally I don't like software that does the same job simply because you can't "feel it's presence". The white board IS the Sprint. It oozes openness and immediacy like a wiki or spreadsheet could never hope to. (Tip: Get a moveable whiteboard on wheels so you can drag it into meetings etc. when necessary. You can seriously adapt to change when your gear is mobile! Also, you can brain-storm on the other side).

So, now we can track a task's progress, but what about the meanings of the various stages? Many, many moons ago (I was working in COBOL on a x386...) a project manager said to me "There are only two accurate estimates a programmer ever gives me: Not started and finished.". He was spot on, and his insight can be seen today on many a Sprint board:

• Unassigned: Nobody has taken this task yet
• Work In Progress: Something is happening
• Done: Complete. Nobody is working on this
• Blocked: There is a problem. Nobody (in the team) is working on this.

Unassigned is pretty self explanatory. Work In Progress is similarly easy to visualise but the last two need a little more explanation.

How do you know when something is done? Well, this is very often open to debate and individual circumstance but from personal experience I would define done as being the following:

What? Well, if for example we are adding the Save Blog Details story to a REST service then this is likely to be in the form of a suite of automated tests which prove the positive and negative behaviour of the user story. It also means that it has been demonstrated to the PO in a QA environment using an accepted delivery mechanism. i.e. We have deployed the code (and tests!) to a controlled environment using some form of automated delivery system - preferably using continuous integration techniques. What we have not done is emailed a new version of a .dll to our mate in testing who then copied it onto a server. Or worse, demo'd the story on our development laptop.

DoD essentially needs to say "The business has accepted this software. It is ready to ship and there is no more work to be done on this user story."

Ok, so what about "Blocked"? Again this is pretty easy conceptually. Blocked simply means that something outside of the Sprint team's control means that this task cannot progress. E.g. Deployment to the QA server is blocked because the CI software is being upgraded. Blocked should have your Scrum Master running around the place trying to find a solution as quickly as possible. As soon as a task hits the Blocked column, the sirens start wailing and red lights flashing as this means your Sprint is no longer on plan. (As an aside, Scrum Masters should be facilitators to ensure a smooth Sprint. Scrum Masters should ensure Agile practices are being followed and guide the Sprint but not dictate it. They are peers in a team, not leaders of it. The team should be in control of it's actions at all times and should be able to self-organise in order to get things done in the most effective manner).

So, that's a quick tour of one approach to undertaking a task breakdown in order to create a Sprint Backlog. The Sprint Backlog is the focal point for every Sprint. It is a dynamic thing which can have tasks added or taken away as things dictate and people discover more about a story. One final thing to note is something called the Sprint Burndown. As stories arrive in the done state, the number of points estimated for that story is subtracted from the total number of committed points (thereby burning down). At the end of a Sprint, if the number of outstanding points is zero, the Sprint was successful. Sprint teams should try and get into the good habit of signing off stories when they are complete and not leaving them all to the end of a Sprint. If a story is ready to be "Done" on day three of a Sprint then sign it off, don't leave it lying around until the last day when unforseen circumstances might mean you can't demo and sign off!

One more tip: Use a magnetic whiteboard so that cheap sticky notes don't blow away. Nothing worse than having the cleaners hoover up your planning half way through a Sprint.