Wie auch immer man zu einer Schätzung kommt wurden meistens folgende Punkte mit einkalkuliert:
- Risiko
- Know-How
- Komplexität
- Zeit
- Qualität
- Resourcen
Wie komplex ist es, vom der Wohnungstür zum nächstgelegenen Supermarkt zu gelangen. Nehmen wir an, es ist 1. Wie komplex ist es dann wohl, von der Wohnungstür zum nächstgelegenen Flugplatz zu kommen? Vielleicht eine 3. Dass bedeutet, dann die Bewältigung der zweiten Aufgabe 3-mal so komplex ist, wie die für Aufgabe eins.
Man macht also bewusst keine Aussage über Zeit, Resourcen, Know-How oder ähnliches. Man versucht vergleichbare Aufgaben in Komplexitätsrelationen herunterzubrechen. Gebräuchlich ist die Fibonacci Folge 1,2,3,5,8 - nicht mehr!
Wenn man ein paar mal mit Story Points geschätzt hat, bekommt man sehr schnell ein Gefühl dafür, wass eine 1, 2 oder 5 ist. Da das Team die Story Points pro User Story definiert, hat der Kunde einen Feedback. Zusammen mit dem ihm bekannten Business Value kann er nun die Priorisierung festlegen. User Stories mit hohem Business Value und geringer Komplexität werden in aller Regel zu Beginn realisiert. Für alle anderen Kombinationen gibt es unterschiedliche Ansätze. So geht man bespielsweise davon aus, dass ein Feature mit einer hohen Komplexität, aber geringem Business Value auch möglichst früh in einem Projekt begonnen werden sollte, da eine hohe Komplexität das Team und den Kunde bezüglich gewonnenem Know-How am weitesten voranbringt. Man geht davon aus, dass nicht die Entwicklung des Produkts die grösste Errungenschaft ist, sondern das gewonnen Know-How ...
5 Kommentare:
hehe, etwas zu Story Points gesucht und prompt hier gelandet ;)
das ging mir genauso :)
Hallo Jean-Pierre,
ich bin gerade am anlesen der Bedeutung der Story-Points und habe deinen komplett gegensätzlichen Artikel in Bezug auf http://www.livingscrum.de/2011/02/18/story-points-begriffserklarung-und-abgrenzung/ gefunden. Finde ich sehr interessant wie unterschiedlich das gesehen wird. Gibt es irgendwo eine offizielle Definition?
Ich finde die Aussage "Feature mit einer hohen Komplexität, aber geringem Business Value auch möglichst früh in einem Projekt begonnen werden sollte" momentan eher unlogisch, da durch die erhöhte Komplexität es evtl. zu Blockaden kommt.
Enrico
Hallo Enrico, nein, es gibt keine "offizielle" Definition. Scrum ist ein empirisches Management-Framework. Man kann, ja muss es sogar adaptieren.
Zu meiner Behauptung: Den Grund hierfür findet man im Wissensmanagement vom Scum Team. Hohe Komplexität bedeutet nicht anderes als ein hohes Mass an Unwissen- und/oder unwegbarkeiten. Wenn man diese Themen früh adressiert, wird die Lernkurve schnell ansteigen. Verschiebt man hohe Komplexität auf später läuft man Gefahr, dass man etwas deutlich unterschätz hat und schlussendlich viel Refactoring angesagt ist.
Gruss, jp
Hallo jp, zu deiner Behauptung:
Ich denke, dass die Entscheidung "Komplexität/BusinessValue - zu welchem Zeitpunkt?" eher situationsbezogen zu treffen ist.
Während deine Aussage zum Wissensmanagement richtig ist, und der geringe Business Value am Anfang auch geringes Business Risiko bedeuten kann, kann es aber je nach Projekt auch so sein, dass das Team für den PO dann am Wertvollsten ist, wenn es bereit ist, möglichst frühzeitig einen möglichst hohen Business Value zu erzeugen, und dafür späteres Refactoring bei komplexeren Aufgaben in Kauf genommen wird.
Immerhin hat der Kunde dann schon was Brauchbares an der Hand, während er sonst auf seinen eigentlichen Nutzen erst warten muss.
Die Einstellung "Man geht davon aus, dass nicht die Entwicklung des Produkts die grösste Errungenschaft ist, sondern das gewonnen Know-How " scheint mir sehr kunden- oder domänenspezifisch.
Auch ist es vom Produkt und der Domain abhängig, ob der Einstieg über weniger komplexe Themen nicht vorteilhaft für das bessere Erfassen der komplexeren Themen ist und deren vernünftige Bearbeitung eigentlich erst ermöglicht.
Det
Kommentar veröffentlichen