Learn to use Visual Studio, Visual Studio Online, Application Insights and Team Foundation Server to decrease rework, increase transparency into your application and increase the rate at which you can ship high quality software throughout the application lifecycle
Kanban customizable columns was made publicly available on the March 4 service update, and will be available in the RC version of VS Update 2.
You can read the release notes for an overview of the feature itself. The purpose of this blog post is to talk about what’s going on under the hood of this new feature.
With this feature, we’ve added an additional data element called “Kanban Column”. This stores which column on the team’s kanban board the work item is in. This is separate from, but related to the State field.
When designing this feature, we considered just adding another field to the User Story / Requirement / Product Backlog Item work item types called “Kanban Column”, but that would require existing customers to have to update their work item type definitions to utilize the feature. And, since the board’s column configuration was meant to be scoped to a team, using a “global field” didn’t work well.
We created a new work item tracking element we call a WIT Extension, which allows you to attach to an individual work item a field and a set of rules dynamically, at run-time, without updating the work item type definition. I underlined that last part, because that’s pretty exciting stuff.
For this feature, we created the Kanban Column WIT Extension, which contains a single field “Kanban Column”, and a set of rules on that field. In this case, the rules ensure that the State and Column are kept in synch, as per the State/Column mappings defined in the Customize Columns dialog. For example, if you have the following column configuration:
We generate rules that look like this:
These rules fire when you drag an item to a Kanban Column, and we automatically update the State:
We also generate the rules in reverse, like this:
So that when you update the State, we automatically update the Kanban Column:
The Kanban Column field is scoped to the team, and appears as follows in the work item history. Note how the field is scoped to [Team Project\Team Name].
WIT Extensions are only attached to individual work items when those work items appear on a backlog. When an item is added to a backlog, the WIT Extension is attached, the field exists, and the rules are run. If a work item is removed from a backlog, then the WIT Extension is detached from the work item, and the field no longer exists, and the rules are no longer run.
Attaching/detaching is done dynamically via the WIT Extension’s predicate, which defines an expression which, if evaluated as TRUE, will attach an extension to the work item, or detach if FALSE. For each TFS Team, we create a unique Kanban Column WIT Extension that with a predicate that matches that team’s product backlog query. This is done automatically for you when you create the team. On every save, we will evaluate the work item against the set of WIT Extensions (one for every team), and will attach/detach as needed.
For example,. if change the area path, and move the work item from one backlog to another, TFS detaches the extension for the original team, and attaches the extension of the destination team. In the example below, we changed the area path to move it from Team B’s backlog to Team A’s backlog.
The “Extension Marker” field shows whether the WIT Extension is attached or not. You’ll also notice that the Kanban Column has a new value for Team A. How did we know how to do that? The current state of the work item was “Active”. We ran the rules on Team A’s WIT Extension, and the default column for “State=Active” was “Working”, and set it automatically.
You can configure two teams to own the same area path. Its not recommended, but it is possible. In this case, the work item would have two WIT Extensions attached to it. For example, let’s say both “Team A” and “Team A Clone” are configured to have the same area path. The predicate for the WIT Extension for both teams are identical and both would evaluate as true. In effect, the item appears on two different boards at the same time. But what happens if you change the column on one board? Here’s the answer:
Here is Team A’s board and column configuration:
Here is Team A Clone’s board and column configuration:
The work item “Item 1” is the same work item, but appearing in two different places. What happens, if I drag “item 1” from “WORKING” to “VERIFICATION” on Team A’s board:
TFS will run the rules on both extensions. It will look something like this:
Team A: When Kanban Column = Verification, then State must be Resolved. Team B: When State = Resolved, then Kanban Column must be one of: “Testing”, if not set to default column (which is Testing)
Team A: When Kanban Column = Verification, then State must be Resolved.
Team B: When State = Resolved, then Kanban Column must be one of: “Testing”, if not set to default column (which is Testing)
This will produce a work item revision that looks like this:
As you can see the new WIT Extension paradigm is pretty powerful. We have written it for the Kanban – Customizable Columns feature, but our goal is to expand the functionality to have parity with other work item fields. For example, while the field will show up in the work item history and is available from the object model, it is not available for queries, reporting, excel/project integration, and can’t be displayed on the work item form.
Eventually, we want to allow WIT Extensions to be created by our customers, allow the process to be defined in a much more componentized manner, rather than the monolithic way it is today.
For now, whenever you drag that tile from one kanban column to another, just know that there is a powerful new component in work item tracking that is managing the stuff under the hood.
@Bruce, what is supposed to show in the "Done" column are the 20 most recently completed items. More specifically, we do a reverse sort by "Closed Date", and take the top 20 items returned. This works great if all of your user stories has a value in the "Closed Date" field. If you have every that have no value (NULL), then that would explain what you are seeing. If you are using one of our out of box templates, then you should not get into this situation, as we always set the Closed Date when you mark an item as Closed/Done/Completed. However, if you had customization, or an upgraded server, its possible you have this situation.
If you do, one suggestion would be to create a query that returns all user stories with a Closed Date of NULL, and set all of those Closed Dates to some older date.
I am a PM in the Platform Services Group of Global Foundation Services. We are very much interested in having a flexible KanBan board capability in TFS. We have been using the Agile Template, but the "Board" view on has Item State and not "Where" in a customizable workflow. What you show above is very interesting. Do you have a "sandbox" TFS project that has this "installed" that I can work with to get a feel for how it works? are you familiar with the KanBan Board in the EE Toolbox ( http://kanban ). This looks good, but appears to not be supported any more. THANKS :-)
Great progress - I would to be able to configure who who the work item becomes automatically assigned to when the work item is moved to a new column. Example - feature definition is now complete and I drag it to "Ready for Development". Doing this assigns to my dev lead so he knows to take next steps.
I'd like to add a "review" column for the task's bit before DONE, so every task gets a review.
Can this be done?
@HK, it is not possible yet to add your own columns on the task board. It is on our backlog though.
Is it possible to create a work item query to report on the Kanban states?
I am perplexed by a couple things.
Kanban is definitely a feature that helps with Agile processes, Scrum for example. If I am doing Scrum (or any number of Agile processes), I have iterations where the work on a Story gets done. This is the Coding, Testing, and similar States that are always shown in the TFS Kanban board descriptions (like this one).
But the Kanban view is not available in iterations. Why can't I use Kanban boards where the coding, testing, etc is actually done? TFS definitely recognizes iterations in the Control Panel for a given project, so the iterative development concept is in TFS.
If I am using the Kanban boards in the backlog as described, how would I manage any form of iterative development -- where I have a specific set of PBI I need to complete and then demonstrate every n weeks? The backlog contains all the work I might do. The top of the backlog is definitely the PBI's I am likely to schedule into a coming Sprint, but I have no way of limiting the view to a defined Sprint, or show (with color coding or just a horizontal dividing line) what I plan to complete in this Sprint.
Is anyone using the TFS Kanban board to manage iterative development? How?
@England, I hope I have understood your comment correctly. If not please let me know.
I believe you want to filter the Kanban board by iteration. That is not possible today. It is however on our list as one of the improvements of the board.
If you are interested to get a view of what stories you have finished in a sprint, then you can use the iteration backlogs by selecting the iteration on the left, or you can use the work item queries to get that list.
What I have also seen in the past is that people create a column for each sprint to indicate in what sprint it is deployed.
Let me know if I misunderstood you, or if you have follow up questions
TFS Program Manager
You did understand my question. Thank you for taking the time to reply
What I really need is a Kanban board for the Stories in an iteration, and this is something you can't do now, but is in your backlog. Have someone drag that up near the top please!
The idea of columns for each Sprint is interesting, but...
1) If I were to use this for preliminary planning on future Sprints, there is no good way to get these pre-selected Stories into a Sprint. You can't drag them to the Sprints on the left, and there is no way to query them and bulk edit the group to add an iteration path..
2) Adding Stories to columns representing past Sprints is also vaguely interesting, but since there is no way for Stories to move to columns on their own, I have a lot of dragging to do. it seems I could accomplish the same thing faster by writing a query for past Sprints, sending the results to Excel, and building the display there. This would also give me more than just titles - I could add effort as an example.
The only way I can see this being used for Scrum, is to put pre-Sprint activities in the columns. Things associated with drafting a Story, having it reviewed by coders and testers, whether it was waiting for more information from the Product Owner, and finally when it is groomed and estimated.
With iteration filtering, this would be great.