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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)