{"id":1859,"date":"2020-11-02T06:00:00","date_gmt":"2020-11-02T05:00:00","guid":{"rendered":"https:\/\/produktwerk.de\/produktwerker\/?p=1859"},"modified":"2024-03-06T12:47:38","modified_gmt":"2024-03-06T11:47:38","slug":"akzeptanzkriterien-richtig-einsetzen","status":"publish","type":"post","link":"https:\/\/produktwerker.de\/akzeptanzkriterien-richtig-einsetzen\/","title":{"rendered":"Akzeptanzkriterien richtig einsetzen"},"content":{"rendered":"\n\t

Wie k\u00f6nnt ihr als Product Owner Akzeptanzkriterien richtig einsetzen? <\/p>\n

Wir starten in dieser Folge mit etwas theoretischem Input und einer Definition von Akzeptanzkriterien. Wir besprechen, wie man gute Akzeptanzkriterien findet. Und nat\u00fcrlich auch, wie man sie sinnvoll einsetzen kann. Auch die Abgrenzung zur Definition of Done oder der Relevanz beim Sch\u00e4tzen besprechen wir. Und die oft gestellte Frage, ob es eine “richtige” Anzahl von Akzeptanzkriterien gibt. Und was haben Akzeptanzkriterien mit dem CCC-Prinzip von Ron Jeffries zu tun? Weiterhin geht es um verschiedene Formate und Techniken Akzeptanzkriterien zu finden. Habt ihr zum Beispiel schon mal probiert, sie nur zu visualisieren? D.h. die Visualisierung eures Gespr\u00e4chs \u00fcber das Verst\u00e4ndnis der User Story einfach nur als Bild anzuh\u00e4ngen? Oft reicht dies n\u00e4mlich schon aus.<\/p>\n

Uns ist es wichtig festzuhalten, dass es nicht um das Schreiben der Akzeptanzkriterien geht, sondern um ihre Nutzung im Gespr\u00e4ch mit dem Team und auch mit Stakeholdern. Das Wichtigste scheint zu sein, mit Akzeptanzkriterien Empathie f\u00fcr den Problem-Kontext herzustellen. Damit entsteht ein gemeinsames “mentales Modell” \u00fcber das zu l\u00f6sende Problem. Ach ja: bitte vermeidet ein “Contract”-Game zwischen Product Owner und Team. Das ist definitiv nicht hilfreich!<\/p>\n

Letztlich sind Akzeptanzkriterien f\u00fcr Product Owner eine super hilfreiche Praktik. Wie schon erw\u00e4hnt auch bei der Arbeit mit Stakeholdern. Wir k\u00f6nnen allen Product Ownern nur empfehlen, sich damit eingehend zu besch\u00e4ftigen! Dazu soll diese Episode beitragen.<\/p>\n

Folgende Quellen werden in der Folge genannt:<\/h3>\n– Gojko Adzic: Specification by Example – How Successful Teams Deliver the Right Software<\/a>
\n–
CCC-Prinzip<\/a> von Ron Jeffries
\n–
Behavior Driven Development<\/a>
\n– Beschreibungssprache der
Gherkin-Syntax<\/a>\n

Diese Folge steht auch im Zusammenhang mit unserer fr\u00fcheren Podcast-Episode “Das Product Backlog<\/a>“.<\/p>\n\t