Akzeptanzkriterien und Tasks sind zwei verschiedene Dinge, die häufig als Synonym verstanden werden. Dabei kommt in neuen Scrum Teams die Frage auf, ob "man denn Tasks schreiben müssen, das seien doch gleich die Akzeptanzkriterien". In diesem Artikel schauen wir mal gemeinsam auf diesen Sachverhalt, betrachten was Akzeptanzkriterien wirklich sind und wie du Tasks am besten für dich interpretieren kannst.
Die Bedeutung von Akzeptanzkriterien
Akzeptanzkriterien sind ein "C" der drei "C's" einer jeden User Story. Sie ermöglichen es, dass der Product Owner formulieren kann, ab wann eine Story als "abgenommen" gilt. Er drückt also seine Erwartung an das Product Backlog Items damit aus. Damit das richtig gut funktioniert, sollten Akzeptanzkriterien immer erlebbar sein.
Das ist ein ganz wichtiger Mechanismus, um zu fertiger Arbeit zu kommen. Beispiele können sein:
Manche Akzeptanzkriterien können auch in einer Definition of Done stehen. Was der Unterschied zwischen Akzeptanzkriterien und der Definition of Done ist, habe ich dir in einem extra Artikel beschrieben. Für diese Betrachtung spielt diese Frage eine untergeordnete Rolle.
Muss ich Akzeptanzkriterien haben?
Müssen tut man nichts, allerdings habe ich persönlich noch recht wenig gute Arbeit gesehen, die keine Akzeptanzkriterien und Tasks hatte. Das ist auch logisch, wenn du bedenkst, dass die Akzeptanzkriterien klar vor Augen führen, was von der Arbeit erwartet wird. Und ich stelle da gerne die Gegenfrage: "wieso denkst du, keine Akzeptanzkriterien haben zu müssen?". Schauen wir kurz auf mögliche Antworten, die ich am häufigsten höre:
Die erste Frage ist durchaus valide - meist aber nur ein Argument und keine tatsächliche Wirklichkeit. Wenn wir alle das absolut gleiche Verständnis über die User Story haben und diese auch ohne Akzeptanzkriterien abgenommen wird - dann ist es super. Oft brauchst du aber doch genau ein wenig Dokumentation, um so das "gleiche Verständnis" über viele User Stories über die Sprints zu bekommen. Prüfe deswegen bitte genau, ob das wirklich so ist. Oft unterliegst du da schnell einer falschen Annahme!
Die zweite Frage ist auch etwas merkwürdig in meinen Augen. Man dokumentiert keine seitenweisen Listen oder ähnliches, sondern in der Regel eine Aussage, wie oben formuliert: "Zugriff auf die Benutzerdaten nur nach Anmeldung möglich" ist keine aufwändige Beschreibung.
Wie dich die Akzeptanzkriterien ins Ziel bringen
Für mich gibt es zwei Hauptgründe Akzeptanzkriterien zu verwenden. Diese sind
Akzeptanzkriterien
sparen Zeit
Wenn in einer User Story klar und deutlich beschrieben ist, was erwartet wird, dann verringert das Diskussionen. Es ist klar ersichtlich was erreicht werden soll. Das hilft auch beim Schätzen der Aufgabe.
Akzeptanzkriterien
schärfen Verständnis
Wenn die wichtigsten Erwartungen in den Akzeptanzkriterien stehen, hilft das für das Verständnis. Sind die ergebnisorientiert beschrieben, bekommen alle ein Verständnis, um was es genau geht.
Die Bedeutung von Aufgaben
Aufgaben, die häufig in Scrum nur Tasks genannt werden oder im Jira (unterhalb einer User Story) auch Subtasks, beschreiben Aktivitäten, die vom Team durchgeführt werden. Diese Aktivitäten sind elementar zur Erreichung der Akzeptanzkriterien.
Wie du an diesen Beispielen siehst, handelt es sich bei den Tasks (oder auch Aufgaben) um Aktivitäten. Das bedeutet, so etwas tust du immer. Das hilft dir auch bei der Formulierung sehr stark.
Es kann natürlich auch Aufgaben geben, die keine User Story sind, aber auch für ein Sprint Ziel relevant sind. Diese müssen dann nicht zwangsläufig an User Stories hängen. Die meisten Aufgaben, die existieren, sollten einen Bezug zu einer User Story haben, denn die repräsentiert schlichtweg konkreten, erlebbaren Mehrwert (in den meisten Fällen).
Muss ich unter jeder User Story Tasks haben?
Aufgaben, die häufig in Scrum nur Tasks genannt werden oder im Jira (unterhalb einer User Story) auch Subtasks beschreiben Aktivitäten. Diese Aktivitäten sind elementar zur Erreichung der Akzeptanzkriterien. Ich finde es ein gutes Verhältnis wenn man so 1:3 bis 1:6 von User Stories zu Tasks in seinem Sprint Backlog hat. Müssen tust du das nicht, es hilft dir aber den Blick zu schärfen, ob den Teammitgliedern wirklich klar ist, was mit dieser User Story tatsächlich gemein ist.
Oft erlebe ich schnelle Antworten wie
Schaue ich dann rein, frage im Daily Scrum mal nach, dann ergibt sich oft das Bild, dass eben genau diese Aktivitäten viel "zu groß" geworden sind, als man es sich genauer angesehen hat. Daher empfehle ich immer in der Sprint Planung (Teil 2) einen etwas genaueren Blick auf die entsprechenden Aufgaben zu legen, damit eben genau das nicht passiert.
Indirektes Ableiten von Aufgaben aus Akzeptanzkriterien
Manche Teams leiten aus den Akzeptanzkriterien die Tasks ab. Das kannst du natürlich tun. Aus "Dokumentation ist abgelegt" wird dann implizit "Die Dokumentation schreiben". Das ist bei einfachen Themen machbar, bei etwas koplizierteren ist das schwieriger. Aus "Nur angemeldete Benutzer können auf Daten zugreifen" erfordert sehr wahrscheinlich mehr als nur eine Aufgabe.
Vergleich von Akzeptanzkriterien und Tasks
Akzeptanzkriterien und Tasks versuche ich "high level" etwa so zu betrachten:
Es sind Richtwerte und keine konkreten Grenzen. Behalte das bitte auch immer im Hinterkopf.
Akzeptanzkriterien und Tasks auf meinem YouTube Kanal
Wenn du der visuelle Mensch bist, dann schaue dir gerne auch das folgende Video zu Akzeptanzkriterien und Tasks auf meinem YouTube Kanal an.
Gesunder Menschenverstand
Aus dem Product Backlog Refinement kommen Product Backlog Items heraus, die gemeinsam verstanden sind. Ob das mit Akzeptanzkriterien und Tasks gemacht wird, ist im Grunde zweitrangig. Es hilft den meistens Teams Akzeptanzkriterien und Tasks zu nutzen. Beides gibt eine gute Struktur für das Team, an der man das gemeinsame Verständnis schärfen kann.
Es mag Teams geben, die das nicht brauchen - alle die, die fragen ob man das nicht braucht und weg lassen kann, brauchen es in der Regel aber gerade 😉
