问题
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 : )
回答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.
回答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
回答3:
Scrum / Extreme programming storyboard.
http://www.flickr.com/photos/dafydd_ll_rees/4138686549/
Work appears on the second-from left colum, and progresses across the board through different stages of completeness.
Column names: Not Started, Just Started, Half-Way, Almost Done, Ready for Showcase (passed QA)
The first row is specially reserved for bug fixing - like a fixed, priority for clearing bugs.
The Simpsons characters represent each member of the team. They're moved around so we can see who's working on what.
回答4:
I suggest you to take a look on Eylean board. http://www.eylean.com/?utm_source=geffort&utm_medium=content&utm_campaign=geffort it can fit all your needs because of intuitive interface, statistics, dashboard. Also it fits any process and the most important thing it is very easy to use. This board allows you to represent several projects on one board using rows. All the rows may be visible at a time or you can remove selected ones from the scope.Another solution may be task grouping and filtering by categories - then all the tasks can be represented on one board and row, but attached to different categories.
回答5:
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!
回答6:
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!
回答7:
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 picture of where in the life cycle that particular story is. We've only been using this structure since the start of the current sprint (we're 9 days into a 10 day sprint), so we'll be exploring this structure in more detail in our retrospective tomorrow. Not perfect I'm sure, but if it continues to work for the team that is piloting it, we'll try to roll it out across other teams in our organisation.
回答8:
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
回答9:
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-dashboard.aspx
回答10:
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.
回答11:
We went with following board structure in our company.
Backlog | Next sprint | Current sprint | Done
Buffer | Working
Lanes are assigned to specific members. Each member has different job at our office so the tasks vary. We add what we have to work on to our Backlog, then move it into Next Sprint if it approaches the deadline. Blocked green tasks are used for continuous tasks that have to be worked on daily. Red cards indicate importance of the task and have to be finished as soon as possible. Our board allows us to collaborate freely and add tasks to each others swimlanes if we need something to be done by different department.
We use KanbanTool (Kanbantool.com) to visualize our workflow and manage projects. It's really intuitive and easy to use. Our team communication has improved tremendously.
来源：https://stackoverflow.com/questions/1807100/kanban-scrum-boards