Würde man die Praxis der Estimations als Userstory formulieren, so lautete diese:
Als Product Owner möchte ich wissen, wie groß anstehende User Stories sind, um priorisieren und eine bessere Release-Planung machen zu können.
Und würde man diese Userstory wiederum einem Team zur Schätzung vorlegen, wäre eine lange Diskussion vorprogrammiert, wenn die Story nicht sogar als unschätzbar zurück gewiesen würde.
Estimations sind bei den meisten Scrum Teams üblich, aber auch umstritten. Viele Entwickler empfinden Estimations als vergeudete Zeit, die sie lieber produktiv am Rechner verbringen würden, anstatt auf Basis von halbgaren Informationen über irgendwelche abstrakte Größen zu entscheiden, die ohnehin nicht überprüfbar sind. Dass man über Stories spricht, die vielleicht gar nicht oder erst in Monaten oder Jahren zur Umsetzung kommen, wenn sich die Bedingungen komplett gewandelt haben, macht die Sache nicht besser.
Der Product Owner dagegen fordert genau diese Zahlen, um zu erfahren, wie leicht oder schwer eine Story umgesetzt werden kann, um planen und entscheiden zu können und sich vielleicht auch vor dem Management zu rechtfertigen. Gleichzeitig ist er oder sie frustriert, wenn das Team jede ungenaue Story zurück weist oder die Team-Mitglieder ihre eigenen Schätzungen wieder komplett über den Haufen schmeißen.
Keine sehr guten Voraussetzungen für produktive Meetings und eine verlässliche Planung.
Sind Estimations also wirklich hilfreich? Schließlich kosten sie eine Menge Zeit und damit Geld.
Für Vasco Duarte, Autor des Buches „No Estimates. How to always be on time, and not risk missing important deadlines or go over budget“ sind Estimations deshalb reine Zeitverschwendung. Eine solche Vorhersage, die mit Sicherheit Zeit kostet, aber nur mit einer gewissen Wahrscheinlichkeit eine korrekte Vorhersage liefert, sei nichts anderes als zu sagen: „Gib uns dein Geld, wir versprechen dir, nicht mehr als 25% zu verschwenden (mit einer Chance von 25%, dass wir mehr verlieren).“
Rufen Sie uns an: 030 – 555 74 70 0
