Headline: Always associate related work items to your changesets upon check-in. This post shows an easy way to do that using a Query that also reinforces the process.
Scrum Sprint Board Overview
Most projects I work on with Visual Studio and Team Foundation Server use the Scrum process template. I also do some work using what is now called Visual Studio Online or VSO. This used to be called Team Foundation Service, but I’ll call it VSO from now on. The Scrum template has a nice flow. I won’t go into too much detail, but below I show what the Sprint Task Board looks like. On the left you have Product Backlog Items (PBIs) with blue left margins (or Bugs with red left margins) and in the three other lanes of To do, In progress, and Done you have Tasks which have yellow left margins.
It’s really nice for team members to see what your working on. So I like to make sure that any task I’m working on I move into the In progress column. I make a habit of doing that before I begin working on the task.
Changeset Related Work Items
In my role many times I’ve had to go back and review what work was done for a particular PBI or Bug. If someone says the bug was fixed but there is no associated changeset for the bug I have to ask myself, “Was it closed as not reproducible? Did they ask the right people? How do you fix a bug without changing code?” It is possible, but I hope there’s at least a comment.
The easiest way to associate Work Items is at the time of checkin.
The Query
So, I said I had a query that made this easy. When you are trying to checkin, in Visual Studio (I’m using 2013 for this post) you see the Related Work Items section that has Queries and Add Work Item by ID.
I find it much easier to use a query and then just highlight the PBI (select with a mouse click) and the Task (select with Ctrl+Click so both are now selected) and drag them into that area just as the gray text says, “Drag work items here to link them to the check-in.”
Here is the query I use:
There are some groupings there, but they are very faint in the image, so I highlighted that in red. It is a simple query, but you’ll notice that it reinforces good process.
- A PBI must be committed before it shows up.
- A Task must be in progress.
- A Bug must be committed.
You shouldn’t be working on a Bug or PBI if they’re not committed. And Tasks should obviously be In progress and not just in “To do”.
Note: If I’m working on a large team (which I seldom do) then I might change the task section to be Work Item Type = Task And State = In Progress And Assigned To = @Me
@Me is a special placeholder so that you can share the query with others and they don’t need to change that. It can figure out who “Me” is.
For a nicer query I should not that I have a tree view:
With these settings:
Summary
DO associate work items at the time of check-in.
DO associate both the Product Backlog Item (or User Story if your using the Agile template) as well as a Task, not just one or the other.
And as you can see, this query forces you to move tasks into the In progress column so that you can easily drag it over into the Related Work Items area of Pending Change when you’re checking in code.