During the past week I have been busy creating a Team System process template to be used by the MSFT Development group where I work.
While discussing this topic with my boss and showing him how the MSF for CMMI work items look like, he asked that I add a field to indicate the current track, workstream and activity. To be more precise, he asked me to use the "Area path" field for workstreams and activities, and to add an extra field to specify the track.
I proceeded with these changes (yes, a bit hastly, I admit). Once faced with a real project for which I had to encode work items, I realized that I absolutely needed the "Area path" field and that I had no idea what to write in the new "Workstream & Activity" field. This started a discussion with my boss where he insisted that "Area" was not an MSF concept and that we needed to specify "Workstream & Activity".
It was time to clarify these concepts! The definitions below have been constructed with the following sources:
-  MSF for CMMI Process Guidance
-  MSF Essentials, Michael S.V. Turner, Microsoft Press
-  MSDN
-  VSTS Forum
Tracks are overlapping, coordinated groupings of certain activities aimed at producing relevant deliverables : 5 enactment tracks (Envison, Build, Plan, Stabilize, Deploy) and 1 governance track (Governance). 
Tracks are groupings of workstreams and activities which lead to a governance checkpoint. Several tracks can run concurrently providing the entry conditions for the track are met and resources are available to start the work within the new track. Tracks reflect the changing nature of a project throughout its life cycle. Different roles feature more or less prominently in each track. 
Workstreams are groups of activities that flow logically together and are often associated with a particular role.  (They can occur once in lifecycle or once in an iteration. They are defined by entry criteria, activities and exit criteria.)
Roles do activities, which are grouped in workstreams. Activities may produce certain work products and may require work products in certain states before they can be performed. 
They are tracked by Work Items. 
A work item is a database record which Visual Studio Team Foundation uses to track the assignment and state of work. 
Work products are the documents, spreadsheets, project plans, source code, and other tangible output from the activities. 
Iteration: The scheduled iteration in which the task is carried out. 
An iteration is a predetermined logical stopping point in a delivery life cycle. Typically, it is a predetermined period (time-boxed, for example, 4 weeks), a predetermined set of features or a predetermined capability. Regardless of approach, there is a predetermined level of quality that must be achieved. 
The project iteration is a process hierarchy of events in the project life cycle. When the team project is first created, the life cycle of the project is expressed in terms of iterations. The default number of iterations is determined by the process template used in creating the team project. For example, the process template for MSF for Agile Software Development establishes a lifecycle with three iterations (0, 1, and 2). 
There are two types of projects: date-driven and functionality driven. If your project is date driven, you probably have a date in mind for its delivery (such as a trade show) and want to scope the functionality appropriately. The iterations are fixed periods of time (between two weeks and two months). You can divide the project into several iterations using a calendar or project. If the project is functionality driven and you want a date, perform a few iterations and get your team's velocity. The project manager can then conduct a feasibility analysis (see workstream "Guide Project") to find the end date. Without some velocity information, any feasibility analysis is likely to pretty inaccurate. 
Area: Used to group the task into an appropriate feature or team area. 
Areas and Iterations are actually hierarchies defined outside work item tracking, and can be used to organize tests as well as work items. They're treated as special fields in work item tracking. [?]
The project areas are an organizational hierarchy of components and features. When the team project is first created, there usually is no organizational structure to the project. You manually build the tree structure of the project by creating nodes to represent major components and subcomponents, and major features and sub-features. The project areas are then used to organize and display work items into logical groupings. 
What is the relation between these concepts? It seems clear to me that we are dealing with three different axis that can categorize a Work Item:
- The Track/Workstream/Activity hierarchy. The hierarchical relationship between these concepts is pretty clear from the MSF documentation. For a global overview you can check out the "MSF for CMMI Responsibility Matrix" created by Martin Danner.
- Areas. They represent segments of the project: components, subsystems, groups of features, etc. The most important thing about Areas is that it is a non-temporal concept in contrast with Track/Workstream/Activity and Iterations, where there is always a positioning within time. Areas refer to the project content. They allow us to split this content in meaningful groups.
- Iterations. Where do Iterations fit? Are they defined within a Tracks/Workstreams or are do they cut through them? My understanding is that they are independent from the Tracks/Workstreams/Activities and Areas (that is why I say there are 3 axis). As explained in , iterations are time cycles. They work done during an iteration can impact one or more areas and can involve performing one or more Worksterams and Activities. From the MSF for CMMI track picture below, we can deduce that iterations can cover one or more tracks
Why don't Work Items have a field to indicate Track, Workstream and/or Activity?
An important difference between Track/Workstream/Activity and Areas & Iteraitons is that the former are defined at the process template level while the latter are defined at the Team Project level.
The amount, names and definitions of workstreams and activities are defined by MSF for CMMI or MSF for Agile (or any other process template). It seem to me that they actually define a "methodology". They give step-by-step guidelines on how to go about software development. For example, the "Fix a Bug" workstream includes the following activities while in the Build track.
- Reproduce the Bug
- Locate Cause of Bug
- Reassign Bug
- Decide on Strategy for a Fix
- Code Fix
These are clearly general to any project using MSF for CMMI as template.
(Note: I always mention the Track/Workstream/Activity hierarchy but, to be exact, Workstreams cut across Tracks -- for instance, check the "Fix a Bug" workstream mentioned above, which spread over the Plan and Build tracks.)
Areas and Iterations, on the other hand, depend on the specific team project. They are not general, abstract concept. They are directly linked to the day-to-day work done on a project. Therefore they have to be present as work item fields since they allow us to classify them. Workstreams and Activiites are not work item fields because they do not classify the item. Work items allow us to track Workstreams and Activities, that is, to monitor how we are following the chosen process.
After explaining all of this, my boss still insisted in having a Track/Workstream/Activity field in each work item ... (which I proceeded to add by hardcoding the possible values). So much for hard work and analysis :)
I am wondering how people are going to use these fields - if they use them at all. I'll post any interesting findings :)