Ticket Prioritäten und Reaktionszeiten | Kussin

Ticket Prioritäten und Reaktionszeiten


Mit klaren Prioritäten und Absprachen schneller Aufgaben umsetzen.

24.02.2022 | Daniel Kussin | Entwicklung

Jedes Projekt besteht aus einer Vielzahl an Aufgaben, Optimierungen, Features und leider auch Fehlern, und für jeden Projektbeteiligten sind seine persönlichen Anliegen immer am wichtigsten, aber wie organisiert man die vielen Tickets richtig, so dass der Fortschritt am größten ist?

Verbindliche Absprachen

Die Grundlage für eine effiziente Zusammenarbeit sind zum einen verbindliche Absprachen des Projektteams und eine klar definierte Prioritätenskala.

Zu den verbindlichen Absprachen gehört, dass das Projektteam genau definiert, wie umfangreich die Umsetzungszeiträume sind (z.B. ein Sprint) und welche Arbeiten dafür eingeplant sind, sowie das geplanten Arbeitsumfänge nicht verändert werden, d.h. keine weiteren Aufgaben hinzukommen, ohne das geplante gestrichen werden.
Es gilt zu beachten, dass die Summe der geplanten Aufwände (z.B. Stunden oder Story Points) nicht die Summe der Arbeitsstunden des Umsetzungszeitraums überschreitet, eher sollte der geplante Aufwand 10-20 Prozent kleiner sein, als Sicherheitspuffer für „Interne Fehler“.

Empfehlung: Ein wöchentliches Planungsmeeting (oder Sprint-Planungsmeeting), sowie regelmäßige 15-Meetings (z.B. wöchentliche Stand-Ups) dienen dazu alle zu informieren und die Prioritäten zu überprüfen.

Prioritätsskala

Die Planung der Umsetzung ergibt sich i.d.R. von selbst vorausgesetzt, alle Tickets wurden geprüft, priorisiert, bewertet und ggf. einem Teil-Projekt (z.B. Epic oder Story) zugeordnet, denn dann übernimmt die Prioritätsskala die Planung.
Die Prioritätsskala definiert eindeutig in welcher Reihenfolge offene Tickets bearbeitet werden und was passiert, wenn ein Show-Stopper (z.B. kritische Sicherheitslücke oder ein Serverausfall) auftritt und die geplante Arbeit nicht fortgesetzt werden kann.

Unsere Prioritätsskala

  1. Hotfix (Kritisch)
  2. Hoch
  3. Normal
  4. Niedrig

Faustregel: Das Tupel „Priorität und Verfügbare Umsetzungszeit“ legen die Reihenfolge der Abarbeitung fest, d.h. das Ticket mit der höchsten Priorität wir als erstes in den nächsten Umsetzungszeitraum eingeplant, wobei unabgeschlossene Tickets immer Vorrang haben.

Aufgaben, Optimierungen, Features und Fehler – kurzum Tickets

Alle Aufgaben – egal welcher Natur – sollten als Tickets angelegt werden und im ersten Schritt geprüft und zwischen Autor:in und Projektmanager:in durchgeplant werden. Bei umfangreichen Aufgaben (z.B. neuen Features), sollte das Ticket in möglichst kleine Unteraufgaben runtergebrochen werden, damit der Arbeitsaufwand möglichst realistisch geplant werden kann.

Empfehlung: Umso klarer ein Ticket formuliert ist, umso einfacher kann das Ticket geplant werden. – Michel Rienäcker von Sellmore hat den passenden Blogbeitrag Das perfekte Support-Ticket dazu geschrieben.

Erst wenn ein Ticket geprüft, priorisiert und vom Entwicklerteam bewertet wurde, kommt kann das Ticket eingeplant werden bzw. erhält den Status PM & Konzeption: Done.

Umgang mit neuen Fehlern am LIVE System

Neue Fehler werden vom Autor:in und Projektmanager:in geprüft und bewertet und nach folgenden Regeln eingeplant:

  1. Priorität: Normal oder Niedrig
    Der Fehler wird im nächsten, zu planenden Umsetzungszeitraum eingeplant (max. 4 Wochen).
  2. Priorität: Hoch
    Das Entwicklerteam wird informiert und plant den Fehler in den aktuellen Umsetzungszeitraum ein (max. 2 Wochen).
    Hinweis: Der Fehler ersetzt automatisch die Tickets mit der niedrigsten Priorität.
  3. Priorität: Hotfix (Kritisch)
    Das Entwicklerteam stoppt die gegenwärtige Umsetzung und behebt den Fehler.
    Hinweis: Der Fehler ersetzt automatisch die Tickets mit der niedrigsten Priorität.

Reaktionszeit: Die Reaktionszeit auf Tickets sollte klar im Projektteam geregelt sein (z.B. bei kritischen Fehlern werktags 2 Stunden und bei allen anderen 48 Stunden). Die Reaktionszeit entspricht der Zeit bis wann erstmals auf ein Ticket reagiert wird, nicht bis wann es gelöst ist.

Zufällig gefundene Fehler

Fehler, die durch Zufall (z.B. bei der Abnahme eines Tickets) gefunden werden, aber nicht im Zusammenhang mit dem umgesetzten Ticket stehen, werden dokumentiert und vorerst mit der Priorität „niedrig“ versehen.

Sollte der Tester die Priorität als „Hoch“ einschätzen, dann sollte das Fehler im nächsten Meeting (z.B. Stand-Up) besprochen werden.
Die Bewertung des Fehlers liegt im Ermessen des Projektmanager:in und kann jederzeit von ihm angepasst werden.

Der sonstige Umgang mit dem Fehler entspricht dem Umgang mit Fehlern am LIVE System.

„Interne Fehler“ – Umsetzung von Tickets

„Fehler“ die im Rahmen einer Umsetzung eines Tickets auftreten, werden nicht als Fehler bewertet, sondern als Änderungen bzw. Anpassung und sind Bestandteil des Tickets.

Die Änderungen werden als Unterticket zum Ticket angelegt und im aktuellen Umsetzungszeitraum umgesetzt.

Empfehlung: Bei der Planung des Umsetzungszeitraums sollten 10-20 Prozent der Zeit als Sicherheitspuffer für „Interne Fehler“ eingeplant werden.

Hinweis: Ein Ticket gilt erst als abgeschlossen, wenn alle Untertickets umgesetzt sind, bis zum Abschluss wird das Ticket immer in den Folgeumsetzungszeitraum übernommen. Sollte das Projektteam gemeinsam entscheiden ein nicht abgeschlossenes Ticket nicht zu übernehmen, dann wird die Priorität auf „Normal“ geändert und erst nach Prioritätsskala wieder neu eingeplant – dieser Schritt sollte immer im Ticket dokumentiert werden.