Add a hook to your version-management system to require that commits have an associated issue. This will make it harder to forget to add the issue number. The hook can be as simple as checking for a string that matches the issue number pattern, or as complex as checking for an actual issue. Simple is adequate.
Have a fallback issue number for developers to use in case a commit does not fit a story cleanly. This will allow work to continue while providing data to analyze about cases where team members wanted to not enter an issue.
Conclusion
Traceability can be onerous, especially when tracking requires extra work on the part of developers. It's possible to automate many things, but it's far easier to tell the system what you are doing. Doing so can help you understand if you are working on the right thing. You can use tools to minimize overhead, but the most important thing is to establish the habit of associating work with something—the plan.
Knowing why you are making a code change, and sharing that knowledge with the team, can only be a good thing. The enhanced focus on sprint goals is the main benefit. Traceability for retrospection is a happy side effect.
References
- A Pattern Language of Competitive Development, Part 1
- JIRA
- Mylyn
- Cohn, Mike, User Stories Applied : For Agile Software Development (Boston, MA, Addison-Wesley, 2004).






