You should use ticket trackers to track tasks, bugs, or issues. While some ticket trackers can also help with resource scheduling or tracking work items against milestones, they are not inherently good at mapping agile user stories. There are ways to coerce user stories into tickets, of course, but you should carefully evaluate whether you are letting your tools drive your process, rather than allowing your process to guide your selection of appropriate tools.
Informally, user stories are full-stack slices of functionality that contain context and a point of view. They are also essentially conversational placeholders, intended to guide programmer/stakeholder interactions rather than act as fixed specifications.
Informally, tickets generally serve one of two purposes:
- Task tracking.
- Issue tracking.
While tickets often contain background details sufficient to reproduce a bug or describe the steps needed to complete a task, even the most complete ticket is rarely a substitute for a properly-written user story. They are not less useful; they simply serve a different purpose.
Mapping Stories to Tickets
This is a case of letting your tool drive your process. It is a clear violation of the principle that tools should fit your process, rather than having your process dictated by a tool.
Nevertheless, there are some things you can do within your current system. Some examples include:
Making each ticket a user story, and then listing concrete deliverables as tasks within the ticket.
In this case, "implementing a badge system" would be the subject of your ticket, while concrete tasks attached to the ticket might include designing a data model and implementing the database schema.
Treat your ticket tracker as a work-in-progress tracker instead of a scheduling tool.
In this case, you would use your ticket tracker as more of a Sprint Backlog than a Product Backlog. Issues would be transferred to the ticketing system when they become work items, rather than using the ticketing system itself as a project planning tool.
Treat user stories as milestones, and tasks as tickets linked to a milestone.
In this scenario, your completed badge system is a specific project milestone, and your badge-related tasks are all separate tickets related to that milestone. In fact, you may need to decompose further, making design and implementation of your data model separate milestones on the critical path to the "badges completed" milestone. Of course, each of those smaller milestones would have detailed tasks of their own.
On the downside, these sorts of mappings can lead to bad metrics or additional project management overhead. The first example may lead to situations where teams might say "81% of the stories are 63% done." The second requires a lot of work breakdown analysis in order to determine what specific task each ticket should address, how to link it to other tickets, and how to prioritize each of the tickets.
There are certainly other ways to use a ticketing system, largely limited by your imagination. However, there is no intrinsic 1-to-1 mapping of user stories and tickets; they are fundamentally different tools with different use cases, and you should carefully evaluate whether ticket tracking is the right tool for the job within your organizational process.