TFS Work Item Customization for Deliverable Tracking

Question

I am looking for a bit of guidance on the best practices for using TFS as a work management system in a time-bound implementation project. Let us assume we begin with the Scrum workflow and our project is following a hybrid Scrum/Waterfall model (for a moment, ignore the controversy that statement may create). Assume that you have full rights to customize the TFS project area as you please and that all features in TFS 2015 product suite are available.

The scrum workflow has work items and PBIs and familiar concepts for code deliverable creation and defect management. The first assumption I would like to vet is that these work items are most appropriate for code creation and deployment. This may be a bad assumption given that Task for example is fairly abstract, so please correct me if this is wrong.

Let us then assume that in addition to the software product there are a number of other deliverables which must be produced for the project to be a success, but that these deliverables are not deployable as part of the software:

• Design Documentation
• Standards Documentation
• 'Change Requests'
• Socialized "Key Decisions" which may dictate design patterns and strategies

Each having its own logical set of steps to progress towards its own definition of done (reviews, signoffs etc).

When is it appropriate to put items like this into TFS as a custom work item definition and what are the trade offs? Ordinarily these may be handled as line items in a MS Project plan. Naively, I am interested in putting these into TFS instead of MS Project because then TFS work items can be the single source of truth for deliverable progress, instead of having to keep a project plan in sync with TFS or vice versa.

Can someone with experience customizing TFS weigh in on the pros and cons of using TFS for managing deliverable tracking when the deliverables are not coded deployables, and creating custom work items for those deliverable types?

Answer 1

I wouldn't specialize the customization of TFS to this level. Even the pretty detailed CMMI template doesn't detail out to this level.

You can match any deliverable to a Product Backlog Item in scrum if you have to, or capture the action to update it as a Task under another Product Backlog Item. If a specific document always needs to be created or updated, capture it in the Definition of Done and if needed as a task under each product Backlog Item.

A change request also translated to a Product Backlog Item. Or, if the Product Backlog Item hasn't been actioned upon before, can simply be captured by changing the original item. TFS will track history, so it can be deduced that it had a previous intent before.

Key decisions would be reflected as Acceptance Criteria on the PBI, these need to be taken into account while developing and may later be converted into a task it testcase during actual implementation.

TFS is very bad at tracking reviews and signoffs. It isn't meant for such things. It would require a lot of customization to automatically clear signoffs and reviews when changes occur. A tool like SmartBear Collaborator can add proper review and signoff features if needed.