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.
Introducing, the WIT Extension
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].
How are WIT Extensions attached to work items?
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.
Can work items be on multiple boards?
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)
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.