Ich bin der Scrum Master für eines der Produkte in einem Softwareentwicklungsunternehmen. Unser Team, einschließlich mir, operiert von Indien aus. Mein Product Owner ist jedoch in den USA. Wir arbeiten an der Funktionsentwicklung für dieses Produkt, das jetzt seit zehn Jahren existiert.
Unser Team in Indien startete vor sechs Monaten ohne Produkt- oder Domänenkenntnisse. Es gibt einige Probleme, mit denen wir seitdem konfrontiert sind:
Gibt es also eine Richtlinie, die unser Team befolgen muss, um bessere User Stories zu erstellen, wenn man bedenkt, dass dieses Produkt ziemlich alt ist und sich seit seiner Entwicklung stark verändert hat?
Beachten Sie, dass es in den USA ein anderes Scrum-Team gibt, das parallel Funktionen für dasselbe Produkt entwickelt.
Mangelndes Produkt- oder Domänenwissen ist eher eine Prozesslücke als ein Fehler, der dem Team zuzuschreiben ist. Sie können die Genauigkeit Ihrer Schätzungen durch eine erhöhte Beteiligung des Product Owners, Schulungs- und Dokumentationsstorys und Story-Spikes erhöhen.
Das Team hat nicht die Möglichkeit, auf Schätzungen zu setzen. Am Ende des Sprint Plannings müssen alle in den Sprint aufgenommenen Stories eine Schätzung haben.
Die Schätzung sollte so genau sein, wie Sie es innerhalb des für die Sprint-Planung vorgesehenen Zeitfensters machen können. Deshalb muss der Product Owner beim Sprint Planning dabei sein:
Eine Schätzung ist keine Garantie – es handelt sich um eine „fundierte Vermutung“, die auf den Informationen basiert, die dem Team während der Schätzung zur Verfügung stehen. Wenn Informationen fehlen, wird diese Schätzung im Allgemeinen falsch sein; das ist einfach Teil des Scrum-Prozesses, und die Probleme, die zu einer schlechten Schätzung geführt haben, sollten während der Sprint-Retrospektive evaluiert und entsprechende Gegenmaßnahmen vorgeschlagen werden.
[D]as Team ist nicht in der Lage, verschiedene Stellen herauszufinden, an denen es den Code hinzufügen/ändern muss. Manchmal dauerte es mehrere Sprints, um eine User Story abzuschließen.
Eine gute Schätzung trägt der Unsicherheit des Teams Rechnung. Nehmen wir zum Beispiel an, eine User Story über das Hinzufügen eines Widgets zu einem Thingamabob beinhaltet Änderungen an einer unbekannten Anzahl von Klassen mit ungewisser Komplexität. Wie soll man das einschätzen?
Der erste Schritt besteht darin, Ihre Unsicherheit so weit wie möglich zu reduzieren. Vielleicht brauchen Sie ein Paar Story-Spikes, wie zum Beispiel:
Grenzen Sie den Anwendungsbereich ein.
Als Entwickler
möchte ich wissen, wie viele Klassen am Rendern eines Widgets beteiligt
sind, damit ich den Aufwand für die Änderung abschätzen kann.
Schätzen Sie die Komplexität ein.
Als Entwickler
möchte ich die Komplexität der Widget-Rendering-Klassen messen
, um den Arbeitsaufwand für deren Änderung genauer abschätzen zu können.
Wenn Sie einige Zeit mit diesen Spikes verbringen, ist Ihr Team besser in der Lage, eine fundierte Meinung über den Arbeitsaufwand abzugeben, der erforderlich ist, um die ursprüngliche Geschichte fertigzustellen. Darüber hinaus geben die Spikes dem Team mehr Sicherheit, dass es den Teil des Systems versteht, den es schätzen muss.
Unabhängig davon, ob Sie die Spikes zuerst ausführen oder nicht, enthalten alle Geschichten ein gewisses Maß an Unsicherheit. Je größer jedoch der Unsicherheitskegel ist, desto ungenauer sind Ihre Schätzungen. Die Spikes reduzieren den Kegel, beseitigen ihn jedoch nicht vollständig.
Unabhängig von der Größe des Kegels sollte man beim Schätzen immer das Konfidenzintervall berücksichtigen. Dies führt zu Story-Point-Anpassungen basierend auf dem aktuellen Wissensstand des Teams.
Hohes Vertrauen, kleiner Kegel der Unsicherheit
Beispielsweise kann das Team während der Sprint-Planung sicher sein, dass eine Änderung auf einen bekannten Bereich des Codes beschränkt ist und die Unsicherheit daher gering ist. In solchen Fällen lässt sich der Aufwand leicht abschätzen.
Geringes Vertrauen, großer Unsicherheitskegel
Wenn andererseits die Unsicherheit hoch ist, sollte sich dies in der Story-Point-Schätzung widerspiegeln. Das Team könnte zum Beispiel sagen:
Die Änderung betrifft nur die Umbenennung von „foo“ in „bar“, aber wir sind uns nicht sicher, welche Klassen von der Änderung betroffen sein sollen. Die Änderung selbst ist wahrscheinlich nur 1 Punkt, aber herauszufinden, welche Klassen geändert werden müssen, sind wahrscheinlich weitere 5 Punkte. Wir können es nicht eine Sechs nennen, da es keine solche Punktekarte gibt, also machen wir stattdessen eine 8-Punkte-Geschichte.
Denken Sie daran, dass Story Point-Schätzungen eine Möglichkeit sind, dem Product Owner und der Organisation Ressourcenbeschränkungen mitzuteilen. Die richtige Dimensionierung einer Story basierend auf Unsicherheit verbessert die Genauigkeit der Velocity-Metriken und spiegelt genauer die Geschwindigkeit wider, mit der das Projekt Elemente im Product Backlog bearbeiten kann.
Indem Sie den Mangel an verfügbaren Informationen über das System zu sichtbaren Kosten für das Projekt machen, geben Sie dem Product Owner die Möglichkeit, Schulungen, Dokumentationen oder Code-Refaktorisierungen zu priorisieren, die die Produktivität des Teams verringern könnten.
Fehlendes Systemwissen ist ein Prozessproblem , das nicht ohne Mitwirkung des Product Owners gelöst werden kann. Da der Product Owner durch die Priorisierung des Product Backlogs für die Ressourcenzuweisung im Projekt verantwortlich ist, liegt es in seiner Verantwortung, dem Product Backlog bei Bedarf Schulungs- und Wissenstransfer-Storys hinzuzufügen.
Wenn ich beispielsweise der Scrum Master in diesem Team wäre, würde ich Backlog Grooming als Gelegenheit nutzen, um vorzuschlagen, dass der Product Owner einige zeitgebundene Schulungssitzungen zum Product Backlog hinzufügt. Darüber hinaus würde ich aktiv dazu ermutigen, User Stories wie diese zum Product Backlog hinzuzufügen:
Als Entwickler eines Wartungsteams
würde ich gerne mit einem der ursprünglichen Entwickler zusammenarbeiten, um das Foo-Modul zu dokumentieren
, damit ich das System besser verstehen und genauere Schätzungen erstellen kann.
Solche Geschichten würden einen großen Beitrag zur effektiven Kommunikation der zugrunde liegenden Prozessprobleme an die Stakeholder leisten. Diese Geschichten sprechen auch direkt eine Wissenslücke an, die Ihr Projekt weiterhin plagen wird, bis es direkt konfrontiert wird.
Herausforderungen bei der Arbeit mit einem Offshore-Entwicklerteam
Basierend auf meiner Erfahrung mit einem ähnlichen Setup, hier sind meine Vorschläge:
Abhängig von Ihrem Budget und Ihrer Motivation sollten Sie einige, wenn nicht alle der oben genannten Möglichkeiten ausprobieren. Weitere Must-haves sind natürlich:
Ich würde mir die Beschwerden der letzten Jahre ansehen (wenn einige Akten aufbewahrt wurden) und ob einige Kunden in der Vergangenheit um Rückerstattung gebeten haben + welche Teile des Produkts kaputt gegangen sind oder womit die Kunden nicht zufrieden waren. Ich würde den Kundendienst und den technischen Support Ihres Unternehmens anrufen + diejenigen, die Ihr Produkt reparieren können (auch wenn dies ein anderes Unternehmen für Sie erledigt).
Tiago Cardoso
Ramu