How to map user stories into tickets?

Question

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.

Answer 1

TL;DR

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.

User Stories

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.

Tickets

Informally, tickets generally serve one of two purposes:

1. Task tracking.
2. 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:

1. 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.

2. 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.

3. 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.

Answer 2

I don't think you can split stories up the way!

The normally accepted best practice for splitting up stories is always vertical - one mini-feature at a time, not a layer at a time.

Doing so should make it simpler to keep the connection, I think you are losing it by splitting in horizontal blocks of work which have no business value taken by themselves.

As a side note, I found that using an issue system has a big drawback: they don't generally have a notion of time. For example, try to build a burndown chart... it's very difficult.

Answer 3

We're transitioning from TFS to Redmine nowadays, and we decided to follow the Scrum way of workflow parsing. We are used to MS Scrum templates and they reflect the Scrum methodology very succesfully. Here is how we are going to do it:

We are planning to use two main workflows to adapt Redmine's workflow logic to the Scrum methodology. One of them will use two trackers called PBI and SBI. (Product Backlog Items and Sprint Backlog Items) They will be used mainly for the Stakeholders, Product Owners etc. Of course the Team will be responsible of them, too but their main responsibility will be the Work Items. Completing the Work Items will cause the completion of the related SBI. PBIs will be converted into SBIs throughout the whole product cycle (sprints) and declined or refused PBIs will be leftovers which can be analyzed after the product finalization.

The second main workflow is for the Work Items. We won't create a new tracker for those. Any Work Item planned by the Team during the Sprint Planning meeting will be created with the default 'Task' tracker. The 'Bug' tracker will be treated as Work Items, too. We aren't going to use the default 'Feature' and 'Suggestion' trackers because they'll be represented by the PBI and SBI trackers.

The two main problems here are that it needs a manual controlling mechanism to reflect the "Work Item - SBI" relations, and a manual process to change the related statuses of those two trackers. The Scrum Master needs to change the SBI statuses regarding to the related Work Item statuses and vice versa. The Work Items have to be related manually to the SBIs. This part is the only weakness in our plan. I'm trying to find a way to do that automatically. This question is about this problem: https://stackoverflow.com/questions/23114198