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?