Kanban/Scrum Boards [closed]

Answer 1

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

Answer 2

Our boards tend to evolve overtime as we progress as a team. I tend to favour physical card boards if you have a collocated to team as it encourages better face to face communication generally from my experience. Obviously there is more overhead, but it's worth it to get the team working together. Another advantage I have seen with physical boards is that it helps with business engagement. Remote stakeholders can't just sign in and see progress within the current sprint and take things out of context as sometimes cards don't tell the full story. They have to have a conversation and come to the board which can be beneficial as things can get explained and it also means that they can be encouraged to help resolve with impediments. However this is not exclusive to physical boards but it helps.

As mentioned our boards evolve overtime with the teams needs. Often we start with textbook scrum, but encourage continuous improvement and usually end up with a scrumban solution. These changes are reflected by visualising the new workflow through the boards. I recently wrote a post on our latest change if your interested have a look at our hourglass scrum / Kanban board

I think the team should get involved in making the boards as it helps the team understand the workflow and not become silo's. Also if the team have had a hand in making the board they police their own processes better which helps with self organisation as it's a product they have had input to.

Answer 3

In practice the organisation of the work-in-progress board is best left for the team to determine depending on your circumstances and environment. (Agile == selfmanagement.)

That said, here's what we did in my previous team, part of a 300+ developer effort that was relatively new to Agile and Scum:

We had two boards - one with index cards for forthcoming stories so we could tell what was coming up, and one with the current sprint's work. Our columns on the current sprint board were simply

Not Started
Under Development
Dev Done 
In QA
Complete ("Done Done")

and a box in the corner for Blocked.

A post-it note represented each story.

Developers each had a little magnet which they used at the standup each morning to signify who was working on what. Our team was quite big (~ 12 at one point) so this really helped figure out who was paired with whom.

We didn't bother with an electronic version (no point), although our Product Owner did have a Scrumworks system that he needed to keep up to date. We kept as far away from that as we could!

Answer 4

I'm pretty keen on Lean/Kanban and we've been iterating on our process for a while, initially through a customized workflow in JIRA, but that's not exactly frictionless given the admin complexity in the enterprise version. We've now expanded our use of a whiteboard and have decided to iterate our process using the whiteboard for a while before re-codifying it in JIRA. Here is an example of our layout:

• We are 6 developers
• When a story is in dev, it's on a dev's desk. Likewise with being reviewed, being QA'd, etc. This means every card on the board represents and actionable item, and also provides a decently accurate snapshot of iteration progress. The rule is that only in exceptional circumstances do you have more than one card on your desk.
• We've agreed not to have more than two cards "pile-up" in the Awaiting Review column. This maintains a degree of "flow".

Backlog   | Awaiting Dev   | Awaiting Review   | Awaiting Design  | Awaiting Deployment | Awaiting QA | Done |
Story11   |    Story2      |    Story9         |     Story 6      |   Story1            |    Story9   |
Story3    |    Story7      |                   |                  |                     |    Story12  |
Story8    |    Story10     |                   |                  |                     |             |
          |                |                   |                  |                     |             |
          |                |                   |                  |                     |             |

This is pretty close to mapping the value stream except for the awaiting deployment part, which is a hack to fix the problem where QA can't QA an item until we've deployed it on their server - we deploy 3/4 times during a 2 week iteration.

One thing I have noticed from mapping the value stream on an "information radiator" is that it does magically focus people on the actual value-add work that needs to be done, and that seems to up the pace of business-value development and keep up momentum.

Hope that helps!

Answer 5

Our whiteboard is broken down into these columns:

Story, Not Started, Req/Des/Dev*, Peer Review, QA, Done

The highest priority stories go from top to bottom. Each story can have multiple tasks so we use a big postit for the story and smaller ones for the tasks. Tasks move from left to right. Every day we check to make sure we're working on the highest priority stories.

We use a sticky white tab on each task where the person working on it puts their initials. When they're done and move it along a new white tab is placed over the old one to show it's available to anyone to pick up. When all the tasks are done, the story is moved to the Done column also and at the standup, all Done work is tallied up and moved up the board to make room at the bottom for more stories.

We also have colored tabs for the stories and tasks to indicate blockages to progress (blue indicating a blockage from another team, red requesting scrum master assistance). We talk about the roadblocks at each standup.

We can see when there is too many tasks in one particular column and shift emphasis to get more to Done. We deliberately added the review column to emphasize that the work needed reviewed by someone other than the person doing it before it got to QA.

*Requirements/Design/Development