Work Item Association Policy FAQ
1. What is the main purpose in enforcing this policy?

The main reason we are enabling this check-in policy is to encourage contributors to use the TFS system as it was intended and further customized. Work item tracking is a major component of TFS and we need additional baked-in, systematic processes to standardize our use of it across the teams. These “guard rails” will also enable us to get better reporting out of TFS for mid and upper level management.

2. Why do I need to associate my check-ins with a task and not a requirement or bug work item type?

A task communicates the need to do some work. Each team member can define tasks to represent the work they must accomplish. For example, a developer can define development tasks to implement requirements. A tester can define test tasks to assign herself the job of writing and running test cases. Also, a team member can define a task to represent generic work for the project. Enforcing the association between a check-in (changeset) and a task encourages contributors to enter their work into the work item tracking system as opposed to capturing this information on paper or some other form outside the system. By creating relationships between requirements or bugs and tasks, you can plan projects more effectively, track dependencies more accurately, view hierarchical relationships more clearly, and find relevant information more quickly.

References:
Task - http://msdn.microsoft.com/en-us/library/ee332492
Requirement - http://msdn.microsoft.com/en-us/library/ee332491
Bug - http://msdn.microsoft.com/en-us/library/ee332480

3. Why can’t I associate my check-ins with multiple tasks?

“Do one commit per small-grained, consistent task. Strive to have each commit of code reflect one task. When in doubt, err on the side of more check-ins because it is easier to roll back changes and see the effects of integration with other people’s work.” (Berczuk p113-p114) Enforcing that check-ins be associated with a single task encourages contributors to complete discrete pieces of work and commit them into source control as a single atomic transaction. This allows for: better traceability between work item tracking and source control, the ability to perform changeset rollbacks, and cherry pick merging.

References:
Berczuk, Stephen P., and Brad Appleton. Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Boston ; Munich [u.a.: Addison-Wesley, 2006. Print.

4. Why do I need to associate my check-in with a task that’s in the “in progress” state and not just use the “active” state?

The “in progress” state communicates that work is currently being performed against a task while the “active” state signifies that the work is approved and ready to be performed. Each contributor’s “in progress queue” should accurately represent the tasks they are currently working so that anyone involved in the team is aware. An added benefit to using this methodology is that each contributor can limit the work item query they use for associating check-ins to “My Tasks In Progress”. (I see a lot of people scrolling through hundreds of tasks each time they check-in.) Task reactivations should also be correctly represented in the system, so check-ins should not be associated with tasks in a resolved or closed state.

5. Why do I need to associate my check-in with a task that’s assigned to me?

Tasks are not decomposed granularly enough if you are sharing tasks with a member of your team. Coarse-grained tasks are not desirable for traceability purposes. Each member of the team contributes to the product as a whole and these components should be appropriately represented in the work item tracking system. The agreement on who is doing what is quickly and easily entered by creating individual tasks.

Reference:
http://msdn.microsoft.com/en-us/library/ms181344.aspx

6. What’s to stop me from just associating a check-in with a generic task for all the work I do?

At this point there is nothing to stop such an egregious act from occurring. Unfortunately, there are many check-ins associated with a “do some work” task that does not spell out what work is actually being performed. This is poor form on the part of the contributor and impacts the quality of the product that is being delivered. A team’s work in progress report will expose these poor practices.

Last edited Jul 3, 2012 at 7:09 PM by jasoncamp, version 1

Comments

No comments yet.