.st0{fill:#FFFFFF;}

Scrum Grundlagen

Jetzt gute Akzeptanzkriterien und Tasks schreiben

 Juli 6, 2020

von  Sebastian

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:

  • Dokumentation ist erfolgt
  • Feedback ist eingeholt
  • Kundendaten können über die Adminmaske eingetragen werden
  • Jede Anfrage ist unter 5 Sekunden beantwortet
  • ...

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:

  • Wir wissen ganz genau was zu tun ist, da brauchen wir nichts extra zu dokumentieren.
  • Das ist uns zu viel Arbeit, die ganzen Akzeptanzkriterien aufzuschreiben. Das brauchen wir nicht bei uns.

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

  • Terminvereinbarung mit einem Keyuser, zum Ausprobieren und Feedback einholen.
  • Das Video drehen
  • Eine bestimmte Klasse zu entwickeln
  • Einen Workshop vorbereiten
  • Kapitel 3 der Dokumentation überarbeiten
  • ...

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

  • Ja, wir brauchen da nur schnell diesen Termin und dann reden wir drüber und kommen schon zu einem Ergebnis. Ich schreibe da keine Task auf.

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:

Akzeptanzkriterien

  • 3-8 Akzeptanzkriterien pro User Story
  • Sind binär beschrieben (ja/nein)
  • Fokussieren sich auf das "was"

Tasks / Aufgaben

  • Anzahl variiert von der Größe
  • Sind als Aktivität beschrieben
  • Fokussieren sich auf das "wie"

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.

Wir brauchen Ihr Einverständnis!

Wir benutzen Drittanbieter um Videoinhalte einzubinden. Diese können persönliche Daten über Ihre Aktivitäten sammeln. Bitte beachten Sie die Details und geben Sie Ihre Einwilligung.

Dieser Inhalt kann nicht freigegeben werden, da der Betreiber dieser Webseite die CMP-Konfiguration für diese Technologie nicht abgeschlossen hat.

powered by Usercentrics Consent Management Platform

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 😉

Sebastian

Ein paar Worte über den Autor
Agile Team Facilitator Sebastian Schneider
Agile Team Facilitator Sebastian Schneider
Sebastian Schneider CSP
Sebastian Schneider CSP-PO

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt. Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben. Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen. Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Sei auch mit dabei: Der Newsletter zu Scrum aus Augsburg.

__CONFIG_colors_palette__{"active_palette":0,"config":{"colors":{"62516":{"name":"Main Accent","parent":-1}},"gradients":[]},"palettes":[{"name":"Default Palette","value":{"colors":{"62516":{"val":"var(--tcb-skin-color-0)"}},"gradients":[]}}]}__CONFIG_colors_palette__
Hier gehts lang!
>