Requirement Engineering als Teil der Wertschöpfungskette

Öfters schon habe ich POs sagen hören: “Ich hoffe, meine User Storys passen für das Grooming” oder “Ich weiß schon, dass die Storys nicht optimal vorbereitet waren…” Sprich: POs haben oft ein schlechtes Gewissen, weil sie befürchten, dass die Storys/Tickets nicht die nötige Qualität haben. Nicht selten zurecht.
Warum ist das so? Ein Gedanke: Weil wir das Requirements Engineering (RE) nicht als Teil der Wertschöpfungskette betrachten. Das fertige Issue erscheint “magisch” in der Ready-Spalte und geht dann in den Value Stream Dev | Test | usw. Was davor passiert, ist Freestyle. Es gibt Teams, die für Issues eine Definition of Ready haben, das hilft sehr und es stellt Kriterien mehr oder weniger klar. Es bildet aber nicht die Wertschöpfung im RE ab.

Requirement Engineering hat einen Value Stream

Was heißt das nun für POs? Sie sollen gute Issues erzeugen, ohne einen klaren Prozess vor Augen zu haben, wie das überhaupt geht. Ich zumindest kenne keinen solchen definierten Prozess. Viele machen einfach und schauen, dass es passt. Und wie sagt es W. Edwards Deming so trefflich: „If you can’t describe what you are doing as a process, you don’t know what you are doing.“ Ich glaube, es würde helfen, die Schritte im RE abzubilden und als Teil der gesamten Wertschöpfungskette zu sehen – vom Eingang des Kundenwunsches bis hin zum Review durch den Kunden. In diesem Zusammenhang habe ich einen Ansatz von Mike Burrows, einem führenden Mitglied der Lean Kanban University von David Anderson entdeckt: Er sagt, man solle die Steps im Value Stream (in Kanban) als Schritte der “Entdeckung von Wissen” (Knowledge Discovery) sehen. Das ist – so finde ich – hilfreich, weil es auf eine andere Art noch mal klarstellt, warum man einen Schritt in der Wertschöpfungskette hat.

Requirement Engineering als Teil des Value Stream und Knowledge Discovery

RE-im-Value-Stream

 

  • PO Issue Generation: Der PO erzeugt das Ticket mit dem Kunden bzw. aus den Kunden-Informationen heraus.
  • PO 1 Dev Grooming: Mit einem Entwickler geht der PO das Ticket durch. So bekommt er frühzeitig ein Feedback, ob alles Sinn macht, ob etwas fehlt oder unklar ist, usw. Das ungünstigste, was passieren kann, ist, dass man erst im SP1 feststellt: “Oh, das Ticket ist ja noch ganz unklar.” Dann hat der PO keine Chance mehr, das Issue in den Sprint zu bekommen. Je früher er das weiß, desto besser. Mit niedrigen Kosten aber (nur 1 Dev) hat der PO auf diese Art ein erstes Screening und ausreichend Zeit, sich noch einmal an den Kunden zu wenden.
  • UAK: Der PO macht UAKs. There shall be no issue without UAK! (11. Gebot)
  • Customer Issue Review: Der PO spricht die UAKs mit dem Kunden durch. Wurde alles richtig verstanden?
  • Grooming: Ab jetzt geht es im “klassischen” Workflow weiter, also Grooming des Tickets mit dem Team, Entwicklung, Testing usw.

Sie haben Fragen zum Thema Requirement Engineering oder Projektmanagement?
Gerne stehen wir Ihnen in einem persönlichen Gespräch zur Vefügung.

Informationen zu unseren Schulungsangeboten finden Sie unter 
https://www.techdivision.com/leistungen/analyse-und-beratung/schulungen.html

 

 

Kommentar abgeben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.