I've been using the same convention for over a decade, and it works with a lot of different agile tools: [<ticket action> TIcket Number] action, in the imperative form (<ticket action> <additional ticket numbers>) If my code isn't descriptive enough or the ticket doesn't cover enough of why this code should be implemented this way, I write a little bit more in the long description, although this is a rarity. Here is an example: [starts API-1234] refactor user widget to show avatar [wont-fix API-4356 blocks API-2543] Adding the avatar here blocks the ability of the user to see the logo (API-2543) I rarely use the long description due to better tooling and code design. If my code is self-documenting and my tooling allows me to see all changes in a commit easily, I should be able to discern the reason for any particular change without much effort, if any.