Die Teamgeschwindigkeit verlangsamt sich dramatisch zum Ende eines Sprints

Ich habe festgestellt, dass die Teamgeschwindigkeit manchmal gegen Ende eines Sprints "negativ" wird. Es gibt nur noch wenige triviale Geschichten/Bugs, aber sie haben außerordentliche Anstrengungen gekostet, um sie zu beenden. Team scheint nicht erschöpft zu sein. Dies ist aber immer gefährdet und verschiebt den Liefertermin. Was ich versucht habe:

  1. Mikrokontrolle – gibt einen kleinen Schub, aber stresst die Menschen und widerspricht agilen Praktiken
  2. DYI - funktioniert aber nur wenn man weiß wie
  3. Reduzieren Sie die Sprint-Backlog-Kapazität, um eine Cooldown-Periode zu haben, in der das Team alles richtig machen kann. - Funktioniert nicht
  4. Es wurde eine Redline eingeführt, so etwas wie eine interne Deadline, wo alle Geschichten mit allen nicht trivialen Fehlern geschlossen werden sollten. - Funktioniert nicht
  5. Die Freigabe wurde auf die Mitte eines nächsten Sprints verschoben und das Brandbekämpfungsteam eingesetzt, das die verbleibenden Aufgaben BEENDET. - Funktioniert, aber niemand will die Arbeit anderer erledigen.

Keine der aufgeführten Methoden funktioniert zu 100 % oder ist aus Sicht der Interessengruppen/Managements zufriedenstellend.

Irgendwelche Ideen zur Art der Dinge oder Vorschläge, wie man das Problem loswird?

Wie lange dauern die Sprints?
Haben Sie eine bestimmte Zeit pro Sprint für die Korrektur von Legacy-Code einkalkuliert? Könnte es sein, dass Entwickler die schwierigsten Dinge bis zum Ende des Sprints verschieben, und sie sind aufgrund von Problemen mit Legacy-Code schwierig, und deshalb dauert es ewig, sie zu beheben?
Was meinst du damit, dass sich die Geschwindigkeit gegen Ende eines Sprints verlangsamt? Wollen Sie damit sagen, dass Sie die Velocity täglich messen und hoffen, diese Dynamik beizubehalten? Wenn ja, scheint das äußerst gefährlich zu sein. Die Geschwindigkeit ist ein Maß für die Leistung des Teams über die gesamte Sprint-Box. Die täglichen Schwankungen sind weniger wichtig als die Geschwindigkeitskonstanz von Sprint zu Sprint.
Meine zusätzliche Befürchtung ist, dass Sie sich tatsächlich auf die Arbeit beziehen, die begonnen, teilweise abgeschlossen und dann trotz des Großteils der abgeschlossenen Entwicklung schmachtend zurückgelassen wurde. Das zeigt mir, dass Ihre Definition of Done nicht eingehalten wird und Geschichten keine dünnen Scheiben von Wert sind, die zur Vollendung getrieben werden. Können Sie eine typische User Story beschreiben, die Ihr Team unvollendet lässt?
NielsvanReijmersdal hängt von einem Projekt und einer Phase ab. Typischerweise 2±1 Wochen. @YvonneAburrow ja, wir haben die Kapazität des Sprint-Back-Logs reduziert, um Zeit zu haben, mit Altlasten, zusätzlichem Refactoring (Tech-Storys) und Resten zu arbeiten. Nun, wir zerlegen Geschichten immer auf ein minimales wertvolles Stück. Es bedeutet auch, dass Burndown jeden Tag aktualisiert wird. Es besteht also die Möglichkeit, eine grobe Tagesgeschwindigkeit zu haben, aber Sie haben Recht, sie kann nicht einmal auf Sprintbasis gleich oder konstant sein. Hier ist ein Beispiel für eine Definition of done pastebin.com/yuxfU5hx Ich würde mich freuen, wenn Sie mir helfen, es zu verbessern.
@Venture2099 Beispiel einer Geschichte: Als französischsprachiger Benutzer möchte ich eine französische Lokalisierung für das xxxxx-Portal haben, damit ich eine bessere Benutzererfahrung haben kann. Hinweis: Das ist keine triviale Geschichte für Content Manager. Wir haben 3 Systeme, die unabhängig voneinander auf einem Portal arbeiten und eines davon enthält die Lokalisierung in Portaleigenschaften, Webinhalten und sogar Hardcode. Trotzdem ist die Geschichte weit darüber hinaus, eine harte Nuss zu knacken, sie wurde vergangene Woche nicht geliefert. Wir haben in der Vergangenheit die gleichen Lokalisierungsgeschichten und kennen alle Unterwasserfelsen.
Das ist keine User Story; das ist eine vollständig integrierte Feature-Anfrage. Das Äquivalent wäre „Als Englischsprecher möchte ich Amazon ganz auf Englisch sehen“. Das ist keine User-Story. Auch „eine bessere Benutzererfahrung“ ist kein Geschäftsergebnis.
Ich würde vorschlagen, zu den Grundprinzipien zurückzukehren und die Patterns for Splitting User Stories zu studieren, die sich hier befinden. agileforall.com/2012/01/new-story-splitting-resource
@Venture2099 Wie, denkst du, sollte die Geschichte in meinem Fall aussehen? Im Grunde enthält es alle 3 User-Story-Komponenten. Wer? Was? Warum? Warum ist eine bessere Erfahrung kein Geschäftsergebnis? Zum Beispiel können Sie sagen, dass die Steigerung von Conversion/Verkäufen/SEORanking das Geschäftsergebnis ist. Aber in diesem Fall können wir das nicht anwenden, da das Produkt einzigartig und hochspezifisch ist, also ein 100%-Monopol auf einem Markt hat und auf seinem spezifischen Markt auf der ganzen Welt sehr bekannt ist. Und Benutzer aus Frankreich sind gezwungen, die englische Version zu verwenden. Übrigens danke für die coole Splitting-Anleitung!
Auch das von uns entwickelte Produkt enthält einige Mechanismen und Architekturen für die Lokalisierung und wir haben bereits 2 Sprachen.
Eine bessere Benutzererfahrung ist keine geschäftliche Wertaussage. Es ist eine subjektive Meinung über die Umsetzung. Ist Twitters Wechsel zu Hearts from Stars eine bessere Benutzererfahrung? Ich bin mir sicher, dass jemand so gedacht hat, aber es ist keine Geschäftswertaussage, die in eine User Story gehört. Die Geschäftswertaussage besteht darin, etwas erreichen zu können. Als BENUTZER des Portals von Alexander Averchenko möchte ich die Homepage auf Französisch sehen können, damit ich die richtige Menüoption auswählen kann. [1 Benutzergeschichte].
Die Sammlung von User Stories, die für eine vollständige Sprachübersetzung erforderlich sind, bilden das Epic.

Antworten (5)

Sie verwenden den Begriff Geschwindigkeit auf eine seltsame Weise. Die Velocity ist der Aufwand, den ein Team in die Entwicklung von Stories pro Sprint stecken kann. Es wird normalerweise in Story Points gemessen. Der Durchschnitt der Velocity dient der Release-Planung oder als Orientierungshilfe beim Sprint-Planning, wie viel Arbeit in einem Sprint erledigt werden kann.

Es klingt eher so, als ob Sie über eine Art Burndown-Diagramm sprechen. Hier ist es wichtig zu unterscheiden, ob es sich um ein Aufgaben-Burndown-Diagramm oder ein Story-Burndown-Diagramm handelt.

Wenn die Geschwindigkeit negativ wird oder sich dramatisch verlangsamt , bedeutet dies wahrscheinlich, dass das Burndown-Diagramm eher nach oben als nach unten geht. Wenn das der Fall ist, sprechen zwei Dinge dafür:

  • Sie haben den Arbeitsaufwand zunächst unterschätzt
  • Es gibt Hindernisse, die es unmöglich machen, die Arbeit zu erledigen
@Alexander Averchenko könnten Sie bitte überprüfen, was Sie meinen, wenn Sie davon sprechen, dass a) Geschwindigkeit und b) Geschwindigkeit negativ werden.
Danke für das Theorie-Update, "negativ" ist eine Übertreibung. Wir verwenden kleine Geschichten, um ein tägliches Burndown-Update zu haben. So kann ich sehen, wie viele Storys täglich geschlossen werden, um zusätzlich zu den täglichen Meetings eine doppelte Quelle für Projektgesundheitsinformationen zu haben.
Ehrlich gesagt würde ich mir keine Gedanken über den „täglichen Burndown“ machen und das Team auf einen symbolischen Sieg konzentrieren – da ein funktionsübergreifendes Team es dazu bringt, eine ganze Geschichte in die Spalte „Fertig“ zu verschieben, bevor es irgendetwas anderes tut.

Es gibt nur noch wenige triviale Geschichten/Bugs, aber sie haben außerordentliche Anstrengungen gekostet, um sie zu beenden. Team scheint nicht erschöpft zu sein. Dies ist aber immer gefährdet und verschiebt den Liefertermin.

und

Team versteht, dass es ein Problem gibt. Aber denkt, es ist eine natürliche Ordnung der Dinge und kennt die eigentliche Ursache nicht und zieht es vor, die Dinge so zu lassen, wie sie sind.

Ist Ihr Team zufällig voller Persönlichkeiten, die auf Termindruck angewiesen sind und/oder davon leben, um Dinge zu erledigen?

Es klingt nicht so, als stimmen sie darin überein, dass es ein Problem gibt. Ein „Problem“ ist mit der „natürlichen Ordnung der Dinge“ nicht wirklich vereinbar.

Die einzigen Prozesslösungen, die mir einfallen, wurden bereits erwähnt: interne Deadline, strenges WIP-Limit, sequentielle Story-Lieferung (mein Team nennt diese „Sub-Sprints“).

Aber es hört sich so an, als hätten Sie wirklich ein Motivationsproblem, und dass gefährdete und verspätete Lieferungen ein Problem für Sie sind , aber nicht für sie . Wie können Sie sie also dazu bringen, sich zu kümmern? Erleben sie negative Folgen für verspätete Lieferungen? Können Sie Prämien für pünktliche oder verfrühte Lieferungen anbieten? Können Sie auf das Risiko für den Ruf des Teams im oberen Management hinweisen (oder jemanden darauf hinweisen lassen?), wenn dies ihr Muster ist?

Terminologie Hauswirtschaft

Die Geschwindigkeit sollte als Maß für das Softwareinkrement „Fertig“ verstanden werden, das das Entwicklungsteam produziert. Dies liegt daran, dass es um Welten wichtiger ist, dies zu messen als die "Geschwindigkeit" der Aufgabe, des Workflow-Schritts usw.

Jetzt, wo wir über „Fertig“ sprechen, dh Definition von „Fertig“ in Scrum, lassen Sie uns darüber sprechen, wie das Risiko verringert werden kann, dass Dinge am Ende des Sprints nicht „Fertig“ werden. Zusamenfassend:

Zerlegen Sie große Teile rücksichtslos in kleinere Teile

Der Scrum-Leitfaden beinhaltet Bemühungen in den vier Aspekten jedes Product-Backlog-Eintrags. Die Größe der Arbeit hängt mit dieser Maßnahme zusammen. Ich habe einen Zusammenhang zwischen riskanter und großer Arbeit festgestellt. Um die Wahrscheinlichkeit zu verringern, dass Arbeit nicht „erledigt“ wird, unterteilen Sie die Arbeit an der Spitze des Rückstands ständig in immer kleinere Teile. Ich mag diesen Artikel sehr für gute Dekompositionstechniken

Erhalten Sie kleinere Dinge schneller "erledigt".

Machen Sie Product Backlog Items klein und wertvoll (sehen Sie auch die INVEST-Kriterien nach, um mehr Hilfe beim Erstellen von PBIs zu erhalten).

Konzentrieren Sie sich wahnsinnig darauf, kleine Dinge schnell zu erledigen, bevor Sie zu neuen übergehen, dh halten Sie die Arbeitseinheiten klein und begrenzen Sie rücksichtslos den WIP, bis der optimale WIP beobachtet werden kann. Sehen Sie sich dieses Video an, um besser zu verstehen, wie ein optimaler WIP aussieht:

https://www.youtube.com/watch?v=W92wG-HW8gg

Was bewirkt das?

Das Risiko für jedes Softwareinkrement wird angegangen und lange vor dem Ende des Sprints eliminiert. Daher wird das am Ende des Sprints auftretende Risiko reduziert und die Prognosen des Entwicklungsteams werden genauer.

Wenn ich „fast am Ende eines Sprints“ lese, bedeutet das, dass Ihre Sprints zu lang sind. Du musst deine Sprints verkürzen. Das ist die Hauptsache, auf die Sie sich konzentrieren müssen. Sie haben die Antwort in Ihrer Frage.

Sie haben ziemlich klar erklärt, was passiert und welche Maßnahmen Sie ergriffen haben, um die Probleme zu lösen, aber uns fehlt irgendwie, warum dies passiert, daher ist es schwierig, darauf eine Antwort zu geben.

Haben Sie dazu einen Einblick? Haben Sie versucht, das Problem während der Retrospektive anzugehen? Was ist Ihre Rolle in dem Prozess?

-- Aktualisierung basierend auf diesem Kommentar --

Team versteht, dass es ein Problem gibt. Aber denkt, es ist eine natürliche Ordnung der Dinge und kennt die eigentliche Ursache nicht und zieht es vor, die Dinge so zu lassen, wie sie sind

Ich könnte mich irren, und mir fehlt wahrscheinlich etwas (zum Beispiel ist es immer noch nicht klar, was Ihre Rolle ist, ich nehme an, Sie sind der Scrum Master), aber was ich in diesem Fall tun würde, ist:

  1. Beteiligen Sie das Team an einer Diskussion über das Problem und bringen Sie gegebenenfalls einige Interessenvertreter ein, um ihren Standpunkt einzubringen. Wenn das Problem besteht, sollte es angegangen werden, unabhängig davon, ob sie dies für wichtig halten oder nicht
  2. Versuchen Sie, einige Maßnahmen zu ergreifen, damit das Team jede Geschichte nacheinander liefern kann. Dies kann kurzfristig zu einem noch schlimmeren Szenario führen, aber zumindest ermöglicht es Ihnen, besser zu verstehen, wo das Problem liegt, und geeignete Maßnahmen zu ergreifen

Auf jeden Fall würde ich an der Kommunikation arbeiten, damit alle Beteiligten ein gemeinsames Verständnis der Situation haben.

Ich schätze, wenn ich wüsste, warum, würde ich nicht hierher gehen, um zu fragen. Ich bin praktischer PM/SM. Retrospektiven ergaben nichts zu diesem Thema.
Können Sie erläutern, was "nichts gegeben" bedeutet? Sieht das Team das Problem, kann aber nicht verstehen warum oder wird es gar nicht als Problem wahrgenommen? Die Sache ist die, dass der Versuch, eine Lösung zu finden, ohne auch nur das geringste Wissen darüber zu haben, warum dies geschieht, wie in die Luft zu schießen, in der Hoffnung, dass ein Vogel den Weg der Kugel kreuzt. Und selbst wenn Sie eine Lösung finden, werden Sie nicht verstehen können, warum sie funktioniert ...
Es bedeutet, dass das Team versteht, dass es ein Problem gibt. Aber denkt, es ist eine natürliche Ordnung der Dinge und kennt die eigentliche Ursache nicht und zieht es vor, die Dinge so zu lassen, wie sie sind. Noch einmal, wenn ich wüsste, warum es passiert, könnte ich eine Lösung finden. Deshalb bin ich hierher gekommen, um Menschen zu fragen, die in einer ähnlichen Situation waren, und eine Ursache zu finden.
Das ist schon etwas, ich werde meine Antwort darauf basierend aktualisieren. :)
Die Teamgeschwindigkeit verlangsamt sich dramatisch zum Ende eines Sprints
AntwortenHierDatenschutz-Bestimmungen1y, 0v