Für das Projektmanagement sowie die Verteilung und Priorisierung von Tickets ist es extrem wichtig, dass bereits aus dem Titel klar hervorgeht, worum es im jeweiligen Ticket geht, was für ein Problem besteht oder was konkret getan werden muss. Es sollte möglich sein, das Ticket bewerten zu können, ohne es öffnen zu müssen, um an fehlende Details zu kommen, die beispielsweise im Beschreibungstext stehen könnten.

Darum sollte der Ticket-Titel immer eine Aufgabe wie beispielsweise "Der Button auf der Startseite ist zu klein" oder "Klickt man auf das Kontaktformular, verschwindet der Anrufen-Button" sein. Weniger optimal sind Titel wie "Bug Startseite" oder "Buttons". In den letzten zwei Beispielen ist absolut nicht ersichtlich, welcher Aufwand hinter dem Ticket steckt, sodass der Projektmanager zunächst das Ticket öffnen und mit einem Mehraufwand den Titel korrigieren muss.

Ebenfalls extrem unvorteilhaft sind Sammeltickets, die mehr als ein Problem enthalten. Oft sind die verschiedenen Probleme auch in ihrer Komplexität unterschiedlich, sodass ein solches Ticket viel zu lange offen bleibt, obwohl beispielsweise nur noch einer der zehn genannten Punkte tatsächlich abgearbeitet werden muss. Allein diese Tatsache führt schon zu einem massiven Verlust von Zeit und Übersicht.

Viel schlimmer ist aber, dass ein Sammelticket nicht mehreren Personen zugewiesen werden kann. Betreffen die beschriebenen Probleme also mehrere Entwickler, wird auch automatisch das zügige Abarbeiten der einzelnen Punkte verhindert, da auch hier erst ein Projektmanager aus allen im Sammelticket genannten Punkten neue Tickets erstellen muss, die letztlich den betroffenen Entwicklern zugewiesen werden können.

Neben einem selbsterklärenden Titel ist es auch sehr wichtig, dass in den Ticket-Details alle Informationen dokumentiert sind, die benötigt werden, um das Problem zu verstehen und zu beheben. Aus Sicht eines Entwicklers kann ein Problem nur behoben werden, wenn die Ursache verstanden oder ein Fehler tatsächlich reproduziert werden kann.

Aus diesem Grund sollte in der Ticket-Beschreibung sehr detailliert erläutert werden, welche Vorgehensweise beispielsweise einen Absturz verursacht hat und welche Schritte dafür nötig waren. Auch ist es sehr wichtig, dass Fehlermeldungen in das Ticket kopiert und Screenshots erstellt werden. Häufig haben Fehler andere Ursachen als vom Kunden vermutet und durch Screenshots oder Videos können wir als Entwickler viel besser nachvollziehen, wie ein Problem wirklich provoziert wurde.

Ein Ticket kann einen Typ haben, der je nach verwendeter Projektmanagement-Software natürlich variieren kann. In JIRA gibt es standardmäßig beispielsweise unter anderem "Bug" (also Fehler), "Task", "Improvement" oder "New Feature". Das Projektmanagement einer Firma, die in der Softwareentwicklung tätig ist, nutzt diese Ticket-Typen häufig, um entsprechende Tickets zu priorisieren oder anders darzustellen.

Hat also beispielsweise ein Ticket, das eigentlich einen Featurewunsch beschreibt den Typ "Bug", wird es zunächst als "Fehler" im System geführt und im Zweifel zu spät oder von den falschen Personen bearbeitet, bis der Fehler korrigiert wird.

Es ist natürlich verständlich, dass aus Sicht eines Kunden jedes Problem oder jeder Wunsch die höchste Priorität hat. Fatal ist aber, wenn beispielsweise jedes Ticket mit der Priorität "Sehr hoch" erstellt wird. Denn letztlich kann eine priorisierte Abarbeitung und insbesondere ein Notfallszenario nur funktionieren, wenn eine Priorisierung möglichst realistisch vorgenommen wird. Haben alle Tickets die höchste Priorität, ist im Endeffekt kein Ticket wichtiger als ein anderes.