Kanban/Scrum Boards [closed]

Question

I'm curious as to what other people use for physical Kanban/Scrum boards in their companies. I appreciate that because of sensitive business information you may not be able to provide a photo of the board. I"m looking at to find out what does your board looks like, and how you organize user stories and tasks as they move through a typical sprint/iteration?

Typically I've worked in a places that organize the board as follows with each

User Story   | Todo                   | In Progress  | Ready for QA     | Done   | UC-001       | Domain Object, Service | DAO(Bob)     |                  |        | UC-002       | Payment UI Screen      |              | Payment Srv (Don)|        | UC-003       |                        |              | UC-003           |        |              |                        |              |                  | UC-004 |              |                        |              |                  | UC-005 | 

So to summarise:

• A task for UC-001 is in progress by one member of the team (Bob). A list of tasks for other people to pick up are waiting in the Todo column, but this can be picked up by another member of the team who co-ordinate with Bob to get the work done.
• For UC-002 the payment service task was completed and an automated test harness was completed for QA allowing them to test the service without a UI. If the test fails a bug is raised and moved along with the Payment Service task back into the QA phase
• All the tasks for UC-003 was completed and moved to Ready for QA.
• All the tasks for Uc-004 and UC-005 were complete so the user story was moved to Done.

This works as a tangible white board that involves people interacting with each of the tasks/user stories (represented as post it notes). An electronic version is created prior to the sprint/iteration and is only updated at the end of the sprint/iteration corresponding to the current situation. Comments and criticism are welcomed : )

Answer 1

We use something inspired by the famous Scrum and XP from the Trenches from Henrik Kniberg, the columns being adapted depending on the context (often: TODO, ON GOING, TO BE TESTED, DONE):

alt text http://blog.realcoderscoding.com/wp-content/uploads/2008/09/hk.png

Product Backlog Items (PBIs) are printed as "physical cards" (A5 format) for the Sprint Planning Meeting (at least the most important). Once the team has picked up PBIs for the next iteration, items are break down into tasks/activities (on sticky notes). After the meeting, everything goes on the Scrum Board and I suggest to use tape or thumbtacks or magnets. PBIs are ordered by importance, most important at the top of the board, less important at the bottom. The team should work on the most important item first until it gets done. First, activity post-its move from the left to the right. Then, the PBI jumps to Done. Unexpected tasks are added to an "Unplanned items" zone (to take them into account in the burndown chart). Future PBIs stay visible in a "Next" zone (if all items are completed during the iteration, we pick a new one from there). Pretty simple.

These practices allow to detect smells visually, for example:

• stucked tasks (i.e. tasks that are not moving) that show a potential impediment
• team doing things in the wrong order and not focusing on top-priority items, like on your sample :)
• too much work in progress, nothing done
• unplanned items that are killing a sprint

Works great.

If you are looking for more "kanban oriented" stuff, maybe have a look at Kanban vs Scrum, One day in Kanban Land and Kanban and Scrum - a practical guide from the same Henrik Kniberg. Great stuff too.

And, for more pictures, give Google Images a try with scrum+board, kanban, scrumban, scrum+kanban.

Answer 2

Here is our Kanban Board that we use at TargetProcess. We do not work on Tasks level, just on User Stories and Bugs level. Sometimes we create tasks, but they are not tracked explicitly on the board.

We do not estimate User Stories and Bugs, but try to split Stories into smaller (with mixed success). Columns are self-explanatory. We accumulate items in Tested column, then create a branch , smoke test it and release new build. Usually we release new build every two weeks.

Also the board shows developers and testers load and classes of services via color coding.

UPD. Now we have several small teams and use a single board to track progress of all teams in http://www.targetprocess.com/3