Advance WorkItems to next state on check-in

Nearly two years ago, I had a project where we used whiteboard and post-it notes for our Kanban board. Perhaps one of my favourite aspects of using a whiteboard was the non-verbal communication that occurred between team members: when a developer would finish a task, she would stand-up from her desk, take a deep breath and well deserved stretch then rip her post-it note from the In-Progress column, slap it into the Ready-for-test column and then yank one from the Next column. Everyone on the team would look up, smile and go back to coding.

Alas, whiteboards and post-it notes only work when all team members can see the board and when you’re teams are remote you will need a software solution. Our organization is big on TFS, and I’ve found much luck using SEP Teamworks to simplify the data and present it in a Kanban fashion.

One of the challenges with using software for task tracking is that it loses that tacit capability. Choosing the wrong tool can mean you spend more time managing the tool than building software.

Here’s a quick post that illustrates how you can leverage features of TFS workflow to automate your Kanban process a bit, so you don’t have to harass your team members so much.

The xml schema for our User Stories, Bugs and Tasks contains elements that describe fields, user-interface and workflow. The workflow element is interesting because it allows us to define the supported transitions between states and default values for fields in each state. It also supports this sweet little addition that will automatically transition a work-item to a different state simply by including the following Action in the Actions element:

<TRANSITION from="In Development" to="Ready for Test">
  <REASONS>
    <DEFAULTREASON value="Development Complete" />
  </REASONS>
  <FIELDS>
    <FIELD refname="System.AssignedTo">
      <ALLOWEXISTINGVALUE />
      <EMPTY />
    </FIELD>
  </FIELDS>
  <ACTIONS>
    <ACTION value="Microsoft.VSTS.Actions.Checkin" />
  </ACTIONS>
</TRANSITION>

Although the schema suggests that it would allow custom actions to be plugged in here, only the Microsoft.VSTS.Actions.Checkin action is supported.

To take advantage of this feature, simply associate your work items to your check-in and mark the action as “Resolve”.

Kanban, TFS style.

I’ve been building up a system of tracking tasks using User Stores in TFS for almost two years and I’ve been blogging as I go. Over time, I’ve written several short emails to colleagues pointing them to the Kanban tag of my blog, but that tag list is a bit heavy. Here’s a quick recap of helpful posts that can get you up and running.

Getting Started

If you’re a developer, team lead or architect – you should start here.

1. My first month with Kanban – a quick walkthrough that discusses my initial observations with Kanban. Old school, using a whiteboard and sticky-notes.
2. Using Kanban with TFS – a high level overview of the process I’ve adopted for tracking Tasks in TFS using Kanban columns. Provides an overview of customizing work-items.
3. Configuring SEP Teamworks – a walk through how to set up SEP Teamworks, my favorite free tool for viewing TFS items in a sticky-note fashion.
4. Using User Stories with SEP Teamworks – Revisiting my workflow slightly to adapt to using User Stories instead of just individual task tracking.
5. Setting up Areas and Iterations – Shows you how to organize your stories into TFS Areas & Iterations, and then using SEP Teamworks features to simpli

Reporting and Querying

If you’re a project manager and you want to set up SEP TeamWorks. Please read:

1. Working with TFS WorkItems in Excel – includes a walk through on how to set up your machine, and export queries to Excel.
2. Configuring SEP Teamworks – a walk through how to set up SEP Teamworks, my favorite free tool for viewing TFS items in a sticky-note fashion.

Advanced Customizations

1. What’s new in SEP Teamworks 1.0.31 – highlights some of the new improvements in the latest release: Card Editor to customize views, creating linked work items.
2. Marking Kanban items as Blocked – demonstrates how to customize your work items to take advantage of marking items as blocked.

Working with TFS work items in Excel

Visual Studio ships with a pretty good query engine that you can use to retrieve a list of work items, but if you need to change the filter criteria frequently or calculate totals for estimates or remaining work, Visual Studio can’t cut it on its own. Fortunately, the integration between TFS and the Microsoft Office suite is fantastic and we can export our data into Excel with a few simple clicks.

Hey, if you’re reading this because you’re a project manager at my office and I sent you this link, you’ll need a few things on your machine for this to work:

1. Download a copy of Visual Studio Team Explorer.  It’s basically a slimmed down shell of Visual Studio without all the code editing features and it includes all the goodies for you to query work items and export to Excel.  If you have Visual Studio installed, you can skip this step.
   • Visual Studio Team Explorer for Visual Studio 2012
   • Visual Studio Team Explorer for Visual Studio 2010
2. You’ll need read permissions to the TFS Team Project. Reach out to your friendly IT support for this.
3. If you’ve never connected to the TFS server before, you’ll also need the TFS Server name, Team Project Collection name, and Team Project name.

There are two ways to get TFS work items into Excel:

• Import TFS Work Items into Excel
• Export TFS Work Items from Visual Studio or Team Explorer into Excel

Importing TFS Work Items into Excel

Let’s assume that you’ve never connected to TFS before. Managing this from Excel is actually pretty easy.

1. Open Excel and create a blank workbook
2. Select the “Team” option from the Ribbon. If “Team” isn’t available in the Ribbon, you haven’t installed Team Explorer. (see above)
3. Select the “New List”.
   
4. The Connect to Team Foundation Server dialog will appear.
   
5. Click the Servers button. The Add/Remove Team Foundation Server dialog will appear.
   
6. Click the Add button to open the Add Team Foundation Server dialog.
   
7. Fill in the server name and details provided to you by IT. You’ll know you’ve entered the right information when the Preview matches the information provided.
   
8. After all the connection information is provided, select the appropriate Team Project Collection, and the Team Project that you want to use.
   
9. Finally a dialog appears that lets you select an existing TFS query.
   
10. Once you’ve selected, the query, click OK. Voila!
    

Exporting TFS work items to Excel from Visual Studio

Exporting your favorite query from Visual Studio to Excel couldn’t be easier. Simply run the query and then select “Open in Microsoft Office –> Open Query in Microsoft Excel”

Famous Last Words

Here’s a few tips with working with work items Excel:

• At any time you can get the latest by clicking the “Refresh” button
• If you make changes, you can push them back to the server by clicking the “Publish” button. (You’ll need write permissions for this)
• This worksheet is tied directly to the server, so don’t forward the spreadsheet to individuals that don’t have access to the data. For this, copy the entire worksheet to another worksheet.

Using Areas & Iterations in SEP TeamWorks

TFS supports a concept that allows you to organize your work items into different functional areas and chronological iterations, called Areas & Iterations. This post shows you how you can use these features to groom your Work Items using SEP TeamWorks.

Areas & Iterations in TFS

Areas & Iterations can be accessed from the Team Explorer.

Visual Studio 2012

Selecting this item opens a single dialog that allows you to configure both Areas & Iterations. Note that you’ll need to be an administrator for your Team Project in order to make changes.

Areas

The following shows an example of functional areas for a product.

Iterations

The following shows an example of Iterations.

Both Areas & Iterations can be nested so you can structure them any way you want. The system is also flexible if you delete an item you’ll be prompted to select a new value work items that would be impact.

Querying Work Items based on Path

When you query Work Items, you can find all items within the hierarchy.

Using Swim Lanes with SEP TeamWorks

SEP TeamWorks doesn’t have any built in mechanism to filter your TFS queries, but it has a fantastic feature that let’s you group content using swim lines.

Swim Lanes can be turned on any query (except hierarchical queries), simply right-click (long-press on your touch device) to open the context-menu and choose Edit Swim Lanes. You can also access the swim lanes from the Options button in the UI.

You can create Swim Lanes for most fields, assuming that the Work Items in the Query support the fields you’re grouping by:

Here’s the same query with a swim lane enabled for Iteration Path.

Where swim lanes really shine is you can use them to edit your work items without opening them simply by dragging them into another lane.  Here’s some great examples:

• Bug Triage: write a query that pulls back all new bugs then use swim lanes for Severity, Priority, Found In or Triage status. 
• Product Planning: write a query for all User Stories then use swim lanes for Area path, Iteration path, Risk, Story Points
• Grooming the backlog: write a query for all Tasks then use swim lanes for Activity, Area, Assigned To, Remaining Effort

As you can see, with a little bit of planning and some creativity you can customize the tool to fit your needs. In the upcoming posts, I’ll look at common queries and exporting information out of TFS into other formats.

Until then, Happy Coding.

Using User Stories with SEP TeamWorks

When I first started with Kanban over a year ago, the post-it notes on my whiteboard represented Tasks and Bugs, which for the most part worked great. The two main challenges raised by the team, were:

• Developers had a hard time visualizing related tasks, which made it difficult to organize and plan effort. We also had the risk of being unable to deploy because some related tasks were unfinished.
• Project Managers had a hard time reporting progress on high-level features. Although they had access to the Kanban board, organizing a status report from low-level tasks and bugs wasn’t sufficient.

Kanban is intended to be an adaptive process, meaning that it’s not a full-featured methodology and you pretty much have to add your own rules and concepts to it so that you can adapt it to your needs. Other methodologies, like Scrum, have solved my problem by using User Stories to represent high-level features that you can group related tasks under. Developers could see related tasks; project managers could report progress on Stories – win / win. The only remaining challenge was how to represent User Stories on a whiteboard? (How do you associate post-it notes with a Story? Do Stories move on the board like Tasks do? If a few of the tasks for a Story are “ready for test” does the status of the Story change?)

I struggled with this challenge until I switched over to a digital Kanban board which afforded us the ability to produce different queries over the same data. We’re using TFS 2010 as a repository and SEP TeamWorks as a front-end to visualize task effort.

Querying and Displaying User Stories

The Agile Process Template used by TFS 2010 includes a User Story work item type which you can link tasks to in a Parent-Child relationship. You can write a simple query to obtain all parent-children tasks. 

Note that the TFS query that I’m using is a Work Items with Direct Links query, which allows me to pull back Children tasks as well as Related bugs. I also don’t nest my User Stories – this technically works within TeamWorks, but it seems a little odd and needs some further investigation.

SEP TeamWorks supports hierarchical tasks out of the box. Stories and their children are represented as swim lanes, with the first column representing the Story.  Note that because Stories are broken into swim lanes, you can’t use TeamWork’s swim lane feature to further refine the query. If this is something you want, you’ll have to set up different TFS queries.

Adjusting Kanban Workflows

While the workflow that I’m using for Tasks and Bugs would work for User Stories, it seems a little heavy to duplicate the process for Stories. I simplified the flow to make it easier to manage and for reporting status.

The flow for my Tasks and Bugs, which I’ve outlined in my previous posts, is:

• Proposed
• Active
• Selected
• In Development
• Ready for Test
• Testing
• Acceptance
• Closed.

For my User Stories, I’ve simplified it to:

• Proposed: the story does not have all the details, yet.
• Active: the story is well defined and is actionable.
• In Development: the story is being developed or validated by developers
• Testing: development has completed and the testers are running their test cases
• Acceptance: test cases are complete and its ready for client review
• Closed: the feature has been accepted / shipped / etc.

Note that SEP TeamWorks uses the Status column from all Work Items into its UI so I’ve repurposed my existing status definitions to simplify things.

Daily Operations

As mentioned previously, having our Kanban board as software solution allows us to query and represent the data in different ways. I use a combination of three different queries for my daily operations:

• Product Planning: I query only User Stories which allows me to see the high-level status of the project at a glance. I heavily use Areas & Iterations (I’ll blog about this next) to help organize and plan the project.
• Iteration Backlog: I use a hierarchical query as shown above to represent the current iteration.  This query allows me to see the detailed status of the Story
• All Work Items: This query returns all Tasks and Bugs and it resembles the Kanban board I’ve fallen in love with. This query allows me to see bottlenecks, developer allocations, etc.

Conclusion

Having User Stories has made a big difference for how we track and organize our effort, but it’s not without its challenges. There’s a special knack to writing stories and it takes some practices to get used to the format, which I’ll have to blog about later. For now, I hope that this post shows you how easily it is to introduce Stories into your Kanban flow.

Until next time, happy coding.

NuGet PackageRestore is awesome

It’s safe to say I’m a NuGet fan.  I’ve been using and following NuGet since the original Nubular days, but somehow I missed the significance of the Package Restore feature announced in version 1.7. I’ve had a chance to try it out. Simply put, it’s awesome.

Package Restore is a feature that allows your project to download and install packages as they’re needed, which means you don’t have to commit these packages into your source control repository. Java developers will recognize this feature as something similar to Maven, which has been around for while, but for .NET this is a very welcome change.

Enabling the feature in Visual Studio is pretty simple, just bring up a context-menu on the Solution Explorer and choose “Enable Package Restore”. Once enabled developers (and your build server) don’t even need to have NuGet installed to take advantage of this, they simply need an environment variable “EnableNuGetPackageRestore” defined.

The impact this feature has on your development team is subtle, but very powerful, and after using it on my current project I’m realizing how crippling our previous approach has been.

Up to this point my usage of NuGet has focused around the initial stages of the project, when the solution and dependencies are initially being put together. In this scenario, I’m checking the packages NuGet installs into my source control which means other developers (and my build server) have everything they need to compile the solution after they’ve got the latest source from the server.

Checking libraries into source control exposes a few interesting, and a bit too common, pain points:

• Upgrading packages isn’t easy because developers may manage the dependencies for projects manually, even if they have NuGet installed. In a way, I can’t blame the developers for doing this because this is, after all, how we’ve been managing our dependencies for years. But ultimately this practice defeats the purpose of using NuGet in the first place: I can’t upgrade all my projects in my solution to a newer version of the package if there are projects that NuGet isn’t aware of.
• Source control can get bloated with different versions of packages over time. If developers are using NuGet to manage their packages, they might forget to remove old versions in the repository. It takes a bit of extra discipline to stay on top of this.
  • Side note: depending on the connection between your build agent and server this bloat is potentially slowing down your build.
• Developers can still experience problems where their Local workspace isn’t current. This problem happens fairly frequently, if a developer isn’t getting the latest copy of the packages folder on a regular basis.

Over the past few weeks, I’ve found the package restore feature addresses these concerns, plus a few extra perks:

• We’re more open to trying out new packages because there’s less operational overhead. Developers don’t have to worry about breaking the build because they forgot to check in required assemblies, and the impact to remove the dependency is limited to the project file and config file. Less operational overhead makes the team more flexible to change when necessary.
• There’s new found desire to move existing dependencies to NuGet packages. NuGet has helped our team visualize the relationship between our dependencies which plays into how we’ll update and manage our packages, but it also automates the dependency management. For example, the process of duplicating a project’s dependencies when setting up a test project is greatly simplified. Once these benefits are realized, you’ll being to scrutinize the dependencies in the solution that aren’t managed by NuGet. In some cases, this has led us to create packages for our reusable libraries – which is so awesome because this will benefit our project and the organization as a whole. And that’s cool.

So there you have it. If you’re not using NuGet, you should download it and give it a try. If you’re already using it but not leveraging Package Restore I challenge you to give it a spin – does it make your team productive? Leave a comment below!

Happy coding.

Marking Kanban Items as Blocked

Sometimes items in your Kanban workflow reach a state where they cannot proceed. Maybe they’re have a dependency on another item; maybe there’s an issue or pending decision. When this happens, you want to increase the visibility of these issues by marking them as blocked.

Fortunately, the SEP Teamworks tool which I mentioned in my last post, supports such a feature. Simply right-click (or on a touch device, tap-and-hold) and use the context-menu to mark it as blocked.

Simple, right? Well, the first time I tried this feature, the tool crashed. Turns out that you must have a Blocked field in your work item definition.

Adding this field to your work item definition is easy.

1. Retrieve the work item definition from your TFS server using the witadmin exportwitd command:
   
   

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

2. Insert a new field definition into the FIELDS node. Note that the namespace doesn’t matter. As TFS doesn’t contain a definition for Boolean fields, you must set it up as a string with Yes/No values.
   
   

   <witd:WITD application="Work item type editor" version="1.0" xmlns:witd="http://schemas.microsoft.com/VisualStudio/2008/workitemtracking/typedef">
     <WORKITEMTYPE name="Task">
   
       <!-- edited for clarity -->
   
       <FIELDS>
   
         <FIELD name="Blocked" refname="Custom.Blocked" type="String">
           <ALLOWEDVALUES expanditems="true">
               <LISTITEM value="Yes" />
               <LISTITEM value="No" />
              </ALLOWEDVALUES>
              <DEFAULT from="value" value="No" />
         </FIELD>
   
       </FIELDS>
     </WORKITEMTYPE>
   </witd:WITD>
   
   

3. (Optional, but highly recommended) If you want to change the Blocked field outside of the SEP Teamworks tool (such as inside TFS), you’ll need to describe the field inside the FORM node. The syntax is relatively straightforward:
   
   

   <witd:WITD application="Work item type editor" version="1.0" xmlns:witd="http://schemas.microsoft.com/VisualStudio/2008/workitemtracking/typedef">
     <WORKITEMTYPE name="Task">
   
   
       <!--edited for clarity -->
       <FORM>
   
          <Control Type="FieldControl" FieldName="Custom.Blocked" Label="Blocked:" />
   
       </FORM>
   
     </WORKITEMTYPE>
   </witd:WITD>

4. Lastly, push your changed work item definition back to the server using the witadmin tool:
   
   

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

With these changes in place, the SEP Teamworks tool puts a visual over blocked items.

My next post will look at some other handy customizations to the TFS work flow.

Configuring SEP Kanban board

In my last post, I showed how I’ve modified the State field of my TFS Work Item definitions to resemble my Kanban workflow.  This post we’ll take a look at how I’ve configure my digital board and highlight the pros and cons of my current approach. Maybe you’ll find this useful, maybe you’ve got some recommendations – either way, I’d love to hear from you.

Setting things up

1. Download and install the SEP Digital Kanban board: http://www.sep.com/labs/teamworks/
2. Run the MSI. Defaults all the way through.
3. Run the app. You’ll need to configure the board with a few settings.

4. Pick a server:
   
   

5. Select your TFS Server:
   
   
   
6. Select your TFS project and select a Query that returns all your work items. I have a small query to return only Tasks and Bugs: 
   
   
   
7. In order to get the workflow correct, you’ll need to manually order the States of the Work Item. Change the Work Item States –> Order.
   
   
   
   
   
   The Item states should be in this order:
   
   
   • Proposed
   • Active
   • Selected
   • In Development
   • Ready for Test
   • Testing
   • Acceptance
   • Closed
     
     
8. Depending on your Project collection, you may have additional work item definitions with their own states. You may have to turn off any states that aren’t included in our work item states. (This screen shot shows Resolved, Design and Ready states have been turned off)
   
   
   
9. Set up some limits.
   
    

Cool Features

Touch enabled: While the main feature that I was interested in was representing my tasks in TFS, what sold me on this tool was the fact that it was designed for touch. My HP TouchSmart now operates as our digital kanban board.

Swim lanes: Another great feature is the ability to view the features in their own collapsible Swim Lane. There are many great uses for swim lanes such as grouping by Area, Iteration, Priority, Assigned to, Triaged, etc. Most scalar value fields can be used. What’s also great about this feature is that you can simply drag a work item into a swim lane to assign that field value. This makes it easy to keep your work items organized.

Create or Edit Work Items: The tool takes advantage of the form layouts defined in the work item definition, so you can get the same TFS Team Explorer editor experience right on your Kanban board. Large buttons at the top of the user-interface make it simple to add new bugs or tasks as they arrive, and I can open an item from a context-menu to get or edit details about the task at hand.

Caveats and Annoyances

Tasks and Bugs: Unfortunately, I’m only tracking Task and Bug work items because these are the items that I’ve customized. I would like to Use Stories where I describe the work as a high level story and then realize that effort in tasks. At the moment, I’m using TFS 2008 which doesn’t support hierarchal tasks, so I’m kind of stuck on that.  If I could track hierarchal tasks, I’m not entirely sure how I would use this tool – where should the Stories appear on the board if only some of the development tasks are complete?

No sub-columns: One of the features that this tool lacks is that ability to create sub-columns. Ideally I would like to treat Development as one column with two sub-columns (“In Development” and “Ready for Test”) and put a WIP limit on Development. Having this capability highlights testing bottlenecks and would ensure that the development team is invested in seeing their completed efforts are delivering into the client’s hands.

No central configuration: While I’m sure that the target usage for this application is to use it on a touch-device as a whiteboard replacement, the tool doesn’t offer any means to save the configuration externally or toggle between configurations. This is a minor annoyance because most of my team members are jumping on board with this tool to provide their status updates. Also, as I have multiple projects, a means to jump between configurations would be ideal.

All in all, it’s a great resource.

My next post will talk more about customizations to the Work Item definitions that support my workflow.

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.