Managing Documentation Projects in Team Foundation Server, Part 2: Tracking Work Items

Here's the second post on a series of posts on how we use TFS to managing our documentation process. Compliments of Allen Clark.

------

After our monthly planning meeting (discussed in my previous post), we copy the scenarios that we are going to address into an Excel workbook. We then break each of those scenarios down into tasks. To do that, we set up a work item list on another sheet. Each person on the team enters his tasks in Excel and indicates the scenario that each task supports. (See Working with Work Item Lists in Microsoft Excel for information about how to use lists of work items in Excel.)    The scenarios are captured in a custom field on the work item form. We’d like to use linked work items, but we don’t have that kind of support. It’s coming though, and I’m pretty excited about it.

We’ve tried doing this a couple of different ways. We started with an ID-bound list, but that didn’t work well for team members who prefer to work in Team Explorer to manage their individual work items. (On our team, that’s pretty much everyone.) We now use a query-bound list. I’ve also experimented with different queries. First, we manage our work in the same project as lots of other teams, so my queries always filter on Area. At one time, we also had an iteration called “Current” that we used to indicate that the work items are being handled in the current sprint. That approach worked pretty well, but it required some maintenance. At any rate, we stopped doing that because we need to use the same iterations as the rest of our organization. We have a separate field now to indicate whether a work item is assigned to the current sprint, and I was using that field in my queries. One problem, however, is that, after we close a work item, we have to remember to move it out of the current sprint. That’s just overhead. I figured out recently, though, that I can circumvent the problem by excluding from my query work items that were closed before the end of the last sprint.

I create a PivotChart report that we check weekly to make sure that we’re making appropriate progress. We often rebalance our workload in the second half of the sprint, based on how quickly we are completing all priority 1 work. The rest is gravy, so we don’t balance that. In my next post, I’ll talk about how I created the PivotChart.

 

-- Allen Clark (blog)