Teil 4/4: Typische Fehler bei Aufwandseinschätzung und Abnahme
In unserer Artikelserie zeigen wir Euch, wie die Abräumer von morgen Produkte völlig ohne Projektmanagement entwickeln und dabei Zeit, Geld und Nerven sparen – und worauf ihr dabei achten müsst. Im ersten Schritt habt Ihr Eure Entwicklung bereits transformiert und arbeitet ohne Projektmanagement, dafür aber nun mit der dedizierten Rolle des Product Owners. Woher ihr nun wisst, ob ihr und der Product Owner auf der richtigen Spur seid, eure Aufwandseinschätzung richtig ist und erfolgreich sein werdet, erfahrt ihr in diesem Beitrag der Serie.
Weiterlesen
Wir behandeln das Thema in einer Serie bestehend aus 4 Artikeln, die unterschiedliche Aspekte beleuchten. Und am Ende der Artikelserie werdet Ihr wissen, wie Ihr die Transformation vom klassischen Projektmanagement zu modernen erfolgreichen Ansätzen hinbekommt, welche Aufgaben und Zuständigkeiten ein sogenannter „Product Owner“ (im Folgenden mit „PO“ abgekürzt) tatsächlich hat und woher dieser weiß, ob er/sie erfolgreich ist, bzw. gute Arbeit abliefert. Wir werden uns aber auch ansehen, wie eine gute Wochenroutine aussieht, die Euch bei Eurem Erfolg helfen wird. Und um das Thema vollumfänglich abzurunden, werfen wir ein besonderes Augenmerk auf die Wichtigkeit der Einschätzung des Bearbeitungs- und vor allem auch Abnahmeaufwandes.
Fassen wir kurz nochmal zur Orientierung zusammen, worum es in der Artikelreihe Produktentwicklung ohne Projektmanagement gehen wird:
- Wie Euch die Transformation vom klassischen Projektmanagement zu modernen erfolgreichen Ansätzen gelingt
- Die Zuständigkeiten und Aufgaben der Product Owner-Rolle (PO)
- Woran der PO weiß, ob er/sie erfolgreich ist bzw. gute Arbeit macht
- Wie eine gute weekly Routine aussieht + Erfolgs- Checkliste
- Die Wichtigkeit der Einschätzung des Bearbeitungs- und vor allem auch Abnahmeaufwandes
Im letzten Artikel unseres Vierteilers geht es darum, welche typischen Fehler bei der Definition von Akzeptanzkriterien und der Einschätzung von Userstories vorkommen können, die sich oftmals erst bei der Abnahme oder später im Livebetrieb zeigen und enorme Auswirkungen haben können.
Aus Erfahrung zeigt sich, dass bei der Aufwandseinschätzung von Userstories einige Aspekte oft nicht richtig mit einbezogen werden: der Aufwand für die Abnahme, bzw. die Prüfung anhand der Akzeptanzkriterien. Auf der anderen Seite werden häufig wichtige Akzeptanzkriterien vergessen, sei es mangels Erfahrung oder aus Zeitgründen. Theoretisch sind Fehler und Mängel, die nicht durch die vordefinierten Akzeptanzkriterien abgedeckt sind, in Ordnung. Das Team hat ja korrekt geliefert. Dennoch können Stories dann nicht für das Rollout freigegeben werden.
Ursache 1: Fehlende Akzeptanzkriterien bei der Aufwandseinschätzung
Um Fehler bei der Aufwandseinschätzung zu vermeiden, lohnt es sich, einige Teammitglieder oder das gesamte Team bei der Definition von Akzeptanzkriterien von Anfang an mit einzubeziehen – oft ergeben sich wichtige Kriterien erst im Gespräch oder mit dem fachlichen Hintergrundwissen, wie das System aufgebaut ist bzw. sein wird. Warum?
Um das an einem Beispiel zu zeigen:
“Ein Formular mit einem Eingabefeld soll nach dem Absenden einen Fehler anzeigen, wenn das Feld leer gelassen wurde. Es soll eine Erfolgs-Meldung zeigen, wenn ein Text eingegeben wurde.”
Das könnten zwei einfache Akzeptanzkriterien sein, die ein PO formuliert hat. Mit technischem Background-Wissen ergeben sich jedoch noch weitere Cases: Was soll passieren, wenn Zeichen mit falschem Encoding angegeben wurden und sie vom System daher nicht verarbeitet werden können? Was wird erwartet, wenn jemand einen Text aus 260 Zeichen angibt, obwohl die Datenbank evtl. nur 256 Zeichen-Texte maximal speichern, bzw. akzeptieren kann? Was passiert, wenn das bereits abgesendete Formular mit der schon erschienenen Erfolgsmeldung einfach im Webbrowser mit F5 aktualisiert wird, sprich die Daten erneut in das System zur Verarbeitung gegeben werden, obwohl es schon in Datenbank gespeichert wurde? Oder was soll passieren, wenn zwar das System zur Formularverarbeitung funktionstüchtig, aber die Datenbank selbst aktuell nicht erreichbar ist? (zur Erläuterung: sie sind oft auf anderen Servern in der Cloud)
Genau solche Extra-Cases machen es schwierig, Akzeptanzkriterien anfangs korrekt zu definieren – zumindest für den PO allein. Und das Team oder der PO stolpert am Ende des Realisierungszyklus bei einer finalen Abnahme darüber. Oder User bemerken Fehler im Livebetrieb. Der PO erachtet diese Mängel als so wichtig, dass das Feature nicht ohne Mängelbeseitigung freigegeben werden kann, obwohl es alle anfangs definierten Akzeptanzkriterien erfüllt. Wie erklärt man das den Stakeholdern oder Geldgebern? Schwierige Situation!
Daher unser Tipp: Lasst Eure definierten Kriterien von mindestens einer Person mit anderem Wissens- Background überprüfen. Es ergeben sich meist Szenarien, die mit angegeben werden sollten. Nur wenn diese Kriterien vollständig sind, ist die Userstory klarer greifbar und erst dann kann das Team den Aufwand besser einschätzen. Unter Umständen ist es sinnvoller, mehr Storypoints anzugeben als die ursprüngliche Schätzung ergeben hätte.
Ursache 2: Tests sind nur mit einem definierten Ursprungszustand valide
Fast immer wird falsch eingeschätzt, wie Abnahmetests überhaupt gemacht werden können: Sie erfordern immer einen Ursprungszustand des Systems, damit das Ergebnis valide ist, also die Erwartungen des Tests erfüllt. Dieser Ursprungszustand solltemit den Akzeptanzkriterienangegeben sein, da schon eine andere Datenbasis das Ergebnis verfälschen könnte. Das kann einfach erfolgen, indem man zu Beginn schreibt:
“Angenommen, X und Y sind Z und es gibt noch keinen Datensatz zu P und Q. Wenn ich im Formular nun einen Text eingebe und auf Absenden klicke, dann erscheint eine Erfolgsmeldung.”
(oder so ähnlich)
Ursache 3: Aufwand für das Erstellen von Testdaten, bzw. der Datenvor- und -nachbereitung
In anderen Cases werden ganz bestimmte Daten vorausgesetzt, die vor dem Test sauber angelegt bzw. zurückgesetzt werden müssen. Genauso müssen nach den Tests bestimmte Daten wieder entfernt werden.
Beispiel:
“In einem System können sich Interessierte registrieren”.
Die Akzeptanzkriterien setzen hier voraus, dass die im Test verwendete Userkennung noch nicht im System vorhanden ist. Das heißt, nach jedem Testdurchlauf sollte die Userregistrierung wieder rückgängig gemacht werden, damit der Test wieder ausführbar ist. Das wäre eine typische Nachbereitung. Je nach Systemaufbau ist diese Testnachbereitung bei End-to-End-Tests nicht trivial, da mehrere Komponenten involviert sein können. Ein anderes Beispiel ist das Testen einer Kündigung: es setzt immer voraus, dass der Eintrag noch nicht gekündigt ist und muss also nach jedem Testlauf wieder auf den nicht-gekündigten Zustand gesetzt werden.
Entsprechende Vor- und Nachbereitungen müssen bei der Aufwandseinschätzung und den Unteraufgaben bei jedem Testcase berücksichtigt werden. In der Praxis sehen wir, dass das oft vergessen wird. Je nach System kann das ein enormer Zeit- oder Komplexitätsfaktor sein. Kriterien hier:
- Testfrage 1: Was muss technisch gegeben sein, bzw. gemacht werden, damit der Test mehrfach hintereinander immer zum gleichen (erwarteten) Ergebnis kommen kann?
- Testfrage 2: Hat die Ausführung dieses Tests Einfluss auf den (erwarteten) Ursprungszustand bei anderen Tests?
Fazit
Wir haben Euch drei typische Ursachen aufgezeigt, die in der Regel zu einer falschen Aufwandseinschätzung der Story führen und bestimmte Mängel ggf. durchrutschen lassen, weil sie nicht in den Akzeptanzkriterien definiert wurden. Somit sind in beiden Fällen Folgeprobleme quasi vorprogrammiert, sei es bei der Abnahme oder bereits im Livebetrieb. Und genau das gilt es zu vermeiden.
Eure drei Regeln zusammengefasst: Lasst Eure Akzeptanzkriterien immer von jemand anderem reviewen und ergänzen. Gebt immer den Ursprungszustand an. Unterschätzt nie den Aufwand für Testvor- und nachbereitungen, damit alle Tests mehrfach ausgeführt werden können.
Ausblick
Diese Vierer- Serie zum Thema Produktentwicklung ohne Productmanager findet hier ihren Abschluss. Bei unserem #MacherMittwoch werden wir natürlich weiter spannende Themen rund um die Welt der Productowner, von Startups und deren Entwicklungen mit euch teilen. Wir legen Wert darauf, dass Euch all unsere Artikel im Alltag weiterhelfen und Euer Produkt so erfolgreich werden kann.
Kleiner Tipp zum Schluss: Um nichts zu verpassen und euren Erfolg zu sichern, abonniert einfach diesen Kanal rechts in der Seitenleiste.