What Are You Doing?

To associate the backlog item with the change, you need a concise way to identify it. This is easy to do when you use an issue tracking system, which automatically assigns identifiers to backlog items. If you use a paper-based tracking system, you might want to have a mnemonic for each work item. The “Print a Report” index card could have the mnemonic PRINTRPT, or if your project has the codename “ROME” and printing was the third task, you can give it the mnemonic ROME-3.  Any system works, as long as there is a short code that is easy to identify as an issue ID.

Since issue-tracking systems are common, I'll focus on teams that use issue systems that integrate with version-management systems. Issue-tracking systems also can become impediments if used incorrectly (for example, when the tool goal becomes “entering issues” rather than “tracking progress”), so it’s important to evaluate the overhead of your planning process.

Tracking Change

The simplest way of associating commits with work items is to have every commit have a message that identifies which issue the change implements. For example, "TY-157: Added a new API to allow us to implement the tracking feature."  Some tools, such as Mylyn, [2] will even add the issue identifier to your default commit message when you commit changes in your Eclipse IDE—but you still have to tell it what issue you are working on.

Adding the issue identifier to your commit messages consistently gives some advantages:

The issue system is an easy way to give more context to the reason for a change, particularly when you are doing many small commits per change (a practice I recommend).

It's easy for anyone trying to do similar work to figure out what work to do.

It encourages people to stay focused and not get off track on other work. (If accomplishing a task leads to an opportunistic refactoring, for example, say that you are doing the change to support the issue.)