Viewing entries tagged
sales

Comment

Fazit aus Speech von @JeffSutherland über Einsatz von #StoryPoints oder #Stunden in @Scrum

Noch immer erlebe ich oft Diskussionen ob Stories mittels den abstrakten #StoryPoints oder aber mittels den etwas greifbareren Stunden geschätzt werden sollen. Eine kurze Zusammenfassung der Speech von @JeffSutherland am @Scrum Master Certification Course vom 26. April 13 in Zürich.

Aus menschlicher Sicht scheint die Aufwandschätzung in Stunden nachvollziehbarer und vorderhand einfacher. Die Studie von Microsoft aus dem Jahre 2012 hat aber einen wesentlichen Mangel bei Aufwandschätzungen anhand von Stunden ausgemacht. Diese konnte nachweisen, dass im Gegensatz zur Schätzung via StoryPoints die Aufwandschätzung mittels Stunden eine massiv höhere Standardabweichung aufweist im Verhältnis zum Detaillierungsgrad der Anforderungen. D.h. eine Schätzung mittels StoryPoints bleibt sich mit zunehmender Verdichtung der Anforderung in etwa gleich. Dies ist insbesondere auch für die Kunden essentiell, da nicht immer nachgebessert werden muss.
2013-05-25_21-03-15
Vorausschätzung hierfür ist jeweils, eine gewisse Kontinuität im Team und natürlich eine gemeinsame Referenzschätzung (Vergleiche auch Artikel Distributed Scrum 1 -  Planning Poker).
Interessant fand ich, dass gemäss Erhebungen von ScrumAlliance  mittels StoryPoints ca. 48x effizienter geschätzt wird. Zudem ist aus psychologischen Sicht auch ein Vorteil, wenn sich die Teammitglieder mit jeder abgeschlossenen StoryPunkte gewinnen, anstelle Stunden abarbeiten zu müssen.
Why should you still use estimations in hours if by story points it's 50 times faster and much more accurate?
Jeff Sutherland, co-inventor of SCRUM, Zurich 26.4.13
Nun gilt es die Kunden, als auch das interne Management zu überzeugen auf StoryPoints zu wechseln (Vergleiche auch Artikel Scrum – Ein umdenken im Sales Prozess). Ich kann dies jedem Scrum Team nur empfehlen.
Mehr Details siehe auch im Artikel von Jeff Story Points: Why are they better than hours?

Comment

Comment

Scrum - Ein umdenken im Sales Prozess 3, Kooperationsmodell "Money for nothing"

Bei Vertragsverhandlungen bezüglich Buchung eines Scrum Teams hatte @JeffSutherland @Scrum Master Certification Course Zurich einen etwas radikaleren Ansatz, wie Scrum verkauft werden könnte, vorgestellt. Gemäss Jeff ist dies nur mit erfahrenen Scrum Teams eine Option.
Im Kooperationsmodell "Money for nothing" bucht der Kunde nicht bloss über einen definierten Zeitpunkt ein Scrum Team, sondern hat auch die Möglichkeit dieses bei Zielerreichung zu stoppen bzw. zurück zu geben. Konkret bucht der Kunde bspw. für 10 Sprints ein Scrum Team à 3 Personen. Daraus resultieren Fixkosten pro Sprint von beispielsweise CHF 100'000.- bzw. über CHF 1Mio. für 10 Sprints.
7e46fa53eb7e5df6757b8e6b551d4d1c
Da der PO/Kunde die Umsetzung hinsichtlich Features mit höchstem Business Value steuert ist bspw. nach 5 Sprints 80% des Business Values erreicht und der Kunde entscheidet sich die Umsetzung zu stoppen. Der Kooperationsvertrag sieht nun vor, nicht die restlichen 5 Sprints à CH 100'000.-, sondern dem Lieferanten nur ein zu definierenden "Penalty" für den Arbeitsausfall bspw. 30% also CHF 150'000.- zu bezahlen.
Dieses Vorgehen kann in zeitlich beschränkten Projekten eine win-win Situation für Kunde und Lieferant sein. Da der Kunde weniger bezahlt als für alle 10 Sprints bezahlen würde aber eigentlich nicht mehr Funktionalität benötigt. Andererseits für den Lieferanten, der das Scrum Team stellt, der einen Teil des Umsatzausfalls vergütet kriegt.

Comment

1 Comment

Scrum - Ein umdenken im Sales Prozess

Sowohl Stakeholder, als auch Sales Manager verlangen nach ausgewiesenen Lieferobjekten die geschätzt, offeriert und abgegrenzt werden können. Insbesondere wenn es sich um Projekte im Fixpreis handelt wird seitens des Software Lieferanten sehr viel Energie in die Definition des Skopes investiert um sich abzusichern. Scrum bietet hier einen revolutionären Ansatz diese Mittel besser -nämlich in die Produktentwicklung- einzusetzen.
Generell ging ich früher bei der Ausarbeitung einer Offerte immer in zwei Schritten vor:
1. Kurzanalyse Grobkonzept
2. Detailanalyse
Im 1. Schritt wurde jeweils geprüft ob die Projektanfrage ins Portfolio passt, Timing für Erstellung der Offerte bzw. Umsetzung realistisch sind und die nötigen Ressourcen zur Verfügung stehen. In der Detailanalyse wurde durch ein technischer Senior Consultant die Lieferobjekte im Detail ausgewiesen, eine Lösung skizziert und die Lieferobjekte einzeln geschätzt inkl. Definition von Abgrenzungen. Dieser 2. Schritt war seit jeher immer sehr aufwändig. Es stellte sich zudem heraus, dass die erste Einschätzung des Projektvolumen aus Schritt 1 und die detaillierte Schätzung aus Schritt 2 meist nicht gross abwich.
Als Konsequenz entschieden wir uns daher in der Offerte von Scrum Teams auf den 2. Schritt zu verzichten und stattdessen Kapazitäten zu offerieren. Die KOSTEN definieren sich dabei neu aus der SUMME von verwendeten RESSOURCEN X RATE X TIME.
Hierfür sind folgende Eingangsparameter nötig:
  • RESSOURCEN: Benötigten Ressourcen/Profile anhand Anforderungen inkl. deren Velocity
  • RATE:  Rate pro Ressource, wobei von einer maximalen Buchung ausgegangen wird
  • TIME, die Nutzungsdauer bzw. das Projektvolumen resultiert aus der Einschätzung des Grobkonzeptes bei Berücksichtigung des Endtermins und der eingesetzten Ressourcen inkl. Buffer
Nachfolgend ein abstraktes Rechenbeispiel zur Kalkulation der Kapazitäten und der Projektkosten:
scrum_visual.001
Setzt man nun diese Parameter in obiges Rechenbeispiel ein erhält der Kunde eine Kostenplanung pro Sprint inkl. Kostendach fürs Gesamtprojekt. Bei youngculture setzen wir diese Kalkulation schon seit 2004 ein und diese wurde vom Markt sehr gut aufgenommen. Da die Vorgehensweise nach Scrum nachweislich nach einem working Inkrement verlangt ist zudem gewährleistet, dass der Kunde zum Projektende innerhalb des definierten Kostenrahmens ein Produkt erhält mit höchst möglichen Business Value. Aber dazu mehr in einem späteren Beitrag.

1 Comment