Team Foundation Server 2008 allows that every check-in is associated with a work item, but what do you do if you are developing some features which span several Team Projects?
For example, you’re developing a specific product for a client and that product has its own Team Project, but is also using some of your other components or tools which are maintained independently in another Team Project.
Where do you create work items for requirements which involve a change in both projects?
- Separated, every work item in its own Team Projects
- All work items in clients Team Project, regardless of associated source code
The latter seems easier to maintain and control, but it involves associating check-ins from one Team Project to work items in another.
For a start I would say that having each check-in associated with a work item is good practice and more important that where exactly that work item lives.
From the TFS point of view it is really irrelevant whether the work item is in the same project or another – where it makes a real difference is the reporting side.
Therefore one way of looking at this is to look at reporting. For instance
Another way of looking at it is for historical reasons – if you want to be able to go back and see what was changed in a particular tool/component it is easier to see the work items also within the project.
Probably there is a way to sensibly split the work items and create the work items for the components in the component project and work items for the projects (if they relate to using the component) in the main project. You could always link the two work items together.