-
„Bitte nicht schon wieder schätzen!” Vielen Developern graust es beim Gedanken an die nächste Schätz-Runde. Mühsame Diskussionen um Story Points, nach einer Stunde sind vielleicht 7 User Stories geschätzt…
Doch es geht auch anders. In diesem Artikel richtet Pascal den Blick auf den (Un-)Sinn von Schätzungen in der Produktentwicklung und stellt seinen Favoriten unter den Schätz-Methoden vor – nebst realen Anwendungsfällen aus der Praxis.
-
Bei unserer Arbeit mit Organisationen stoßen wir immer wieder auf die gleiche Herausforderung im Risikomanagement: Mangel an Klarheit über Portfolio-Timelines und über die Verbindungen zwischen verschiedenen Projekten. Abhilfe schafft hier das Tool „Daniels Team Forecaster“, das wir zur freien Nutzung für Produktteams zur Verfügung stellen. Den Link zu Template und Anleitung findet ihr im Beitrag.
-
Die Frage, wann bestellte Software fertig wird, ist – nicht nur aus Kundensicht – eine berechtigte. Doch gibt es viele Fälle, in denen zeitliche Prognosen ordentlich daneben liegen. Alles eine Frage der korrekten Klassifizierung von Arbeit und der Wahl der passenden Schätz-Methode, erklärt uns Simon.
-
Die Chancen stehen gut, dass dein Team jeden Sprint erneut vor folgendem Problem steht:
Einerseits möchtet ihr die Einträge im Product Backlog vor dem Sprint in Story Points schätzen, um die Komplexität der Arbeiten besser zu verstehen. Andererseits sollt ihr gegenüber dem Kunden ein Datum angeben, wann das Feature geliefert wird. Wir haben also immer wieder diese Schwierigkeit:
Dein Team schätzt in Punkten, aber der Kunde möchte ein Datum.
-
Von niederschmetterndem Nutzerfeedback und verlangter Aufwandsschätzung. Simon beschreibt eindrücklich 5 Herausforderungen, die Product Owner meistern müssen entlang seiner eigenen Erfahrung als junger Product Owner – die manchmal durchaus schmerzhaft war.
-
Hochperformante Teams, die vorhersagbar liefern, tragen maßgeblich zum Erfolg von Unternehmen bei.
Solche Teams versprechen sich Unternehmen, die Scrum einführen. Leider überprüfen Organisationen dieses Versprechen häufig nur auf der Grundlage von Velocity.
Velocity ist eine hilfreiche Metrik und gleichzeitig eine Quelle für Fehler.
Keine weiteren Inhalte verfügbar.
Keine weiteren Inhalte verfügbar.
