Managing work for Team System

Martin Woodward, one of our newest Team System MVPs, was recently asking me about how we manage work within our team and if I'd be willing to share our TFS work item types to give a real world example.  Our dogfood usage of TFS is one of my favorite topics and I'm interested in sharing with you our experiences both good and bad in this space.  I don't for a moment argue that we have the ideal implementation of TFS.  We're frequently trying new things, some work well and others don't.  Plus we're part of a larger team (Developer Division) and as a result, there are constraints and requirements placed on us that don't map super well to how we'd like to run our Team System team.  Probably sounds familiar to many of you. 

Looking at our dogfood server, we currently have the following work item types in use for the Orcas project:

• Value Prop: I've written previously about our use of Value Props in our planning process.  They represent the high level, customer focused, value that we hope to deliver in an upcoming release. In the context of managing work in TFS, Value Props are used as top level containers for Experiences (see below) which are in turn containers for Features.  We have created reports that show this work breakdown and the progress we've made against each of these Value Props.  Because the linking functionality in TFS v1 is somewhat limited, we've had to institute various policies and create special reports to ensure that the parentage from Value Prop to Feature is correct.  This is clearly something we're pushing to address with future versions of TFS (I love dogfooding!)
• Experience: We break Value Props into a series of user Experiences as a way to help us organize and plan our features.   We found that this logical step was necessary because the jump from high level Value Props to low level features was just too difficult conceptually.  Now that we're executing, Experiences are not used much except as a connection between Value Props and Features.
• Feature: This is where the rubber hits the road and so the Feature work item type is very rich and I should probably spend an entire post or two describing how we use it.  It's the thing, more than any other, that we use to track our progress towards shipping.  Orcas has something like 350 features planned to be delivered.  Features go through a number of states as they get planned, approved, worked on and completed.  As this happens, they get slotted into various iterations for implementation and testing.  We track start and end dates as well as estimated work complete and remaining through this work item type.  It's also the place that we report on the state of our various quality gates (like level of code coverage from automated tests) that are required to be satisified before we check the feature into the main source branch.  Like I said, I need to spend a lot more time on this area because there's a lot going on here.
• Task:   We don't require all teams to track their tasks in TFS but a lot of Team System teams do.  Many enter and maintain Tasks through the Excel and Project integration and update them on a regular basis.  Tasks can be associated to a Feature through a simple ID field so that it's easy to query on all tasks associated with a particular feature (you can't use links in this way, unfortunately...something we're working on for upcoming versions).  We use the MSF CMMI version of Task with a few more date and categorization fields.  They are either active or closed.  Teams use these to estimate time completed and remaining and roll that up through Excel or Project to update the Feature work estimates on a weekly basis.
• Issue: There are always a number of open issues that we need to drive to closure as a team so we use an Issue work item type within TFS to manage these.  Here we track owner, description, attention level (is it a divisional issue or something that only one team cares about), group affected and owner(s).  We used to manage these through a simple spreadsheet...I love having them in TFS so I can easily assign issues to folks on the team, maintain history of the issue and easily query for the latest information. 
• Bug: Here's another work item type that I could write a book about, and might if people want.  With over 70 fields on the bug form, we collect a lot of information about bugs to track where it came from, how we found it, what the customer impact is, who owns it, what the resolution was and a root cause analysis.  Fortunately, of those 70 fields, only about 10 of them are required for a new bug to be entered (more are required through the lifecycle of a bug) so it's not too overwhelming to report a newly found problem. 
• Icon:  This work item type was curious to me since I haven't been involved in its usage.  Turns out we have 147 instances of this work item type and it appears we use it to track the lifecycle of graphical elements associated with Visual Studio.  Pretty cool actually...I would have assumed that a standard Task would work okay here but upon closer inspection of this work item type, it's clear that there are special needs for this work.  For instance, they track the format info (type, format, color depth, transparency, size, etc) as well as well as filenames and various approvals required for inclusion. 
• UE Release Work Request: Here's another work item type that I wasn't familar with.  The User Education (documentation) release team uses TFS to manage the incoming requests for assistance from their various internal customers.  This customized work item type focused on the specifics of integrating, building, releasing, and troubleshooting the documentation. 

I'm excited that we're always finding new ways to utilize Team System to manage Team System.  It drives goodness into the product as we solve the problems we find as we push the system in new directions.  There are a number of additional ways that I'd like to push the system including tracking our minor releases (such as TFS PowerToys) and feature dependencies.  As we do this, I'll be sure to share with you.

I'd be happy to further explore and describe any of these work item types as people find valuable.  Let me know what you want to learn more about and I'll see what I can do to share what we've got.

Thanks!

Comments

• Anonymous
  October 17, 2006
  Excellent post!  Admitidely, that could be because I asked the question - but this helped a lot.  Your team has one of the more complicated software problems around and while you challanges are different to many of those faced in the enterprise, understanding why you decided to use certain things where is invaluable (for example, the task - feature linking field to get around limitations with the linking service) Thanks for sharing this with us.  I would love to know more about the fields you use in each work item type and why.  A copy of the process template so that we could take a look at it in more detail would also be very interested - but I understand if you are not able to share that. Anyway, thanks again! Martin.

• Anonymous
  October 18, 2006
  Etienne Tremblay on Team Build the ins and outs and TFS Install Scripts V2. Sanjeev Garg on So I am...

• Anonymous
  October 19, 2006
  Well, I didn't ask the question but I agree with Martin :)  We also use links between our work items types to create a 4 level hierarchy (Requirment --> Analysis --> Tasks --> Bugs) and use reports to track it down. I would love to hear more about the 70 fields bug, especially how to collect and analyze the data affectively

• Anonymous
  December 18, 2006
  Last week we did a four days workshop on Visual Studio Team Systems . We have collected a number of resources

• Anonymous
  January 14, 2007
  Previously, Sam Guckenheimer blogged about Scenarios, Value Props and Experiences and introducing them

• Anonymous
  January 15, 2007
  I've been meaning to write a more detailed post describing the mechanics for managing work for Team System

• Anonymous
  August 17, 2008
  A good read: Applying Value Up at Microsoft by Sam Guckenheimer (also available as 60-minute-webcast

• Anonymous
  September 03, 2010
  Confused.... Is this 'Feature' work item type a custom item? I am unfamilar with this one and searching the web as you can imagine is a nightmare.