The team board is another essential ingredient of an agile team. It tells the team what they should be doing and it tells the company what is going to be released, and when. Its magic is the way it radiates information to everybody walking past. As opposed to spreadsheets and 'agile software' which are information fridges because they only give up their information when and if they are opened.
I use a large magnetic white board for my team board. The main part of the board is divided into five columns, and contains all the stories and tasks that will be worked on this iteration. The stories and tasks are written on coloured index cards and stuck to the board with magnets. This allows them to be reordered (re-prioritized) easily. It also contains a burndown chart and other important information like release dates. Anything which we don't want the team to forget e.g. goals, vision, work to do, work remaining, milestones, needs to be visibile in the team space.
Every team I have ever worked with has had a debate about white board vs electronic system at some point. There are some compelling reasons to use software, especially if not everybody in the team works at the same location, but by using software the magic of an information radiator is lost. Being able to hold a card, write on it, give it to somebody, move it and rip it up all helps create a system that works for a team, a system that the team owns.
A story is a feature or requirement that describes something of value to the customer. E.g. A Martian wants to be able to search for uninhabited caves which are near watering holes, so he can easily indulge his habit of getting dunked. For more information on user stories see chapter X.
A task is a piece of work that has to be done to implement the story. E.g. Get search criteria from Martian, Search available caves, Display results. Stories are broken down by the developers into tasks at the planning meeting. ( See chapter Y ). Most tasks should take a day or less to complete. A task that is estimated to take longer than 2 days probably isn't well understood. It is worth taking the time to understand the task and break it down further before we start work on it, otherwise we may get suprised half way through and find the work will take us a lot longer than originally estimated to do, or is unfeasably complex to implment.
Once all the stories and tasks are on the board, then completing the iteration is simple. All we have to do is complete each task before the end of the iteration!
Having all the stories and tasks on the board enables magic to happen. Everybody knows what to do without being told. When a developer or pair need a new task to work on they don't have to ask you or tell you what they're doing.
They simply choose a task card from the 'not started' column and move it to the 'in progress' column. They signal that they are working on it by writing their name on it, or sticking their picture on it. My current team has Simpson avatar pictures (www.simpsonsmovie.com) of themselves which they stick on to the card they are working on.
How does a developer know which task card they should choose? Arrange the cards in priority order from top to bottom, then the developer just needs to choose the topmost card which they are able to do. Allowing the team to choose their own work rather than it being allocated to them keeps them responsible for the whole project and not just 'their' part. It also allows them to choose work that interests them.
When the developer finishes the task, when all the unit tests pass and the code has been reviewed by another developer (if it wasn't written by a pair) then the card needs to be approved by a tester or customer. The customer should verify that this is what they wanted (as opposed to what they asked for.) Depending on how the team works you may be able to interrupt the customer or tester and get them to approve the task straight after it has been finished, or we may want to move it to an 'awaiting test' column, and the customer will look at as soon as possible.
Once the customer has approved the task they move it to the 'complete' column. When all the tasks are moved from 'not started' to 'complete' we have won, the work has all been done.
The board allows one principle of good management to happen, everyone knowing what to do without being told. It also allows a second principle of good management to happen - limit work in progress to capacity, or reduce task switching. The 'in progress' column ensures this happens naturally. Ideally there should be exactly one task in progress for each developer or pair, because you can only be doing one thing at once! Minimising task switching, by having people only work on one task at a time, hugely improves efficiency. If a developer has their name on multiple cards we should find out why.
It also stops a false sense of progress when lots of tasks are started but not finished. Tasks are only valuable to the company when they are finished. Having multiple tasks in progress is worthless, but having one finished is valuable.
Progress is recorded and displayed on a burndown chart. The amount of work left to do is plotted against time left, and compared to how much should have been done by this day. Therefore every day the team see whether or not they are on track to meeting their commitments. This is very motivating for the team. As is the fact that they have to say to the whole team every day what they completed yesterday.
Update the burndown chart every day after the standup meeting. Things which have affected the development effort like missing team members can be written on the chart as well.
As much information as possible should be visible to all and not hidden away in computers. As well as stories, tasks, milestones and burndown charts we can display our roadmap, release plan, architecture diagram, risks or retrospective notes. Make our team space look and feel like our team's space.
The team board allows the team to manage themselves by always making it clear what should be done next. It also provides a way for the team members to communicate status to each other, which allows testers and customers to synchronise easily with developers.
The 'in progress' column helps limit work in progress to capacity which improves productivity.
A burndown chart shows if the team is on track every day - which is a very powerful motivation for staying on track.
The power of team boards lie in the way they are in the team space and visible to all.