Per Salmi

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.

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

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:

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.