Sollte sich die Diskussion darüber, was gestern getan wurde, in einem Scrum-Standup auf Aufgaben im Vorstand oder auf alle geleisteten Arbeiten beschränken?

Ich weiß, dass die Scrum-Regeln in täglichen Stand-ups besagen, dass das Team nur darüber sprechen sollte, was sie gestern getan haben, was sie heute tun und was sie blockiert. Nichts anderes. Das Problem ist jedoch, dass Entwickler manchmal ihren Tag mit Arbeiten verbringen, die für ihre Aufgaben irrelevant sind, und dann im Stand-up darüber sprechen. Das haben sie gestern gemacht!

Nach meiner Erfahrung ist es effektiver, über Aufgaben an der Tafel zu sprechen, den Stand-up-Fokus zu behalten und den Fokus aller auf ihre Aufgaben zu richten, ihre Schätzungen zu überprüfen und ihre Aufzeichnungen täglich zu verfolgen.

Ist es gültig, die Diskussion auf die Aufgaben an der Tafel zu beschränken?

agile scrum meetings

— Shadin
quelle

Dass Entwickler ganze Tage damit verbringen, nicht an ihren Aufgaben zu arbeiten, könnte ein Problem sein, das unsichtbar wäre, wenn es nicht erwähnt würde?

— RemcoGerlich

Alle reden 30 Sekunden, um zu sagen, was sie vorher getan haben. Wie viel fokussierter willst du es? Sie überprüfen keine Schätzungen. Sie verfolgen Aufgaben, wenn Sie sie an den nächsten Mitarbeiter (Prüfer oder Tester) weitergeben.

— Gnasher729

Antworten:

Gemäß dem Inhalt des Scrum-Leitfadens für tägliche Stand-ups stehen drei Fragen zur Diskussion:

Was habe ich gestern getan, um dem Entwicklungsteam zu helfen, das Sprint-Ziel zu erreichen?

Was werde ich heute tun, um dem Entwicklungsteam zu helfen, das Sprint-Ziel zu erreichen?

Sehe ich ein Hindernis, das mich oder das Entwicklungsteam daran hindert, das Sprint-Ziel zu erreichen?

Alle Fragen konzentrieren sich auf das Sprint-Ziel, nicht auf die Aufgaben, die auf dem Brett stehen. Gemäß dem Scrum-Handbuch wird das Sprint-Ziel in der Sprint-Planung erstellt und definiert "ein Ziel, das innerhalb des Sprints durch die Implementierung des Product Backlog erreicht wird, und gibt dem Entwicklungsteam eine Anleitung, warum es das erstellt Zuwachs".

Alles, was Ihr Entwicklungsteam tut, sollte im Idealfall dazu beitragen, dass das Team das Sprint-Ziel erreicht. Dies können ungeplante Aktivitäten sein, die nicht auf dem Brett ausgeführt werden müssen, oder Dinge auf einer niedrigeren Ebene, die möglicherweise berücksichtigt und geschätzt wurden, aber auf einer niedrigeren Ebene als ein Element auf dem Brett.

Ich würde sagen, lassen Sie Ihr Team über alles sprechen, was sie gestern getan haben. Wenn sie über Dinge sprechen, die dem Team nicht helfen, das Sprint-Ziel zu erreichen, sollte jemand dies ansprechen, insbesondere wenn andere Dinge, die sie hätten tun können, das Team näher an das Erreichen des Sprint-Ziels gebracht haben.

Eine Ausnahme kann sein, wenn eine Person mehrere Scrum-Teams unterstützt. In der Besprechung sollten sie wahrscheinlich nicht über alles sprechen, was sie gestern getan haben, sondern darüber, was sie zur Unterstützung des Teams getan haben, das derzeit den Standup hat.

Die Sprint-Retrospektive ist eine großartige Zeit, um mit dem Team über dieses Problem zu sprechen. Es gibt viele Fragen zu berücksichtigen:

Ist das Team in Bezug auf das Sprint-Ziel unterfordert?
Gibt es zu viel ungeplante Arbeit?
Woher kommt die ungeplante Arbeit und wer genehmigt sie?
Warum arbeiten Leute an Dingen, die nicht im Vorstand sind?
Sollten wir mehr Details an der Tafel anzeigen, um die Dinge, die Sie tun, leichter mit Gegenständen an der Tafel zu verknüpfen?

— Thomas Owens
quelle

Das Problem mit "Sprint Goal" ist zu vage und wunschgemäß. in der Praxis Sprint Goal == erledige die Aufgaben an der Tafel. Wenn das, woran Sie gearbeitet haben, dort nicht ist, sollte es entweder sein oder Sie sollten nicht daran arbeiten

— Ewan

@Ewan Ein Kunde ruft an und teilt uns mit, dass die Live-Software abgestürzt ist und wir ein Protokoll und einen Fehlerbericht haben. Es ist wichtig, sich die Zeit zu nehmen, um diesen Bericht sofort zu durchsuchen, auch wenn er gerade nicht im Vorstand ist. Es kann in den Geltungsbereich gebracht oder in den Rückstand aufgenommen werden, aber ich habe es gestern getan und könnte der Grund sein, warum ich Bob erst nach dem Mittagessen bei seinem Problem helfen konnte. Ich sollte diese Aufgabe nicht blind erledigen, aber wahrscheinlich wird niemand sie auf das Brett legen, es sei denn, sie wird in diesen Sprint gezogen. Ich kann mir auch andere Beispiele vorstellen.

— Thomas Owens

Sie sollten ein Ticket "Triage Live Bug" zum Board hinzufügen und es als erledigt markieren. Dann kann man am Ende des Sprints sicher sagen. Bei diesem Sprint haben wir X Stunden damit verbracht, Benutzerfehler zu untersuchen. Deshalb sind wir zu spät. Wir müssen den Helpdesk besser trainieren. "Sonst wird der Sprint nicht erledigt, und der Premierminister hat nur Hörensagen-Ausreden vom Team." Oh, diese Woche gab es eine Menge Fehler zu sehen! Achselzucken '

— Ewan

@Ewan Ich denke das ist unglaublich unnötig. Ich möchte meinen Tag nicht damit verbringen, Tickets zu schreiben. Ein Prozess muss es mir ermöglichen, meine Arbeit zu erledigen, und 90 Minuten für die Triage anstatt 95 Minuten für die Triage zu benötigen und dann ein Ticket einzureichen, das besagt, dass ich ein Ticket ausprobiert habe, ist dumm. Vor allem, wenn Sie mehrere Tickets durchsuchen müssen. Sie brauchen keine Tickets, um die Dinge in der Retrospektive zu besprechen. Wenn Sie elektronische Tools verwenden, können Sie Tickets finden, die vom Team im Sprint geändert wurden, um zu sehen, ob es viele Dinge zu prüfen gab - kein Hörensagen.

— Thomas Owens

Die Ebene der Berichterstattung bis zu Ihrem Scrummaster / PM / Unternehmen. Sie könnten einfach ein "Trigaing Bugs" -Ticket schreiben, um Ihre gesamte Arbeit für den Tag abzudecken. Aber das Wichtigste ist, dass Sie es als Teil des Sprints aufnehmen. Nehmen Sie nicht an, dass es nur von einer anderen Metrik berücksichtigt wird

— Ewan

Nein, du solltest darüber reden, was du gestern getan hast.

Wenn es nicht auf dem Board ist, müssen Sie einen der folgenden Schritte ausführen:

lege es auf die Tafel,
Hör auf damit
oder Teams wechseln.

Die häufigste Methode, beispielsweise für ungeplante Notfallarbeiten, besteht darin, eine Karte aufzuschreiben und auf die Tafel zu kleben. Dies stellt sicher, dass Sie am Ende des Sprints die Geschwindigkeit messen und erklären können, warum die Sprintziele nicht erreicht wurden.

Ein Teammitglied, das an Dingen arbeitet, die nicht im Sprint sind, ist meiner Ansicht nach einer der Hauptgründe für das Scheitern agiler Adoptionen. Am häufigsten wird ein Entwickler umgeleitet, um Live-Probleme bei einem anderen Projekt zu beheben.

Eine andere nervige Sache bei Sprints ist "PM spricht über Meetings für andere Projekte". Meiner Ansicht nach ist der PM nicht Teil des Scrum-Teams, er besetzt die Scrum-Rolle des "Product Owner" und ist daher dazu da, Fragen zu beantworten und keine Fortschritte zu melden.

— Ewan
quelle

Es gibt so etwas wie ungeplante Arbeit - Arbeit, die erledigt werden muss, um jemanden zu entsperren oder andere Aufgaben zu erledigen, die sich auf dem Board befinden, aber nicht auf dem Board. Oft ist es schneller, es einfach zu tun, als es auf die Tafel zu legen. Es ist Sache des Teams, zu besprechen, wie damit umzugehen ist. Mein aktuelles Team hat Regeln - alles, was in einer Produktions- oder QS-Umgebung bereitgestellt wird, oder Aufgaben, die 2 Stunden dauern, werden an Bord gebracht. Es müssen immer noch manchmal kürzere Aufgaben erledigt werden, über die gesprochen wird, die das Board jedoch nicht erstellen, da es nicht den Kriterien entspricht.

— Thomas Owens

@Ewan, kannst du das bitte erweitern? Wer kümmert sich um die Behebung von Live-Fehlern, wenn diese nicht im Sprint enthalten sind? Wie kann der Projektinhaber gleichzeitig Projektmanager sein? (Ich meine, wer ist er oder jongliert er beide Rollen)

— Dennis

aus Gründen der Klarheit bearbeitet

— Ewan

@ Tennis: Projektmanager ist keine Scrum-Rolle.

— RemcoGerlich

@Ewan, danke. Dies ist für die Antwort nicht wesentlich, aber ich bin neugierig - der "PM spricht über Treffen für andere Projekte", wie funktioniert das? Kommen PMs zu einem Meeting über Projekt X, sprechen aber über Y? Es fällt mir schwer, mir das vorzustellen. Wie / warum ist das möglich? Meinen Sie damit, dass sie hereinkommen und im Wesentlichen anfangen zu klatschen oder vom Thema abzukommen, oder gibt es einen tieferen Grund für sie, über nicht unmittelbare treffensspezifische Ziele / Bedürfnisse zu sprechen? Ich würde sagen "Hey, schön das zu hören, aber ich bin kein Teil von Projekt Y ... keine Kenntnisse / Erfahrungen dort, können wir zu X zurückkehren?"

— Dennis