ALM Practices Part 10: Work Item Tracking

What is it?

Using Team Foundation Server’s User Story, Task and Bug work item types as the central unit of work for all the activities done within a project.

Why would you do it?

• Because it adds traceability between the functional requirements and the way these requirements have been realized on a technical level.
• Because it introduces a common view of the project between developers and the business people.
• Because it allows you to keep track of why certain code changes were made.
• Because it creates an automatic link between the work items representing functional changes, bug fixes and other code changes and the automatic builds.
• Because it reduces the chance of ending up with loose ends.

What’s the usual thing to do?

• Track each and every activity that needs to be done in a project as a work item.
• Use that work item as a central placeholder for all related communication, code changes, discussions, etc.

How do you do that?

• Register all functional and non-functional requirements as User Story work items and all bugs as Bug work items.
• Also include non-coding related activities such as deployment activities, writing documentation, assisting the marketing department and such. This improves the transparency of the work that is done in a project.
• Break these down into one or more linked Task work items and use these for each and every source control check-in.
• If you are faced with a research task which is difficult to estimate, consider using a Spike with a time-boxed amount of work.
• Never check-in anything without associating it with a task.
• Never check-in anything without providing a clear description describing the set of changes (as Check-In Comments).
• Use Check-In Policies to require developers to provide the comment and the associated work item(s).
• Rigorously file all loose ends and ‘things to do at some time’ as a Task, preferably linked to the associated Bug or User Story.
• Consider adding a custom Storyotype field to the User Story work item type to differentiate between functional and non-functional requirements and to assist in scoping the User Stories.