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?