Alex Rivera | Logout

Kanban/Scrum Boards

Asked 2009-11-27T06:30:07.730
29

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/iteratio

project-management agile scrum agile-processes kanban
Edit
Report

3 Answers

15

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, answered 2009-11-27T20:22:18.957

2

We're experimenting with a couple of different board structures across a few different projects that we're running. One project has the most basic structure we can use:

| (Sprint) Backlog | In Progress | Done |

As much as possible, we try to have a single post-it to represent both the Dev and QA activities for a story.

The above structure has seemed to work ok for the developers on the project, but the QA members have struggled to know when a story had the development work complete such that they could execute their tests for that story. We found ourselves moving the stories to the "far side" of the In Progress section to indicate that the Dev work was done and that QA could pick up that story. This very quickly became quite unmanageable as the In Progress section filled up.

This led to the second iteration of board structure for another project which is:

| (Sprint) Backlog | In Progress | Ready for Test | Done |

The newly added section Ready for Test essentially became a formal section of the board that was previously the "far side" of the In Progress section. On the surface of it, this should have made things clearer for the QA members, but this still caused some confusion as people had different interpretations of what Ready for Test meant (I'll not bore you with the different interpretations here).

This has then led to the latest iteration of board structure we're using on another project:

| (Sprint) Backlog | Dev in Progress | Dev Done | QA in Progress | Done |

This is certainly quite a far way from the simple Backlog, In Progress and Done sections of the first iteration, but this appears to be working well for the team. They have a clear understanding of what it means to move a story through various sections of the board and for any one story, it gives a clear pi

answered 2009-12-03T15:31:12.137
0

Ours looks fairly similar. Each developer has a column and we have rows for 'Done', 'In Testing', 'Work in Progress', 'Backlog'.

And we use actual post-it style notes that we physically move as it goes through each phase.

Personally, I find the system to be lacking...

  • Manually moving post-its gets to be a pain after a while. Our QA team mostly manages the ticket moving - and it's a constant effort to keep them synched with TFS.
  • The post-its can really only be moved so many times before they aren't sticky anymore. If a ticket is sent-back from testing and placed into 'In Progress' and then moved back to testing, etc, etc...it doesn't take much for it to end up on the floor.
  • Sometimes, the sheer volume of notes is overwhelming. Notes have to be stacked to be even remotely visible - we layer them such that we can see each notes unique identifier (as best as we can)...but then you've got a stack of 10 notes and you need to get the 5th out of the stack and you are rapidly contributing to the decrease in stickiness that will end with the notes on the floor.
  • When the tickets do end up on the floor it's reasonably annoying to find out where they should go. Was that Developer A's ticket? Or B? And was it in Testing? Or was it done? Let's go back into TFS, look up those tickets and then move the post-its accordingly.

Personally, I don't think post-it notes are the appropriate tool here. There are a handful of digital tools that make this sort of thing completely trouble free. We use Team foundation server - and I've seen a couple of really great, robust, free, and even open source tools that will interface with Team foundation server and manage all of that for you, in real time.

http://www.telerik.com/community/labs/tfs-work-item-manager-and-tfs-project-dashb

answered 2009-11-27T06:44:38.290

Your Answer