Ihr kennt das bestimmt auch. Und täglich grüßt das Murmeltier… Wir alle haben unsere mehr oder weniger bewährte Vorgehensweise bei der Ausgestaltung von Tickets. Und doch kommt es immer wieder vor, dass Tickets zum Zeitpunkt des Umsetzungsbeginns mehr Fragen aufwerfen, als Antworten liefern.
Aus dieser Erfahrung heraus ist die neue Frage der Woche im Bereich Anforderungsdokumentation entstanden.
Wie stellt ihr als Team sicher, dass die Anforderungen in einem Ticket klar, verständlich und umsetzbar sind?
Ich setze auf eine detaillierte Beschreibung a la User Story, das vermeiden von Technologie-Sprache (fällt mir als Nicht-Techi nicht schwer ) und die Definition von Akzeptanzkriterien. In der Folge dann Fragen/Reden/Handeln… Kontinuierliche Kommunikation. Als extrem hilfreich empfinde ich hierbei für alle Seiten, wenn wir Funktionalitäten visualisieren und mit dem Kunden darüber ins Gespräch kommen.
Die Verständlichkeit ist allerdings tatsächlich aktuell weniger mein Problem. Bei mir geht es eher um die Struktur des Informationsfluss an sich… also wie kommen Anforderung rein #Kanälechaos, wie und von wem werden sie weiterverarbeitet #Rollenklarheit und wie/wann/wo gehen sie dann wieder raus #Verantwortlichkeiten.
Ich kann nur alles unterstreichen, was Chrissy schon geschrieben hat: Akzeptanzkriterien, Kommunikation (!!!) und Visualisierung.
Es gibt nur einen Punkt, an dem ich widerspreche: die detaillierte Beschreibung.
Ein PBI ist keine Feinspezifikation oder ein Lastenheft. Die nötigsten Eckpunkte und das gemeinsame Verständnis müssen da sein, keine Frage. Der Rest ist Kommunikation/ Kollaboration. Oder zumindest ist das der erstrebenswerte Zustand.
Danke Dir @MarcoSpoerl. Ich sehe es wie Du. Bei mir sind PBI zu 95% Teil eines Epics, und dort wird für das Verständnis auch noch mal ein größerer Rahmen drum herum gezogen. Ich möchte ja auch die Kreativität und das Mitdenken vom Team bei Stories haben weswegen Mut zur Lücke bei Stories für mich durchaus in Ordnung ist. Bei den Stories verwende ich dann gerne auch noch Personas, damit sich das Team noch besser in das “Wer” in eine Story hineinversetzen kann.
Kannst du uns erklären wie du die Personas anwendest? Ich habe wenig Erfahrung damit und finde jeden Ansatz für ein besseres Verständnis seitens des Teams sinnvoll.
Ich hatte in der Vergangenheit mit einem Teams aufgrund gemeinsam prägender Erfahrungen teilweise in Tickets eine Zusatzinfo mit reingenommen: “out of scope”. Um ganz klar eine Abgrenzung aufzuzeigen. Meistens wurden dort Hinweise der Entwickler*innen festgehalten oder wir haben gemeinsam die Abgrenzung erarbeitet. Damals war das wichtig, da der Kunde gerne mehr in Tickets reininterpretiert hatte. Damit hatten wir zum einen Klarheit für uns in der Umsetzung, als auch in der Kommunikation mit dem Kunden. Das hat uns sehr geholfen.
Wie Personas entstehen ist glaube ich eine große Geschichte für sich, aber wenn Sie da sind, würde ich immer bevorzugen diese zu nutzen, statt generischer Rolle. “Als eingeloggter User möchte ich …” ist doch langweilig
Abgrenzung finde ich auch sehr wichtig. Ich nenne es aber Perspektive: da führe ich auf, was mit dieser Story (PBI) nicht tun, ich (als PO) aber für die Zukunft antizipiere (wenn ich auch nicht genau weiß, ob und wann.)
@manueloffermann
Personas sind eigentlich nichts anderes als deine Benutzergruppen. Wir haben beispielsweise bei einer PWA für eine Immobilien- und Architekturfirma drei Personas und nutzen diese um über die User Stories verschiedene Dashboardansichten zu gestalten. Du kannst hierdurch noch konkreter auf deine Nutzergruppen eingehen und auch bei der Priorisierung danach arbeiten.
Wenn man Personas nach dem Lehrbuch macht, basieren diese auf Forschung und realen Daten. Das hat grundsätzlich natürlich den Vorteil, dass auch in deinen User Stories die Wahrscheinlichkeit von Annahmenfehlern reduziert wird. Grundsätzlich können sie im kompletten Entwicklungsprozess bis hin zum Erstellen von Testfällen und Szenarien sehr hilfreich sein
) und die Definition von Akzeptanzkriterien. In der Folge dann Fragen/Reden/Handeln… Kontinuierliche Kommunikation. Als extrem hilfreich empfinde ich hierbei für alle Seiten, wenn wir Funktionalitäten visualisieren und mit dem Kunden darüber ins Gespräch kommen.
