Tuesday, August 10, 2010

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.

No comments: