Using Kanban with TFS

I’ve been actively campaigning for Kanban within our organization. This means giving lunch info-sessions, lending my ear to projects that need a boost, speaking with management and project managers. What I find so fascinating is that people get charged by such a simple concept. It can’t be this easy – but it is – and it’s applicable to most projects. Really? Really.

I’m thrilled to see people “get it”, because it’s easy to draw parallels between work as a pipeline and continuous delivery. Concepts like “push-to-deploy”, continuous integration and regression testing graft directly to parts of your workflow. And while the core concepts of continuous delivery aren’t prerequisites to Kanban, they are certainly mutually beneficial. By leading with Kanban, it’s easier to see value proposition of continuous delivery.

A common theme from all my discussions is I strongly recommend teams “resist the urge to replace a whiteboard with software”. Software can be a trap if applied too early to the process. Pick the wrong tool and you’ll spend your time worrying about tooling rather than the issues that are preventing you from delivering value. Nothing beats the immediate, tactile capabilities of a post-it note moving from one column to another. Focus on the workflow, foster adoption within the team, optimize and then find software to fit your needs. It should rarely be the other way around.

Unless of course, your team is remote.

I’ve heard of some innovative ways to get around this limitation, including a webcam pointed at your Kanban board. This seems like too far a stretch for me, and it’s time for my project to move our spreadsheets and post-it notes into a more centralized digital format.

While there are many cloud-based solutions, a critical feature for me is to own the data. And integrate directly with Visual Studio. (Okay, two key features). Team Foundation Server does Work Items. Let’s start there.

Customizing Work Item Definitions

Out of the box, the definition for Task has all the fields we need to implement our Kanban workflow. The main customization that we need to make is to the State field: we’ll model the various stages of our workflow using this field.

Our current workflow looks something like this:

• Proposed: This is our backlog
• Active: Items that will be included in this release.
• Selected: These are items that we will develop next.
• In Development: Items being actively worked on.
• Ready for Test: Development is complete and is pending deployment or verification.
• Testing: Items that are being validated by testers.
• Acceptance: Items at are ready for client review.
• Closed: Completed items.

We’ll need to model these various states in our work item definition, which we can retrieve from TFS using the following command line:

witadmin exportwitd /collection:https://<tfs-server-name> /p:<project-name> /n:Task /f:task.xml

Our State field is represented in the work item definition as:

<witd:WITD application="Work item type editor"
           version="1.0"
           xmlns:witd="http://schemas.microsoft.com/VisualStudio/2008/workitemtracking/typedef">

  <WORKITEMTYPE name="Task">

    <FIELDS> <!—- simplified for clarity -->

      <FIELD name="State" refname="System.State" type="String" reportable="dimension">
        <HELPTEXT>The workflow state of the task</HELPTEXT>
      </FIELD>

    </FIELDS>

    <WORKFLOW> <!-- simplified for clarify -->

      <STATES>
        <STATE value="Proposed" />
        <STATE value="Active"/>
        <STATE value="Selected" />
        <STATE value="In Development" />
        <STATE value="Ready for Test" />
        <STATE value="Testing" />
        <STATE value="Acceptance" />
        <STATE value="Closed" />
      </STATES>

    </WORKFLOW>

  </WORKITEMTYPE>
</witd:WITD>

Transitioning between States

One of the powerful features of customizing the work item definition is the ability to define rules that govern how the item transitions between states.  There is a bit overhead to define these transitions and it can become cumbersome if you have a lot of states, but overall this is a good exercise to formalize what each column means and why something would move from one state to another.

State transitions are fairly easy but there are a few small caveats:

• You must provide a default state (transitioning “” to “Proposed”)
• Each transition must have a default reason, plus any number of additional reasons.
• Any transition that is clearly not defined is not supported.

There are a lot of neat features that you can define here, some of which will have to wait for another post, but here’s a quick excerpt that demonstrates state transitions:

<witd:WITD application="Work item type editor" 
           version="1.0" 
           xmlns:witd="http://schemas.microsoft.com/VisualStudio/2008/workitemtracking/typedef">
    <!-- edited for clarity -->

    <WORKFLOW>
        <!-- snip -->
        
        <TRANSITIONS>
            <TRANSITION from="" to="Proposed">
              <REASONS>
                <DEFAULTREASON value="New" />
              </REASONS>
            </TRANSITION>
            <TRANSITION from="Proposed" to="Active">
              <REASONS>
                <DEFAULTREASON value="Scheduled in Release" />
              </REASONS>
            </TRANSITION>
        
            <!-- not shown:
                proposed -> development
                proposed -> closed

                active -> selected
                active -> development
                active -> proposed
                active -> closed
    
                selected -> development
                selected -> active

                development -> ready for test
                development -> selected
                development -> active

                ready for test -> testing
                ready for test -> development

                testing -> acceptance
                testing -> ready for test
                testing -> development
                testing -> selected
                testing -> active

                acceptance -> closed
                acceptance -> active

                closed -> active
             -->
    </WORKFLOW>

</witd:WITD>

With our customizations in place, we can push our work item definition back to TFS:

witadmin importwitd /collection:<server-name> /p:<project> /f:task.xml

Now when we open a Task definition, we see that the State transition drop-down is constrained by the transitions we’ve defined and the Reason column is prepopulated with our reasons.

Visualizing TFS Work Items in a Kanban tool

TFS has a rich API and many integrations available (especially with Office stack) but I certainly wouldn’t have gone through all of this trouble if there wasn’t a replacement for my whiteboard and post-it notes.

I recently found this free tool, provided by SEP, that does most of things I want. Because the application supports touch, I’m able to put my HP TouchSmart to good use.

My next post will talk more about setting up the SEP teamworks tool.