We've been trying this process lately on my current project and I'm personally not a fan of it.  There are a lot of times it's relevant and nice to have but I think putting in a guideline for it tends to make people see this as a rule and for me personally, I really don't want this to become anything like a requirement.  I've seen a few things come out of this that I'm not a fan of.

* Any commit with a story URL is questioned.  There are some times you don't have a story associated with work, it's just a cleanup or refactoring.
* Having the story URL attached gives the person submitting the story the ability to say "Look at the story" instead of actually explaining what the change does. I'm even less of a fan of that. The person who worked the story has the best knowledge of that story and should be available to explain it.
* I've yet to actually have an instance of this being helpful.

I realize that part of my objections are based solely on my experiences with this current project but I have nothing else to go off of. Unfortunately once things are put in the guide they become canon and this is something I really don't want to support currently.

One nice benefit of this that I do like is that on pull requests that may need a bit of information, having the URL from the commit message bubble up into the description is quite nice. I would not be opposed to "recommending" that when applicable we put the story URL in description, but still not something I want to see become a requirement.

All that being said, if others think this is a great idea I will happily follow the rules :smile:, just hasn't been something I've enjoyed at all on this project. It feels too much like bookkeeping for the same of bookkeeping, almost equivalent to having to track what you do every hour, just unnecessary.

Sorry for the long response but I wanted to make sure I expressed all my issues.