Kanban customizable columns, “under the hood”

(This blog post is also posted on the Visual Studio ALM Blog)

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.

Comments

• Anonymous
  March 05, 2013
  The comment has been removed

• Anonymous
  March 07, 2013
  Will be able to use this new WIT extension to somehow enforce child link types? For example, Requirements can only have child linked Features, Features can only have child linked Epics, Epics can ONLY have child linked User Stories, User Stories can only have child linked Tasks. We need to enforce children link types for reporting purposes... we don't care about the other link types...but we want to enforce the following "you can't create a User Story UNLESS it is linked to it's parent Epic, if no epic exists you have to find the feature and create a child Epic under the feature, if no Feature exists then you have to find the parent requirement and create a child Feature under the requirement, if no requirement exists FULL STOP - WHY ARE YOU WORKING ON THIS UNKNOWN THING?????

• Anonymous
  March 12, 2013
  Wonderful features! One more questions is can we map multiple states to a single kanban column? For example, mapping both "Approved" and "Committed" to "Coding" column?

• Anonymous
  May 05, 2013
  Very good feature. when could we expect to have the possibility of querying on this field from the interface ? Is something planned for the next updates of TFS ?

• Anonymous
  October 10, 2013
  Very nice!

• Anonymous
  February 27, 2014
  Is it possible to access these column values and rules using the tfs api?