ThomasHi! Mal ne Frage: was sind für Euch Kriterien um zu bewerten, ob Akzeptanzkriterien einer Story gut/sinnvoll/ausreichend sind? Ich will mir da Leitfragen für mich aufschreiben…
Hier z.B. in den Beispielen wären mir die AC viel zu unpräzise und nicht testbar: https://www.atlassian.com/work-management/project-management/acceptance-criteria
“The user can download reports in various formats (e.g., CSV, PDF).”
e.g. stört mich sehr. Aber die anderen Beispiele find ich z.T. auch nicht gut.
Herr Bosslet@nobsagile na ja, reports downloaden schön und gut, aber was bringt der Inhalt oder die Art der Möglichkeit es tun zu können. Machts irgendwas schneller oder regelmäßiger, brauch der User die Reports?
Man kann das aber auch nicht so losgelöst betrachten. Es zählt auch der Kontext vom Feature. Bin kein Freund davon, das Stories für sich stehen müssen (außer local context). Das macht nur unnütze Adminarbeit.
Man kann das aber auch nicht so losgelöst betrachten. Es zählt auch der Kontext vom Feature. Bin kein Freund davon, das Stories für sich stehen müssen (außer local context). Das macht nur unnütze Adminarbeit.
@cartagena mein reden. Daher such ich ja gerade, ob jemand da gute und pragmatische Tipps hat. Atlassian hat nicht wirklich geholfen (wie so oft…)
@nobsagile na ja, mal abgesehen von dem vorher Gesagtem, hängts für mich oft eher an der Umsetzung und Abnahme. Wie viel Selbstorga und -displin hat die Person, die die Story umsetzt. Wie kritisch ist ein PO bei der Abnahme, wie sehr hackt auch mal nen PM nach. Beobachte ich immer wieder, und finde ich viel wichtiger als stumpfe Kriterien (die natürlich ihre Daseinsberechtigung haben).
@cartagena Hi! Vielen Dank! Das Festmachen an einer Person "Wie viel Selbstorga und -displin hat die Person, die die Story umsetzt" finde ich ziemlich merkwürdig, wenn ich ehrlich bin.
"Wie kritisch ist ein PO bei der Abnahme, wie sehr hackt auch mal nen PM nach" ist mir auch zu wenig auf den Nutzer ausgerichtet.
Beides wären für mich keine Kriterien.
"Wie kritisch ist ein PO bei der Abnahme, wie sehr hackt auch mal nen PM nach" ist mir auch zu wenig auf den Nutzer ausgerichtet.
Beides wären für mich keine Kriterien.
BEOZ@nobsagile Da stimme ich dir zu. Meistens sind nach meinen Erfahrungen die User Stories / Use Cases / Requirements das Problem. Auf un-smarte Stories kann man oft keine schlauen AC schreiben ohne dass man zu viel (falsches?) hineinintepretiert. Kommt immer auf das Projekt-Setup an. Reviews sind wichtig und dass man miteinander spricht.
Sebastian Stautz@nobsagile Ich mage gerne wenn es Grafiken gibt.
Bei GUIs Konzept-Zeichnungen / Mockups, bei Abläufen Fluss-Diagramme, bei Daten Beziehungsdiagramme.
Akzeptanzkritieren sind für mich nur eines von mehrere Mitteln wie man gemeinsames Verständnis zwischen allen Beteiligten schafft.
Bei GUIs Konzept-Zeichnungen / Mockups, bei Abläufen Fluss-Diagramme, bei Daten Beziehungsdiagramme.
Akzeptanzkritieren sind für mich nur eines von mehrere Mitteln wie man gemeinsames Verständnis zwischen allen Beteiligten schafft.
@SebastianSolidwork Danke! Ich stelle bisher fest, zu konkret eher nicht. Fluss-Diagramme sind ja schon fast "wie", oder?
@nobsagile Kommt darauf an. Zum einen können sie stark den fachlichen Anforderung entspringen.
Zum anderen bin ich kein großer Freund davon Was und Wie stark zwischen PO/Kunde und Team aufzuteilen.
Auch das Wie darf gerne in Zusammenarbeit entstehen. In meinem, stark technischen, Umfeld (Mobilfunk) ist es normal, dass Entwickler Stories mitgestalten. Auch mit Diagrammen.
Zum anderen bin ich kein großer Freund davon Was und Wie stark zwischen PO/Kunde und Team aufzuteilen.
Auch das Wie darf gerne in Zusammenarbeit entstehen. In meinem, stark technischen, Umfeld (Mobilfunk) ist es normal, dass Entwickler Stories mitgestalten. Auch mit Diagrammen.
@SebastianSolidwork Hab ich kein Problem damit :)
SCRUMschau@nobsagile
AC können agiles Arbeiten killen und die Developer zu Code Monkeys und das Sprint Review zur eledigen-Abnahme-Session machen.
In meinem Umfeld sind AC oft wie eine Einkaufsliste: es wird aufgelistet was man im Refinement als mögliche Lösung besprochen hat und worauf die Schätzung basiert.
Wenn in der Umsetzung nicht alles erfüllt wird/werden kann, dann spricht man miteinander.
Also: Gedankenstütze statt Vertrag.
AC können agiles Arbeiten killen und die Developer zu Code Monkeys und das Sprint Review zur eledigen-Abnahme-Session machen.
In meinem Umfeld sind AC oft wie eine Einkaufsliste: es wird aufgelistet was man im Refinement als mögliche Lösung besprochen hat und worauf die Schätzung basiert.
Wenn in der Umsetzung nicht alles erfüllt wird/werden kann, dann spricht man miteinander.
Also: Gedankenstütze statt Vertrag.
@scrumschau Die Gefahr sehe ich auch! Gedankenstütze statt Vertrag gefällt mir!
Rosanna Sibora@scrumschau @nobsagile das wichtigste in diesem Kontext: wie sind sie entstanden, wer hat sie definiert und enthalten sie konkrete Lösungen oder fokussieren sie sich auf Outcomes. #featurefactory