Ist es eine gute Sache, wenn mein Scrum-Team immer 100 % seiner zugesagten Aufgaben erledigt? Angesichts der großen Variabilität in der Softwareentwicklung scheint dies darauf hinzudeuten, dass etwas faul ist, aber die vorherrschende Philosophie scheint zu sein, dass etwas faul ist, wenn sie nicht immer 100 % des zugesagten Umfangs abschließen.
Wenn Sie der Meinung sind, dass es in Ordnung ist, nicht in jedem Sprint 100 % des zugesagten Umfangs zu erfüllen, wie viel Prozent der Zeit würden Sie erwarten, dass sie falsch liegen, und wie weit würden Sie davon ausgehen, dass sie falsch liegen, bevor Sie denken, dass es ein Problem gibt, das behoben werden muss direkt angesprochen?
Das Ziel von Scrum ist es wirklich, Vertrauen aufzubauen, indem zuverlässig und nachhaltig potenziell lieferbare Wertzuwächse geliefert werden. Wenn Ihr Prozess dies bereits tut, unterbrechen Sie ihn nicht. Wenn dies nicht der Fall ist, sind kontinuierliche Verbesserungen und Inspektionen und Anpassungen sicherlich angebracht.
Bei Scrum ist das Ziel nicht 100 % Auslastung, sondern nachhaltiges Pacing und angemessene Genauigkeit, wozu auch gehört, sicherzustellen, dass das Team seine Arbeit nicht falsch einschätzt oder sich routinemäßig zu Aufgaben verpflichtet, die es nicht innerhalb einer einzigen Iteration erledigen kann. Daher ist es großartig , regelmäßig 100 % des zugesicherten Umfangs zu absolvieren .
Was Sie wirklich fragen, ist etwas anderes. Die versteckte Frage scheint zu sein: "Wenn mein Team immer 100 % des vereinbarten Umfangs liefert, bedeutet das, dass es nicht beschäftigt genug ist?" Mit anderen Worten, Sie fragen, ob sie im Prozess zu viel Puffer haben und ob sie sich bei jeder Iteration mehr Arbeit widmen sollten.
Vielleicht.
Das ist gutes Futter für eine Retrospektive. Wenn das Team alle zugesagten Aufgaben zur Hälfte der Iteration erledigt, schätzt es wahrscheinlich falsch ein oder akzeptiert nicht genügend Story Points für den Sprint. Wenn sie jedoch routinemäßig alle Aufgaben erledigen, zu denen sie sich verpflichten, genügend Spielraum haben, um sicherzustellen, dass sie mit Abweichungen und Hindernissen umgehen können, und nicht so hart „sprinten“, dass sie ausbrennen, dann ist es nicht unbedingt notwendig, mehr Arbeit zu vergießen konstruktiv.
Anstatt zu fragen, ob Ihr Team nicht ausgelastet ist, könnten folgende Fragen besser gestellt werden:
Denken Sie daran, mit einer Analyse der Hauptprämisse zu beginnen. In diesem Fall bedeutet das, sich zu fragen, warum die Einhaltung von 100 % der Verpflichtungen nicht als eine gute Sache angesehen wird. Es kann legitime Gründe geben, warum dies nicht gut genug ist, aber stellen Sie sicher, dass Sie (und das Team) verstehen, was diese Gründe sind, damit das Team als Ganzes die zugrunde liegenden organisatorischen und Prozessprobleme angehen kann.
Wenn das Team die aktuellen Anforderungen des Unternehmens erfüllt und das Team glücklich und produktiv ist, würde ich nicht empfehlen, am Erfolg herumzuspielen. Wenn andererseits der Prozess die Unternehmensziele nicht erfüllt oder Vertrauensprobleme zwischen dem Team und der größeren Organisation bestehen, dann ist dies definitiv eine Diskussion, die geführt werden muss.
Es hängt davon ab, ob; Ziehen sie nach Abschluss des ursprünglichen Sprint-Backlogs immer mehr und erledigen unerwartete Aufgaben? Dadurch entsteht ein charakteristisches Sägezahnmuster am Ende des Burndown-Diagramms, das die Signatur von Teams ist, die die Extrameile gehen. Ziehen sie nach Abschluss der gesamten Arbeit in Sprints im nächsten Sprint mehr Arbeit, um ihre Kapazität auszunutzen? Teams, die dies regelmäßig tun, sind auf dem Weg zu immer höheren Leistungen. Wenn ihre Geschwindigkeit jedoch flach ist und ihr Burndown am oder vor dem Ende des Sprints endet, würde das den Fischgeruch erklären. Teams, die dies tun, fühlen sich normalerweise von den Verantwortlichen unter Druck gesetzt, ihre Sprintarbeit immer abzuschließen. Sie reagieren darauf, indem sie sehr darauf achten, sich nicht selbst herauszufordern, also erneuern, lernen oder verbessern sie nicht so viel, wie sie könnten. ICH' Ich bin mir nicht sicher, wie viel Variabilität "erwartet" wird, aber sicherlich einige. In ähnlicher Weise lässt sich „zu viel“ möglicherweise nicht allgemein angeben, achten Sie also unbedingt auf das Feedback von PO, Kunden und Stakeholdern, die betroffen sein werden.
Das Entwicklungsteam hat zwei Hauptaufgaben. Die erste besteht darin, einen geschäftlichen Nutzen auf einem für die Organisation angemessenen Maß an technischer Qualität zu liefern. Die zweite besteht darin, nach Bereichen zu suchen, in denen es verbessert werden kann.
Beide Aufgaben erfordern, dass das Team Zeit darüber nachdenkt, was es tut. Sie müssen möglicherweise neue Technologien erforschen, über ihr Design/ihre Architektur sprechen und ihren Ansatz kontinuierlich überprüfen. Wenn ein Team die Arbeit so einpackt, dass es häufig bis zum Ende des Sprints auf Hochtouren arbeitet, wird es wenig Zeit für Selbstbeobachtung und Verbesserung haben. Mit anderen Worten, etwas Flaute ist eine gute Sache.
Natürlich muss ein Gleichgewicht hergestellt werden. Ein professionelles Scrum-Team wird sich bemühen, das richtige Gleichgewicht zwischen Lieferung und Selbstverbesserung zu finden. Passen Sie ihre Herangehensweise kontinuierlich an die Umstände an.
100% Abschluss von engagierten User Stories ist ok, aber wie von CodeGnome gesagt ein guter Punkt für die nächste Retrospektive. Vielleicht ist Ihr Team zu defensiv und könnte in einem Sprint noch mehr erreichen.
Warum sind 100 % in Ordnung? Was Sie wollen, ist ein Team, das die Geschichten (aus der Sicht der Product Owner) versteht und ihre Komplexität in Story Points einschätzt. Nach einigen Sprints sollte sich der Burndown stabilisieren und die „üblichen“ Punkte pro Sprint bekannt sein. Das ist eine tolle Sache, wenn der Product Owner das Backlog priorisiert.
Es ist auch ok, wenn nicht alle zugesagten Punkte (immer) erreicht werden konnten. Das Team sollte die Ursache für das Problem in der Retrospektive finden, um zu ~100 % zurückzukehren. Ich kann nicht sagen, wie groß die Abweichung sein darf - aber gehen Sie für "klein".
Es ist die intrinsische Absicht des Teams, nicht faul zu sein. Ist dem Team das Scrum-Verständnis des Teams nicht vertraut, sollte der Scrum Master die Idee transportieren und an einer positiven Atmosphäre arbeiten.
Andreas Klar