Are we using TFS 2010 incorrectly? [closed]

Question

Our team is new to TFS2010. Historically, we have used our own Business Requirements Matrix (traceability matrix) Excel spreadsheet. It has typical columns like:

Requirement ID | Project | Rule Group | Business Rule | Type ...etc

Our Business Rule column reads something like the following:

• "The system shall provide a means to allow the actor to search for a Study."
• "The system shall provide a means to allow the actor to search for a Project."
• "The system shall generate a move activity for the inbound package."
• "To Import Barcoded Manifest, the system shall, with each sample placeholder, include a code stating the sample has been created by barcoded manifest."

Due to the rigor of our industry regarding documentation, audits, etc, we opted for MSF for CMMI instead of MSF for Agile as our Process Template choice.

We have had numerous discussions about the best way to go about implementing "the way we work" into the TFS 2010 world. The crux of our problems seem to come down to the following:

• It seems like we should follow the "parent/child" relationship between Requirement -> Task in the Implementation tab. However, this means that we have a task for every Requirement (which seems redundant and overly granular).
• We like to think of a Task as something less granular (i.e. "Develop an Outbound Console screen.")
• We would like for the developer to be able to look at the Tasks assigned to them, and easily see what Requirements (Functional and Non-Functional) are associated with those Tasks.
• Traceability is a high-priority, however, we don't necessarily need it to be extremely granular (down to actual lines of code). As we see it, doing so would make development extremely tedious and counter-productive. We want a sensible balance in this respect.

Is our approach really the round-peg into square-hole that it seems to be? Or, are we just misunderstanding/missing something? We feel like we have a sound understanding of the various Work Item Types.

To add a bit more context, our understanding is that Requirements of type "Feature" are the "parent" of more granular requirements such as Functional, Non-Functional, QoS. We understand that the Requirement type of Scenario is analogous to a Use Case.

So, we believe that TFS 2010 follows this hierarchy:

• Requirement (Feature)
• Requirement (Functional)
• Task

Obviously, the problem for us is that while we want the parent/child relationship between Requirement/Task in some respects...we almost see the need for a Task as the parent of Requirements at the same time.

We believe that we could skip the Implementation tab (and the parent/child relationship it enforces)...and just use the All Links tab. This allows us more flexibility to relate Requirements and Tasks via other Link Types such as "Related" or "Affects/Affected By"...but, the big catch there, is that it breaks the built-in TFS 2010 reporting (especially regarding tracking Requirement progress/hours).

Any insight is appreciated.

Answer 1

It sounds like you need to customize the out of the box process template that comes with TFS.

To be honest I think everyone should customize the templates to make sure they get the tools to fit their process, not change their process to fit the tools.

I'm not sure if you're aware of some of the customization options that are available so I'll just mention some of the ones I've used when customizing TFS for my company.

You can edit any work item type that comes out of the box in the process template. There are lots of customizations you can perform, for example, in my company we only wanted people in the test group to be able to close bugs, so we put that constraint on all transitions to the closed state.

You can add transitions, states, fields, tabs etc. as required.

If you want a new work item you can create a new one from blank or base one on an existing work item type, to create a new one from an existing type, export the work item type, edit the xml to change the name to your new type and then import it.

The concerns you have about relationship between the different work item types should be addressed by creating custom link types and then including them in your new template.

It seems like you have a good sense of the process you want to follow, I think you need to customize TFS to match that process.

The one drawback about performing this much customization is that the standard reports won't provide you with much useful info. This will require your team to write some new reports. You can also do some nice reporting in excel if that would meet your needs.

HTH

Answer 2

I think you going to have to go with a customized approach here. Pick the reports and metrics that are important to you as your requirements for TFS. From there, design the linkage between work items in a way that gets you your reports and metrics. Also, you probably already know this, but the Task WI does have a discipline field that allows it to be used for more than just development. Good luck!

Answer 3

First off, welcome to the world of TFS. :)

There is nothing wrong with how you wish to work. The hierarchy you outlined is fine, and TFS will support any set of Work Item Types (WITs) and relationships (links) you require them to have. The Implementation tab, and all other tabs that show relationships with other WITs are merely filters to the entire list of WITs your type is related to (i.e. the Requirement's Implementation tab shows all work items that are of type Requirement or Task, and have a parent/child relationship).

What follows, is that you should think what artifacts (WITs) your process requires, and how they should work together, and customize your process template to work as you want it to.

This is relatively simple to do, especially when you use the process editor that is part of the Team Foundation Power Tools. If you want to modify the link pages, it is all done in the layout part of the work item type.

Regarding the question of the relationship between requirements and tasks: I always view requirements as the definition of what the user / customer needs. The requirement should be more outward facing, describing the need, the goal and the desired effects (and side effects). The tasks are more inward facing, and should tell the developer how he (or she) should go about achieving the above goals.

With that in mind, I always prefer to have a developer work only on tasks. Moreover tasks should always derive from a requirement (or a bug, or a change request, and so on). A task that doesn't come up as the result of a requirement might indicate that the work is either unnecessary or poorly planned.

Hope this helps, Assaf.