Currently in my workplace we use Redmine as our backlog management system. It works pretty well for us, but lately (as the company grew), I've been noticing that our tickets tend to be very long (both in regards of the description text and the implementation effort). For what I understand, I think we're having a confusion between a ticket and a user story.

I'm looking for some documentation to guide me in how to manage the transformation of requirements gathering into actual "work orders" to pass to my team. Thanks!

Currently in my workplace we use Redmine as our backlog management system. It works pretty well for us, but lately (as the company grew), I've been noticing that our tickets tend to be very long (both in regards of the description text and the implementation effort). For what I understand, I think we're having a confusion between a ticket and a user story.

I'm looking for some documentation to guide me in how to manage the transformation of requirements gathering into actual "work orders" to pass to my team. Thanks!

EDIT:

A concrete example for it is this: we're currently working on implementing a badges system for our website. Currently we have one ticket describing the problem as a whole (including bussiness value and such), which I believe is important information, only it's not the best place to have it in (It's not really relevant for the development team at coding time).

I think we should have smaller tickets, like:

1. Design and implement data model
2. Backend implementation
3. Front end implementation

The problem is, if we do that, we kind of loose the connection between each ticket and the bussiness goal we're trying to accomplish.

I hope I've made myself a little clearer. Thanks.