Project Boards

An effective practice is to gather around the project board for daily scrum (see my blog on Stand Up Meetings (Scrums). Ah yes, the project board! But what goes on a project board, when is it used, and how is it useful?

Contents of Project Board

The primary goal of a project board is to communicate assignments for a development iteration. More specifically, it should list the assigned stories and their assignee and status. Beyond this, the board format should be flexible; each team should tweak until they have something that works well for their needs.

I like to divide the project board into 3 “Pools”: Assigned, Resolved, Closed. Since each pool basically indicates the status, I simply have to list the stories and assignees. I do have a few symbols that I use to indicate “Reopened” stories (back in the developer’s court for bug fixes), and “Carryovers” that were brought forward from a previous iteration. When a developer completes a story and hands it off to QA for testing, it moves to the Resolved pool. When testing is complete and all required bugs are fixed, it moves to the Closed pool.

You can use a portable white board, or if you use a project tracking tool, you can fashion a real-time report to do the same thing.

Project boards should be the basis for daily scrums. They should also be posted near the team to serve as a reference point during discussions with team members, internal management, and customers.

Traditional Problems

So what are the problems that precipitate the need for a project board?

• People forget assignments – If the iteration plan isn’t visible and reviewed regularly, things tend to fall through the cracks. Within even a few weeks, the wheels can come off.
• Priority drift – Team members can lose sight of priorities and get mired working on lower priority items, e.g. low priority bugs, unscheduled refactors, and other items not actually on their work plan. Why? Maybe it is more fun, maybe it is a bee in their bonnet, who knows. My experience is that this is not limited to junior team members, occurring just as often with more senior team members.
• Status headaches – Instead of incremental, daily status updates, traditional projects often do a mad dash every week or two to provide a status report to the customer. Developers are interrupted to document what they have been doing for the last few weeks, Project Managers spend hours on these reports, and yet they are always outdated, only as current as the last status report that was sent out.
• Piling it on – Business people often have “rush” requests that they throw on the pile mid-iteration, expecting that it will get done as well. Teams quickly find their bandwidth considerably smaller then when they were planning. They can’t deliver as promised and morale suffers.

These problems are almost a given with traditional projects that deliver only every 6+ months. However, I have frequently seen them on iterative projects as well. A few weeks can be a long time, and things can go awry rather quickly.

Project Board Benefits

Using project boards can lead to some great benefits:

• Awareness of assignments – For the most part people knew what they were supposed to be doing, but on a regular basis I would get comments like, “Oh, I forgot that I had picked that up” or “I hadn’t noticed that Janie Developer had reassigned her story to me to integrate my piece.” Once we started gathering around the board, things stopped falling through the cracks.
• More motivation – Developers take great pride in the quality and quantity of their work. They appreciate when their efforts are noticed, and their motivation rises accordingly. Once there was a daily review of what everyone was accomplishing, a healthy competition formed among some of the team to see who could crank out the most. One afternoon on the last day of an iteration, a developer looked at the board and said something like, “I’ve got 6 stories done, but I’ll bet so-and-so finishes two more tonight to pass me up.” He went back to his desk determined to get more done. Don’t beat people over the head with this (“Why can’t you crank out the work like Johnny?”), but certainly do the team the favor of noticing their good work, thereby motivating them to keep it up.
• More accurate status – Developers started correcting my stats, saying, “I already sent that over to testing.” Sometimes this was my mistake, but at times the developer hadn’t yet updated the project tracking system. Updates became more timely, enabling the customer’s ongoing view of status to be more accurate.
• More informed rush order decisions – When business people arrive with rush orders (“We’ve already paid for the ad, it’s running next week!”), the board serves as a reminder that the team is booked and that a swapping exercise will need to take place. I have a friend who has his team use personalized, magnetized buttons (I jokingly refer to them as “flair”) that represent their available work units for an iteration. They distribute their buttons on the board amongst the stories that they take on for an iteration. If a business person has a “rush” request, there is a very visible representation of who is working on what, which simplifies (and simultaneously discourages!) a swapping exercise.