Team Foundation Server : Check-in Policies to ensure traceability
One of the things many teams thrive to achieve is 100% traceable code against Business Requirement Document (BRD) or Requirement Matrix. With evolution of ALM tools, it has become very easy to create traceability matrices and to be able to view history of code and the rational behind design decisions that were taken at the time of its design and development.
So to ensure that you have 100% traceability (even with the most junior member working in your team), you need a set of tools that restrict checking in code without a a work item (or a requirement). But this also means that all your team members and stakeholders have to manage the project (SPRINT, iterations, burn-out etc.) and deliverables using the same tool.
Assuming that everyone is using same tool and you have created the product backlog, you have to create work items (or requirements, for detailed information read my article on Product Backlog and WorkItems) and assign them to your team members with enough information such as
- Expected Effort
- Priority
- SPRINT / Iteration
- Description (and if possible, storyboard)
- Test Cases (in many cases)
- Sub-tasks (if the work can be divided into small tasks)
It is not necessary to define all the above attributes, but you can agree-upon, within your team, a set of standard attributes for each work-item (or requirement).
Now, the developers can check-in their code without actually associating this with any work-item. This means even if you have created work-items (and possibly, sub-tasks or linked work-items) there is no link between a work-item and the checked-in code. So we need some restriction on the action of the developer. He/She should not be able to check-in without associate it with a work-item. This is easily achievable in TFS
Whether you are using Visual Studio or Eclipse plugin, you can go to Team Explorer and click on Source Control.
You are then prompted with a dialog where you can choose Check-in policies. You can click on Add to view the possible Check-in policies. Please note that this is feature is only available to users marked as Project Administrator and this has to be done once-per-project.
As a practice, I prefer to have a minimum two policies for all my collections
- Changeset Comments Policy – Do not allow the developer to check-in without putting comments
- Work Items – Do not allow the developer to check-in without associating a work-item
If you are keen on allowing check-in on gated builds (read: continuous integration), you can add “Builds” policy. Click on OK. Let’s say you want something more than a comment to be added as well for each check-in. For example, design document name. You can go to Source Control dialog, click on ‘Check-in Notes’ and add fields in it and mark it as Required.
If any developer forgets to associate a work-item or to put a comment before checking in the code, he/she will be prompted with
You can now go to the work-item > History tab to view the code history as shown below
This ensures that you have 100% traceability of code with your requirements. If your Business Analyst or Requirement Gathering personnel uses TFS Web Portal to key-in the requirements (read: create work-items) and the Team Lead is engaged in assigning tasks to the team, you can be rest assured that not a single requirement will be missed out and all stakeholders can get a graphical view of your iterations.
