Ist die Verfolgung der abrechenbaren Zeit für Scrum-Zeremonien in JIRA ein Anti-Pattern?

Wir verwenden Story Points, um die Komplexität von User Stories zu schätzen, aber wir stellen dem Kunden Stunden in Rechnung. Dies ist das allererste Scrum-Projekt in unserem Unternehmen, und wir haben nicht genügend Daten, um einen Preis pro Sprint zu berechnen.

Ich wurde von den Führungskräften gebeten, alle Scrum-Zeremonien in JIRA zu verfolgen. In meiner ganzen Scrum-Karriere ist mir so etwas noch nie begegnet. Mein "Gefahrenalarm" klingelt laut. Ich kann ihren Punkt verstehen. Da das Projekt in Scrum läuft, sollten wir dem Kunden auch die „Scrum-Zeit“ auf die gleiche Weise in Rechnung stellen, wie wir die Projektmanagerzeit in Wasserfallprojekten in Rechnung stellen.

Ich weiß, dass wir Sprints "normalerweise" mit den Zeremonien abrechnen sollten, aber so weit sind wir noch nicht. Ich versuche, aufgeschlossen zu sein, ich habe im Scrum Guide nichts gegen das Verfolgen der Scrum-Zeit gefunden (z. B. Framework-Overhead).

Ich kann in jedem Sprint eine JIRA-Aufgabe erstellen, in der wir die Uhrzeit für Scrum-Events verwenden. Ist diese Technik strikt gegen Scrum?

Im Allgemeinen sollte die Budgetierung/Abrechnung auf den durchschnittlichen Kosten Ihrer Sprints basieren (z. B. 7 Personen bei 40 Stunden pro Woche), anstatt zu versuchen, detaillierter zu werden. Scrum-Ereignisse sind Framework-Overhead, und ihre Abrechnung als separate Einzelposten wird niemandem helfen, die Ergebnisse zu messen .
Ich werde auch hinzufügen, dass dies ein Projektgeruch ist, da dies impliziert, dass das Management versuchen wird, „Overhead“ zu quetschen, um auf Kosten von wichtigen Inspektions- und Anpassungsereignissen eine pyrrhusartige Kosteneffizienz zu erzielen. Tu das nicht!
Wie wird abgerechnet? Stellen Sie nur „4 Stunden Projekt X“ in Rechnung oder müssen Sie „4 Stunden Projekt X, Ticket 123“ abrechnen? Wie werden die Stunden berechnet, versuchen sie, Stunden aus Jira herauszuziehen oder füllt jeder einen Stundenzettel aus?

Antworten (6)

Die direkte Antwort auf Ihre Frage lautet, dass die Art und Weise, wie Sie Ihre Zeit dem Kunden in Rechnung stellen, in Scrum nicht angesprochen wird. Daher gibt es kein Abrechnungsmodell, das ausdrücklich Anti-Scrum ist. Wenn das Hinzufügen eines Ortes auf dem Board, an dem Sie die Zeit verfolgen, für Ihr Team die einfachste Möglichkeit ist, sie im Auge zu behalten, zögern Sie nicht.

Nun gibt es Abrechnungsmodelle, die Anti-Scrum-Verhalten anregen können. Wenn Sie beispielsweise jede Person im Scrum-Event nach Viertelstunden abrechnen, kann der Kunde Sie unter Druck setzen, Personen aus dem Meeting herauszulassen, die einbezogen werden sollten. Das würde direkt gegen Scrum gehen, aber die Abrechnung selbst ist in Ordnung.

Scrum funktioniert am besten, wenn Sie über eine gute Produktverantwortung, Iterationen mit fester Länge und ein stabiles Team verfügen. Wenn der Rückstand vom Kunden bestimmt wird und das Team stabil ist (mit Ausnahme von Urlaub und unerwarteten Abwesenheiten), würde ich erwarten, dass die Kosten pro Iteration behoben werden. Wenn Sie also die Kosten pro Artikel aufteilen müssen, ist es sicherlich der richtige Weg, die Iterationskosten (einschließlich Ereignisse) durch den relativen Aufwand zu teilen, der für jede Geschichte aufgewendet wird.

Für einen zweiwöchigen Sprint würde ich davon ausgehen, dass Scrum-Events nicht mehr als etwa 10 % des Aufwands für das Team ausmachen. Aber der größte Teil davon ist die Zeit, die mit der PO (Planung, Überprüfung und Verfeinerung) verbracht wird. Wenn die PO also der Kunde ist, sollten die Kosten der Veranstaltungen ohnehin sehr sichtbar und unter ihrer Kontrolle sein.

Viele Scrum-Teams zeichnen die für jedes Sprint-Backlog-Element geleisteten Stunden auf, obwohl dies häufig hauptsächlich zu ihrem eigenen Vorteil geschieht, z. B. um die Arbeit zu optimieren und die Auswirkungen von Blockierungen zu verstehen. Wenn es für den Kunden wichtig ist, schlage ich vor, dass Sie Ereignisse im Sprint-Backlog (z. B. Aufgaben) aufzeichnen und gleichzeitig den Produkt-Backlog weiterhin anhand von Punkten schätzen. Ich sehe da kein großes Problem.

10% Overhead finde ich viel zu wenig. Ich stelle in einem verwandten Beitrag eine Aufschlüsselung zur Verfügung , die einen durchschnittlichen Overhead von 30 % zeigt (höher bei kürzeren Sprints, niedriger bei längeren Sprints). Scrum-Implementierungen können und werden variieren, daher wird auch Ihr tatsächlicher Overhead variieren.
@ToddA.Jacobs, vielleicht sind 10-15 % angemessen, aber Sie beziehen 1 Stunde pro Tag mit SM-bezogenen Artikeln ein. Das scheint ein wenig hoch (Burn-Charts? Das Erstellen dieser dauert praktisch null Zeit, wenn Sie das richtige Tool haben, und ich mache es nur einmal pro Sprint), aber ich sehe nicht, wie Sie Kommunikationen und das Auflösen von Hindernissen den Ereignissen oder dem gerecht zuordnen können Rahmen. Diese Dinge sollten ähnlich oder gleich sein, unabhängig davon, ob Sie Scrum verwenden.

TL;DR

Scrum basiert auf einer empirischen Steuerungsmethodik. Auch wenn dies nicht direkt im Scrum-Leitfaden angegeben ist, postuliert er im Wesentlichen eine ungefähr konstante Ausführungsrate für jeden Sprint, was eine vorhersagbare Budgetierung ermöglicht, indem die Anzahl der Sprints geschätzt wird , die wahrscheinlich benötigt werden, um ein „gut genug“-Ziel zu erreichen. ( Weitere Informationen hierzu finden Sie unter Agile Release-Planung .)

Im Allgemeinen sollte die Budgetierung/Abrechnung auf den durchschnittlichen Kosten Ihrer Sprints basieren (z. B. 7 Personen bei 40 Stunden pro Woche), anstatt zu versuchen, detaillierter zu werden. Scrum-Ereignisse sind Framework-Overhead, und die Abrechnung als separate Einzelposten wird niemandem helfen, die Ergebnisse zu messen.

Auch wenn Ihr Anwendungsfall anders sein mag, der Versuch, den Framework- Prozess getrennt von den praktischen Entwicklungsaktivitäten abzurechnen, ist ein Projektgeruch. Dies deutet stark darauf hin, dass das Management keinen Wert in der Planung, Kommunikation oder Koordination sieht und wahrscheinlich versuchen wird, den „Overhead“ zu drücken, um Pyrrhus-Kosteneffizienzen auf Kosten wesentlicher Inspektions- und Anpassungsereignisse zu erzielen. Wenn sie das tun, werden sie wahrscheinlich den Prozess unterbrechen und beide Hälften behalten.

Ein tieferer Tauchgang

Ich wurde von Führungskräften gebeten, auch alle Scrum-Zeremonien in JIRA zu verfolgen.

Sie definieren Ihre Rolle nicht in Ihrem ursprünglichen Beitrag, aber ich gehe von „Scrum Master“ aus. Unabhängig davon ist dies ein lehrreicher Moment für Sie, das Scrum-Team und den Rest der Organisation. Vielleicht sogar der Kunde auch!

Es ist eine gute Wette, dass dies ein X/Y-Problem ist . Eine gute Möglichkeit, das eigentlich zugrunde liegende Problem aufzudecken, ist die Technik der fünf Warum . Betrachten Sie diese beispielhafte Fragenkette:

  1. Warum möchten Sie, dass die für Scrum-Ereignisse aufgewendete Zeit in JIRA erfasst wird?
  2. Warum ist es sinnvoll, die Zeit, die für wesentliche Rahmenwerkaktivitäten aufgewendet wird, getrennt von anderen Aktivitäten zu verfolgen?
  3. Warum sollten das Management oder der Kunde zwischen verschiedenen Arten von Aktivitäten unterscheiden, die für unsere internen Prozesse erforderlich sind?
  4. Warum sollten diese Informationen den Entwicklungs- oder Bereitstellungsprozess verbessern?
  5. Warum sollten diese Informationen ergebnisbasierte KPIs und Metriken einspeisen?

Diese Kette (oder eine ziemlich ähnliche, die besser zu Ihrem Anwendungsfall passt und sich dynamisch an die bereitgestellten Antworten anpasst) wird wahrscheinlich zu einer oder mehreren Ursachenaussagen führen, die Folgendes angeben:

  • Fehlendes Vertrauen in das Team oder den agilen Entwicklungsprozess.
  • Magisches Denken, wie der Irrtum der 100-prozentigen Auslastung .
  • Organisatorisches Versäumnis, sich auf die Werte, Prinzipien und Ziele eines inkrementellen oder iterativen Prozesses einzulassen.
  • Der Wunsch, Buzzword Management™ zu verwenden, um Agilität zu behaupten, ohne sich tatsächlich auf das Framework festzulegen.
  • Ein Führungsstil, der nach einem „Schneller gehen“-Knopf sucht, ohne bereit zu sein, die Kosten für den Prozess- und Kulturwandel zu tragen.

Scrum ist kein magischer Schneller-Knopf. Es ist ein Framework, das empirische Planung verwendet, um einen nachhaltigen Prozess mit vorhersehbarer Kadenz zu schaffen. Es kann die Effizienz steigern, aber in diesem Fall bedeutet Effizienz, „mehr von den richtigen Dingen zu tun und mehr von dem zu bauen, was wichtig ist“, anstatt einfach das Tempo zu beschleunigen, indem man all diesen lästigen Projektaufwand abschafft.

Entdecken Sie die wahre Absicht dieses Managementziels. Wenn es sinnvoll ist, beziehen Sie das Team ein, um zu bestimmen, wie es am besten nachverfolgt werden kann. Wenn es sich um eine vergebliche Übung handelt, informieren Sie das Managementteam (und möglicherweise den Kunden) darüber, wie Scrum wirklich funktioniert und welche Hebel der empirische Kontrollprozess ihnen bietet , um Kosten, Zeitplan, Qualität und Änderungen zu verwalten.

Ich bin verwirrt. Sie sagen, Sie stellen dem Kunden Stunden in Rechnung. Darunter verstehe ich "Arbeitsstunden".

Scrum-Zeremonien sind Teil der Teamarbeit . Wenn Sie beispielsweise ein tägliches Standup abhalten, tun Sie dies, damit das Team seine Arbeit im Sprint koordinieren kann. Sie sprechen dort über die Arbeit, nicht über das Wetter oder wie Ihre Katze ihren Kopf in ein Glas steckte und es so lustig war ... Warum diese Zeit separat verfolgen? Für welchen Zweck? Das ist das Wichtigste, um herauszufinden: "warum"?

In traditionelleren Projekten verfolgen Sie die Zeit für verschiedene Aufgaben, um die geschätzte Zeit mit der tatsächlich verbrauchten Zeit zu vergleichen und damit den Projektfortschritt zu verfolgen. Sind wir auf Kurs? Sind wir im Rückstand? usw. Sie verfolgen auch den Aufwand für das Projektmanagement separat, wie Besprechungen, Erstellung von Berichten, Verwaltungsaufgaben usw. Dies ist nützlich, um zu sehen, wie viel Aufwand für die Verwaltung des Projekts erforderlich ist (dh die Dinge, die zur Organisation der Arbeit erforderlich sind). War das ein einfaches Projekt? War es schwierig zu handhaben? War es ein normales Projekt? Können wir in Zukunft den gleichen Prozentsatz an Verwaltungsgemeinkosten für ähnliche Projekte erwarten?

Wenn das der Grund ist, die Zeit zu messen, die in Scrum-Zeremonien verbracht wird (dh um zu sehen, wie viel es kostet, die Arbeit zu organisieren, die an sich Arbeit ist), dann könnte es einen Sinn machen, auch wenn es nur wegen dieser alten Gewohnheit ist Methodik und finden es schwer zu schütteln.

Denken Sie jedoch daran, dass das Maß für den Fortschritt in Scrum die funktionierende Software ist , wobei die wertvollste Arbeit zuerst kommt. Es geht nicht darum, wie viele Stunden Sie gearbeitet haben, im Vergleich dazu, wie viel Sie noch übrig haben oder geschätzt haben . Auch in Scrum sind die Zeremonien zeitgesteuert . Es gibt eine Obergrenze dafür, wie viel Zeit Sie in der sogenannten „Scrum-Zeit“ verbrauchen. Es ist sinnvoll, dies zu messen und zu sehen, ob Sie über die Obergrenze hinausgehen, in diesem Fall könnte dies ein Zeichen dafür sein, dass etwas passiert, etwas repariert oder verbessert werden muss, aber ich sehe immer noch nicht, wie diese „Scrum-Zeit „Passt zu den Stunden, die Sie abrechnen.

Wie Sie Ihre Arbeit abrechnen, ist nicht wirklich eine Technik für oder gegen Scrum. Aber der Grund für das „Warum“ Sie es auf die eine oder andere Weise tun könnten, könnte sein . Wenn Sie beispielsweise die „Scrum-Zeit“ separat verfolgen und jemandem die Zahl, die Sie zurückerhalten, nicht gefällt, könnte er versucht sein, sie zu reduzieren. Warum so viele tägliche Meetings? Haben Sie nur eine pro Woche, am Montag. Retrospektiven dauern zu lange? Mach sie nicht mehr. usw. Wenn dies Ihr erstes Scrum-Projekt ist und Sie nicht wirklich wissen, was Sie tun, werden Sie am Ende mehr Probleme haben, als dem Kunden Rechnungen zu stellen.

Also finde heraus, warum!

Es ist eine schlechte Praxis, weil Scrum keine Zeremonien hat. Scrum hat Events und sie dienen der Überprüfung und Anpassung. Die Planung der Arbeit und die Überwachung des Fortschritts ist kein Overhead, sondern ein integraler Bestandteil des Lieferprozesses. Dies wird im Scrum Guide deutlich.

Aus Kundensicht ist die Zeiterfassung interessant, weil sie nicht für Team-Lunch, wöchentliche QS-Meetings, Feuerwehrübungen, Sicherheitsschulungen usw. bezahlen möchten, aber es macht wenig Sinn, die Zeit von Scrum-Events separat zu messen. Und es ist sicherlich nicht im Einklang mit dem agilen Manifest, da die Vertragsverhandlung wichtiger zu sein scheint als die Zusammenarbeit mit dem Kunden. Aber es ist viel schwieriger, Ihren Kunden agil zu machen, als es selbst zu tun.

Auf der anderen Seite ist kein Zeiterfassungssystem perfekt, und solange Abrechnungs- und Budgetierungsziele angemessen unterstützt werden, ist es das Problem von jemand anderem. Die Befugnisse des Scrum Masters erstrecken sich eindeutig nicht auf Finanzen und rechtliche Angelegenheiten.

Viele Scrum-Teams zeichnen die für jedes Sprint-Backlog-Element geleisteten Stunden auf, obwohl dies häufig hauptsächlich zu ihrem eigenen Vorteil geschieht, z. B. um die Arbeit zu optimieren und die Auswirkungen von Blockierungen zu verstehen. Wenn es für den Kunden wichtig ist, schlage ich vor, dass Sie Ereignisse im Sprint-Backlog (z. B. Aufgaben) aufzeichnen und gleichzeitig den Produkt-Backlog weiterhin anhand von Punkten schätzen. Ich sehe da kein großes Problem.

Zeiterfassung über (Schätz-)Zeit ... wann soll dieses Team arbeiten? Ich persönlich sehe darin ein großes Problem. Als Berater, Scrum Master oder Manager können Sie es kaufen, weil Sie Ihre persönliche Zeit nicht verschwenden, aber das Team wird sich nicht darüber freuen.


Zur Ausgangsfrage. Aus finanzieller Sicht ist es absolut sinnvoll, die vollen Kosten zu berechnen, einschließlich Verwaltungs- und Prozessgemeinkosten wie Scrum-Zeremonien. Jemand sollte ihnen ein Gehalt zahlen.

Aus operativer Sicht sehen Tracking-Zeremonien wie ein zusätzlicher Overhead aus, der keinen Mehrwert bringt und die Teammoral verschlechtert, wie wir in Ihrem Beitrag sehen können. Das Unternehmen „bezahlt“ bereits den Overhead erster Ordnung von Scrum und dann eine weitere Runde Overhead zweiter Ordnung, um ihn zu verfolgen und schließlich an den Kunden zu übertragen :)

Während es eine Reihe von Gründen gibt, warum es eine gute oder schlechte Idee ist und wie detailliert Sie vorgehen möchten, gibt es einen Kompromiss – eine Jira-App für die automatisierte Zeiterfassung , die keine manuelle Protokollierung erfordert und ohne „Overheads“ umgehen kann Eintrittskarten. Sie müssen jedoch etwas mehr über Kanban lernen .