My Work Kanban Support in Visual Studio 2012 Update 2

Category:General PostTag: :

My team at Microsoft is responsible for the My Work feature in Visual Studio Ultimate.

The My Work feature focuses a developer’s immediate work in a single, actionable view. My Work presents TFS Work Items assigned to me in a view that allows quick and easy integration with checking in code. This aims to reduce the friction of associating Work Items with check-ins, a process which has an annoyingly high number of clicks without My Work.

In previous versions of My Work, only two types of Work Items appeared in the My Work panel. It has been generally accepted good practice to associate only Tasks or Bugs with check-ins. In a Kanban world, Task level work is often represented as a state or column on the team’s board. Instead of using Tasks, more teams will not create Task Work Items and instead will orchestrate their work using simple PBI or User Story Work Item types and move those across the board to represent state.

To support Kanban through the My Work feature, developers can now see more Work Item types that might be assigned to them. Generally, any Work Item type that is a:

  • Requirement (User Stories, PBIs, etc)
  • Task
  • Bug

Here is an example of how this might look using the Scrum 2.2 process template.

clip_image001

Any of these Work Items may be associated with pending changes so that future check-ins will associate with them.

clip_image002

There is also a difference in the workflow behavior of the feature. For Tasks associated in My Work:

Checking In Tasks

Given a Task is associated with In Progress Work
When a Check-in occurs
Then the Task’s state transitions to Resolved
And the Task is associated with the Changeset
And the Task will therefore no longer appear in the My Work pane

However, associated Work Items that are generally requirement types behave a bit differently.

Checking In Bugs and Requirement Work Item Types

Given a Work Item is associated with In Progress Work
When a Check-in occurs
Then the Work Item’s state does not transition
And the Work Item is associated with the Changeset
And the Work Item will still appear under "In Progress Work

This new behavior may seem a bit odd at first. When developers resolve Tasks with each check-in, the Task model makes sense. When developers make many check-ins over time associated to a given Product Backlog Item or Requirement, the latter model makes more sense.

Resolving Requirement Work Item Types in My Work

When clicking ?Finish? under ?In Progress Work?, note the language of ?if possible? in the popup that appears:

image

 

It turns out that for Requirement Work Item types, we cannot determine or infer the next logical workflow state. The reason for this is a long-standing design decision in how TFS WI state transition models work, and it is what it is. Given this, removing the Requirement Work Items from scope for the current developer become a wee bit more manual.

After checking in, the Work Items in "In Progress Work" may be handled in several ways:

  1. Open the Work Item and assign it to another person (WI disappears from My Work)
  2. Open the Work Item and manually transition it to its ?Done? or ?completed? state. (WI disappears from My Work)
  3. Click "Finish". The WI is still assigned to the current developer, and re-appears in the "Available Work Items" list.
  4. Commit pending changes. Regardless of whether the WI is marked ?associated? or ?resolved?, it still appears in My Work.

The Bottom Line

To transition a Requirement Work Item Type from your My Work pane to its next logical owner or state, open it and make the changes to the Work Item as appropriate. All the features allowing associating to current and future code check-ins still work as before, but taking your name off a given Requirement Work Item must be a more deliberate choice as must moving it to a ?Done? state.

4 thoughts on “My Work Kanban Support in Visual Studio 2012 Update 2

  1. does this mean that we have to create a task for every little checkin, or actively choose associate every time we do a small check in? Both options extra effort and potential errors. These would lead to higher wip amounts for each task if I’m not mistaken

  2. No. “Associate” is the default association type. Associating to a Work Item is never required. You may associate multiple checkins with a single Work Item by simply keeping in “In Progress Work.”

    Finally, nothing changed at all for Tasks.

  3. So Dave, if we want to retrofit this behavior in the Scrum 2.1 template we need to update the work item types with the new 2.2 ones right? As well as the board xml file right?

  4. I actually don’t know what you mean by the board XML, ET. This is just how we surface WIs in My Work. The Kanban feature in the boards is a function of the site.
    We are keying off the WIT Categories, so I think it should still work in Scrum 2.1. So long as the process template has work item categories.

Comments are closed.