Unsere Sprint-Planungsmeetings machen nicht nur keinen Spaß, sie sind geradezu schrecklich.

Die Treffen sind langweilig und langweilig und dauern ewig (ein Tag, aber es fühlt sich viel länger an).
Die Entwickler beschweren sich darüber und fürchten anstehende Planungen.

Unsere Routine ist ziemlich normal (User Story wird nach Priorität in das Sprint-Backlog eingefügt >> Story wird in Aufgaben zerlegt >> Aufgaben werden in Stunden >> Wiederholung geschätzt), und ich kann nicht herausfinden, was wir falsch machen.

Wie können wir die Treffen angenehmer gestalten?

...

Einige weitere Details als Antwort auf Anfragen nach weiteren Informationen:

Warum werden die Rückstandselemente vor dem Sprintstart nicht eingefügt und priorisiert?

User Stories haben in der Tat Priorität. Wir haben keine Ahnung, wie lange sie dauern werden, bis wir sie in Aufgaben aufteilen! Aus den (ausgezeichneten) Antworten hier geht hervor, dass wir vielleicht überhaupt keine Aufgaben schätzen sollten, sondern nur die User Stories. Der Grund, warum wir Aufgaben (und nicht Geschichten) schätzen, ist, dass wir schrecklich falsche Schätzungen für Geschichten erhalten haben - aber ich denke, das ist das Thema für eine ganz andere Frage.

Warum beschweren sich Entwickler?

1. Sitzungen sind lang.

2. Sitzungen sind eintönig. Geschichte für Geschichte, Aufgabe für Aufgabe, Probleme (ja, Probleme), um abzuschätzen, wie lange es dauern wird und was es bedeutet.

3. Das Abschätzen von Aufgaben macht das Abschätzen von User Storys sinnlos.

4. Je länger die Besprechung dauert, desto weniger ist der Fokus im Raum. Je weniger fokussierte Kollegen sind, desto länger dauert die Besprechung. Es entsteht eine rekursive Hassspirale. Wir haben darüber nachgedacht, das Meeting in zwei Tage zu unterteilen, um die Aufmerksamkeit der Leute zu erhalten, aber die Entwickler würden nichts davon hören. Ein Planungstag ist schon schlimm genug; Jetzt haben wir zwei ?!

Ein Teil unseres Problems ist, dass wir auf sehr kleine Details eingehen (um genauere Schätzungen zu erhalten). Aber wenn wir grob einschätzen, gehen wir weit über das Ziel hinaus!

Um die Frage zusammenzufassen:

• Was machen wir falsch?

• Welche zusätzlichen Möglichkeiten gibt es, um das Meeting allgemein angenehmer zu gestalten?

Erleichtern Sie die Schätzung

Unterbrechen Sie Ihre Sprintplanung.

Haben Sie müssen die einzelnen Aufgaben schätzen? Ich habe die Sprintplanung auf zwei Arten durchgeführt:

1. Geschichten werden in Handlungspunkten und Aufgaben in Stunden geschätzt
2. Geschichten werden in Handlungspunkten geschätzt und Aufgaben fallen einfach ohne Schätzung darunter

Von den beiden bevorzuge ich die zweite Option. Ich stelle fest, dass das Nichteinschätzen von Aufgaben Entwicklern mehr Freiheit gibt, mit Änderungen umzugehen. Wenn eine Aufgabe keinen Sinn mehr ergibt (wie oft haben Sie herausgefunden, dass eine Aufgabe nicht anwendbar ist oder bereits in einem früheren Sprint ausgeführt wurde), werfen Sie sie einfach ohne Abzug aus dem Spiel oder müssen eine aktuelle Aufgabe in ändern etwas Neues, das es möglicherweise kaputt macht. Sie sind wirklich überflüssig, wenn Sie beide schätzen, da die Summe der Aufgaben die Story-Punkte darstellen sollte und umgekehrt. Welchen Mehrwert erzielen Sie wirklich, wenn Sie nicht wissen, wie viel Zeit einzelne Aufgaben in Anspruch nehmen werden? Wenn Sie mit Aufgabengrößen konfrontiert sind, die sich wirklich stark voneinander unterscheiden, würde ich vorschlagen, diese Aufgaben in kleinere, homogenere Abschnitte aufzuteilen.

Auf diese Weise können Sie die Zeit für die Sprintplanung verkürzen . Geschichten werden während der Sprint-Planung geschätzt, und wenn Sie den Sprint starten, können Sie alle Aufgaben aufschreiben, die Sie sich vorstellen können. Wenn Sie beim Abschätzen der Story auf Punkte stoßen, von denen Sie wissen , dass sie in einer Aufgabe behandelt werden müssen, können Sie diese natürlich zu den Story-Informationen hinzufügen und als Aufgabe definieren.

Schätzung in idealen Einheiten

Story Points sollen sich in idealen Einheiten wie idealen Arbeitsstunden oder idealen Arbeitstagen befinden. Dies bedeutet, dass Sie die Aufgabe an jedem perfekten Tag, an dem Sie keine Unterbrechungen und keine Besprechungen hatten und alles nach Plan lief, in X Tagen erledigen können. Jetzt weiß jeder, dass das einfach nicht stimmt, aber das Wunderbare an Statistiken ist, dass es nicht so sein muss.

Was ich damit meine, ist, dass Sie nach einer Weile, nachdem Sie diese in idealen Tagen geschätzt haben, feststellen, dass es möglicherweise zusätzliche 25% der von Ihnen geschätzten Zeit in Anspruch nimmt, um eine Geschichte fertigzustellen. Nehmen wir an, Sie hätten 4 ideale Arbeitstage veranschlagt, und stattdessen haben Sie 5 Tage gebraucht. Mit der Zeit behalten Sie dies im Auge und haben dann eine ungefähre Vorstellung von der Umstellung von idealen Tagen auf reale Tage. Ihr erster Instinkt wäre, zu versuchen, dies durch Überbewertung zu kompensieren, und Sie würden sich wahrscheinlich irren. Die Hauptsache hier ist, konsequent zu bleiben. Auf diese Weise bleibt Ihr langfristiger Durchschnitt gleich. Sicher, manchmal ist es unter und manchmal ist es vorbei, aber je mehr Sie schätzen, desto besser geht es Ihnen. Wenn du das findest du immer noch Ich kann keine annehmbare Schätzung erhalten. Vielleicht bedeutet das, dass Sie nicht genug über die Geschichte wissen, um sie richtig zu schätzen.

Sprechen Sie über die Geschichten

Wenn Sie einschätzen, sollte jeder eine ungefähre Vorstellung davon haben, was von Anfang bis Ende getan werden muss, damit diese Geschichte vollständig ist. Sie müssen nicht jedes Detail kennen, aber genug, dass Sie denken, Sie könnten die Geschichte selbst übernehmen. Wenn Sie dieses Maß an Vertrauen nicht haben, sollten Sie es wahrscheinlich nicht einschätzen. Wenn Sie sagen "Nun, diese Geschichte ist zu groß, um die meisten Details zu kennen", ist das ein Hinweis darauf, dass die Geschichte zu groß ist und aufgeschlüsselt werden sollte. Zumindest nach meiner Erfahrung waren die Geschichten so klein, dass eine Person, wenn nötig, alleine daran arbeiten und es innerhalb von ein oder zwei Wochen fertigstellen konnte.

Dies wird auch dazu beitragen, Ihren zweiten Punkt in der Bearbeitung zu lösen, was zu viel Schätzung ist . Anstatt jede einzelne Aufgabe für jede einzelne Story zu schätzen, schätzen Sie einfach die Story als Ganzes, was helfen sollte, einen Großteil der Schätzung zu entfernen. Um die Meetings weniger eintönig zu gestalten, würde ich empfehlen, Poker zu planen. Weitere Informationen hierzu finden Sie weiter oben.

Machen Sie die Planung spannender

Schätzen Sie mit Planning Poker

Haben Sie versucht , Poker zu planen , um das Schätzen unterhaltsamer zu machen ? Auf diese Weise habe ich immer alle meine Sprints in mehreren Teams geplant und es ist eine gute Möglichkeit, alle Beteiligten zu halten, da sich jeder zumindest für ETWAS entscheiden muss. Es macht auch eine Menge Spaß, wenn jeder im Team 3 wählt und jemand eine 20 drückt und sich erklären muss, oder wenn jeder im Team eine 5 drückt, aber der Manager eine 8 drückt (mit wem wird man streiten?) der Chef, wenn er Ihnen mehr Zeit geben will!).

Dazu benötigen Sie lediglich einige Planungspokerkarten , die wir häufig auf der Rückseite von Karteikarten erstellen, oder normale Spielkarten mit Werten, die an Bildkarten angehängt sind. Nichts Besonderes, und es hält alle konzentriert. Denken Sie daran, dass der Versuch, eine Aufgabe für einen ganzen Tag zu erledigen (einschließlich der Planung von Poker), die Produktivität beeinträchtigt. Viele Kartensätze werden aus einem bestimmten Grund mit einer Kaffeekarte geliefert. Wenn sich jemand ausgebrannt fühlt, gib dem Team eine Pause zum Aufladen und nimm sie, wenn alle frisch sind!

Alternativ zu physischen Karten können Sie sich auch elektronische Karten ansehen . Der eigentliche Vorteil hierbei ist die automatische Verfolgung der Ergebnisse, die Verfolgung der zu schätzenden User Stories und die Möglichkeit, dass jeder seine Karten auf einmal zeigt, um "Betrug" zu vermeiden (wenn die Schätzung einer Person durch die einer anderen Person beeinflusst wird, weil sie ihre Karte sehen kann). Dies setzt natürlich voraus, dass jeder über einen Computer verfügt und sich auf die jeweilige Aufgabe konzentrieren kann. Verwenden Sie ihn also nach eigenem Ermessen.

1. Warum werden die Rückstandselemente vor dem Sprintstart nicht eingefügt und priorisiert? Entwicklerzeit zu verschwenden macht keinen Spaß. Lassen Sie Ihre Teamleiter einige Tage im Voraus mit dem Product Owner und Projektmanager zusammenarbeiten, um Prioritäten zu setzen. Dies gilt auch für die Planung, wer zu jedem Sprint-Team gehört.

2. Warum dauert es einen Tag, um Dinge in Aufgaben aufzuteilen? Wenn Sie ein angemessen großes Team haben (2-4 Entwickler, 0,5-1,5 QA-Mitarbeiter pro Entwickler, 1-2 verschiedene), sollten Sie für diesen Sprint 2-4 User Stories haben. Nehmen Sie sich etwa 30 Minuten Zeit, um die Anforderungen des Produktbesitzers zu klären, und verteilen Sie sie dann auf ca. 8 Stunden. Geben Sie die Aufgaben nicht während des Meetings ein. Vereinbaren Sie als Team, welche Aufgaben für gesunde Menschen ausreichen, um sie zu verstehen, wer für sie verantwortlich ist und wie lange sie brauchen sollten. Stimmen Sie zu, dass "wie lange sie brauchen sollten (einschließlich Tests)" bequem in den Sprint passt.

3. Wenn es nicht nur darum geht, Dinge in Aufgaben zu unterteilen, was machst du dann noch? Sicher, Rückblicke können 30-60 Minuten dauern, werden aber kürzer sein, wenn die Teams in einen Groove geraten.

Fazit: Verschwenden Sie keine Zeit mehr, und Sie fürchten die Meetings ein bisschen weniger. Darüber hinaus ist Spaß und Kameradschaft im Team nichts, worauf Sie in Besprechungen eingehen können. Gehen Sie zusammen zum Mittagessen, scherzen Sie, mischen Sie die Leute, um eine bessere Persönlichkeit zu erreichen, haben Sie Wettbewerbe, bei denen der Schnurrbart wächst ... Wenn die Moral einmal hoch ist, werden die Leute die Sprint-Planungsmeetings auf natürliche Weise unbeschwerter gestalten.

Planung ist ein Bereich, in dem Teams viel Flexibilität haben. Probieren Sie jeden Sprint etwas Neues aus, bis Sie auf etwas treffen, das für Ihr Team funktioniert.

Einige erfolgreiche Ideen, die ich entweder persönlich ausprobiert oder von anderen Teams gehört habe:

• Erstellen und priorisieren Sie User Stories ohne das gesamte Team. Der Product Owner und / oder der Scrum Master können einen Großteil der anstrengenden Arbeit erledigen und es einfach dem Team überlassen, diese zu optimieren.
• Machen Sie Ihren Rückstand deutlich länger als ein einzelner Sprint. Es kann eine Weile dauern, bis es aufgebaut ist. Wenn Ihr Rückstand jedoch groß genug ist, müssen Sie bei der Planung von Besprechungen nur noch kleine Änderungen vornehmen oder sich mit den jüngsten Geschäftsentwicklungen befassen.
• Lassen Sie Schätzungsbesprechungen von der Sprintplanung trennen. Wenn die Leute denken, dass die Meetings zu lang sind, gibt es keinen Grund, sie nicht aufzuteilen.
• Insbesondere Plan bricht in die Tagesordnung ein. Dies ist nützlich, wenn Sie häufig darauf warten, dass ein oder zwei Teammitglieder zurückkehren.
• Brechen Sie in der Mitte des Meetings ab und weisen Sie alle an, eine oder zwei User Storys zu erstellen. Treffen Sie sich dann wieder, um Bericht zu erstatten und einen Konsens zu erzielen.
• Stellen Sie sicher, dass es in Ihrem Planungsmeeting darum geht, was zu tun ist, und nicht darum , wie es zu tun ist. Ingenieure fallen sehr leicht in letzteres. Wenn nötig, richten Sie separate Designmeetings ein, in denen Sie das Wie besprechen.
• Teilen Sie Ihre Geschichten in Untersuchung und Implementierung. Die Planung von Besprechungen dauert oft zu lange, wenn die Teammitglieder zu wenig über ihre Arbeit wissen und versuchen, dies während der Besprechung herauszufinden.
  Angenommen, Sie müssen eine API integrieren, mit der Ihr Team keine Erfahrung hat. Anstatt zu versuchen, während des Planungsmeetings Schätzungen und Aufgaben für etwas zu erstellen, über das Sie keine Ahnung haben, schreiben Sie eine Untersuchungsgeschichte, um die API zu lernen, erstellen Sie eine einfache "Hallo Welt" -App und bringen Sie sie dem Team bei. Dann können Sie die eigentliche Arbeit planen.
• Behalten Sie den Überblick bei Ihren Besprechungen zu bestimmten Themen. Nicht nur "Planen ist langweilig", sondern auch eine Detailebene wie "Wir verbringen viel Zeit damit, über unklare Anforderungen zu sprechen, und niemand scheint die richtige Antwort zu kennen." Besprechen Sie dann diese spezifischen Probleme in Ihren Rückblick und machen Sie ein Brainstorming, um spezifische Lösungen zu finden. Teilen Sie Ihr Problem auf, bis die Teile leicht zu lösen sind.

Wir halten unsere Sprintplanung und Rückschau gleichzeitig ab und sind fast immer in 90 Minuten fertig, aber wir sind eines der schnelleren Teams. Alle 5 Sprints, die 4 bis 6 Stunden dauern, planen wir unternehmensweit langfristig. Natürlich ist jedes Team anders, aber wenn Sie jeden Sprint einen ganzen Tag verbringen, gibt es viel Raum für Verbesserungen.

Ihre Planungssitzungen sind viel zu lang!

Nach meiner Erfahrung sollte ein Sprint-Planungstreffen nicht länger als 2 Stunden pro Woche dauern (z. B. sollte ein 2-wöchiger Sprint höchstens 1/2 Tag dauern), erfolgreiche sollten jedoch kürzer sein (die Hälfte davon).

In Ihrem speziellen Fall: Warum schätzen Sie Aufgaben ein? Sie sollten während der Planung nur Geschichten schätzen. Aufgaben können später von den jeweiligen Aufgabenbesitzern geschätzt werden .

Ein Weg, der für mich funktioniert hat:

• Schnelleinstieg in den Sprint von der PO
• Schätzung der Sprintkapazität
• Die Geschichten laufen ab und planen Poker (mit einer Zeitspanne von 5 bis 10 Minuten pro Geschichte), bis es genug geschätzte Dinge gibt, um den Sprint zu decken
• Offizielles Engagement / Prognose des Teams

Dann parallel / Paare / selbst organisiert an unseren Schreibtischen, Aufgabenstellung und Aufgabenschätzung.

Bei meinem vorherigen Job wurde der gesamte erste Tag jedes Sprints (wir nannten sie dort Iterationen) mit Folgendem belegt:

• Rückblick. Wir begannen dies am Nachmittag des letzten Tages, sahen uns aber oft nach dem Sprint um und machten uns dann wieder an die Arbeit, um die letzten losen Enden des Sprints zu binden Die Arbeit lag alle hinter uns, bevor wir uns damit befassten. Es erschien auch logisch, den gesamten Meeting-Overhead des Scrum-Prozesses zu konsolidieren, damit die anderen Tage besser geplant und verbracht werden können. Dies dauerte normalerweise 2 Stunden.
• Sprint-Planung. Der Rückstand wurde während eines Meilenstein-Planungstreffens geschätzt (das sowohl für die Entwickler als auch für die POs ein ganzer Tag sein kann) und von den POs vor Beginn jedes Sprints priorisiert. Wir fanden heraus, wie viele Entwicklertage wir zur Verfügung hatten (Abrechnung von Feiertagen, Urlaub usw.), griffen nach der Arbeit, von der wir dachten, wir könnten sie vom Stapel werfen, und überprüften schnell die Benutzeranforderungen (die zuvor von unseren BAs überprüft wurden) Machen Sie sich ein umfassenderes Bild von der Arbeit als mit der einfachen Übersicht während des MPM. Dies dauerte in der Regel weitere 2 Stunden.
• Aufgabenplanung. In Kenntnis der Geschichten und Akzeptanzkriterien haben wir jede Geschichte in mundgerechte Aufgaben zerlegt, die in idealen Stunden veranschlagt wurden (eine Stunde diente ausschließlich dazu, diese Aufgabe ohne Ablenkungen oder Hindernisse zu erledigen). Die Art und Weise, wie unsere Punkteskala kalibriert wurde, war eine 5 ein Entwicklersprint, so dass eine 1 bis einschließlich zwei Entwicklertagen alles sein konnte. Aus diesem Grund musste praktisch alles aufgeschlüsselt werden, damit die Teammitglieder Fortschritte auf dem Scrum Board zeigen konnten. Dies war ein weiterer 2-Stunden-Block mit einigem Geben und Nehmen zwischen diesem und dem nächsten Punkt.
• AAT-Gliederung. Unsere POs und BAs waren keine Programmierer und codierten nicht. Die POs hatten sich hinter einem Vertrag versteckt, der vorschrieb, dass sie Anforderungen in Form einer Word-Vorlage liefern und mit den BAs zusammenarbeiten würden, um sie in dieser Form zu verfeinern. BAs verstanden Code, aber ihre Zeit war nur die Analyse und das endgültige Testen (was voraussetzte, dass das System existierte, damit sie ihre Makros in Selen aufzeichnen konnten). Um zu überprüfen, ob unser Code die Akzeptanzkriterien dafür erfüllt, mussten wir unsere eigenen AATs schreiben, die die Aktionen des "Papier" -Akzeptanztests modellieren. Wir haben dies normalerweise in demselben NUnit-Framework getan, das wir für Unit- und Integrationstests verwendet haben (wir haben FitNesse ausprobiert und konnten es nicht schnell genug aufgeben). Dies war der Rest unseres ersten Tages in jedem Sprint und setzte sich in den zweiten fort.

In meinem derzeitigen Job übernehmen wir immer noch den Scrum-Prozess, hatten keine teamweite Meilensteinplanung und viele unserer Arbeiten unterliegen keinen strengen Akzeptanzkriterien. Unsere Sprint-Planung ist also eine Erklärung dafür, was jede Geschichte beinhaltet und was wir als erledigt bezeichnen, und eine Verpflichtung, die besten X idealen Arbeitsstunden von der Spitze zu holen. Wir kommen damit durch - zumindest vorerst -, weil wir ein internes Team sind und jeder von uns persönlich mit den Endbenutzern unserer Software zusammenarbeitet, um Anforderungen und Entwurfslösungen zu erarbeiten. Selbst dann ist die Sprintplanung jeden zweiten Montag ein ganztägiger Vormittag, und am Nachmittag müssen alle persönlichen Hindernisse beseitigt werden, damit die Entwicklung am Dienstag ernsthaft beginnen kann.

Um die Frage des OP tatsächlich zu beantworten, anstatt andere Kommentare / Antworten zu kontrastieren, die besagen, dass es nicht so lange dauern sollte, gibt es Möglichkeiten, agile Schätzungen, Sprint-Planungen und Rückblicke durchzuführen, die ein wenig interessanter sind, als Sie vielleicht verwenden.

Speziell auf Ihre Bedenken eingehen:

• Besprechungen sind lang - Zeitrahmen sie. Jedes Meeting, sei es eine Retrospektive, eine Sprintplanung, eine Aufgabenaufteilung usw., sollte einen bestimmten Zweck und ein bestimmtes Diskussionsthema haben und so weit wie möglich auf einen festgelegten Zeitraum begrenzt sein. Es ist die Aufgabe des Scrum Masters, diese Meetings auf dem neuesten Stand zu halten und die Zeitziele zu erreichen.

• Die Treffen sind eintönig - davon wird es einige geben; Sie arbeiten nacheinander in mundgerechten Stücken, sodass Sie immer wieder dasselbe tun. Es hilft, das Team fokussiert zu halten und den Zweck des Meetings zu erreichen.

  Etwas anderes, was ich höre, ist, dass Ihre Sprint-Planungstreffen vielleicht zu viel bewirken. In meiner letzten Firma wurde die Geschichtsschätzung bei "Meilensteinplanungstreffen" durchgeführt, die ungefähr einmal im Quartal stattfanden und den ganzen Tag dauerten. In diesen Sitzungen wurde alles, was sich auf dem Rückstand angesammelt hatte, den wir nicht geschätzt hatten, in Punkten geschätzt. Wenn Sie eine Story-Schätzung in Punkten und dann eine Aufgabenschätzung in Stunden durchführen, möchten Sie nicht beide gleichzeitig ausführen (möglicherweise am selben Tag).

• Das Schätzen von Geschichten in Punkten und dann von Aufgaben in Stunden erscheint überflüssig. Sie haben zwei unterschiedliche Zwecke. Der Zweck der Story-Schätzung besteht darin, eine grobe Schätzung der Komplexität bereitzustellen, mit der Sie Ihren Sprint-Rückstand basierend auf der Geschwindigkeit in der Vergangenheit und der erwarteten Bandbreite füllen können. Der Zweck der Aufgabenschätzung besteht darin, die Geschichten in Dinge zu zerlegen, die einen Entwicklertag oder weniger dauern (und daher einem einzelnen Mitarbeiter zugewiesen werden können, von dem zu erwarten ist, dass er alles rechtzeitig erledigt), und sicherzustellen, dass Sie dies nicht tun Die Komplexität einer Geschichte wurde falsch eingeschätzt und nicht mehr abgebissen, als Sie im Sprint vermasseln können.

  Wenn Ihre Geschichten alle einen Tag oder weniger dauern, ist dies überflüssig, aber nicht alle Punkteskalen werden gleichermaßen kalibriert. Bei meinem letzten Job waren es 5 Entwicklerwochen (weil wir anfangs viele Epen zu schätzen hatten), was auf einer linearen Skala einen Punkt von bis zu 2 Entwicklertagen ausmachte. In Anbetracht dieser Größenordnung sollte praktisch alles in Aufgaben unterteilt werden. In meiner neuen Firma ist ein Punkt näher an einem halben Entwicklertag, also ist eine 1 oder sogar eine 2 definitiv ihre eigene Aufgabe, und 3-8 ist im Hinblick darauf, das Team zu zwingen, sie in Aufgaben aufzuteilen, nebulös.

• Es gibt einen Teufelskreis, der länger dauert und die Leute weniger fokussiert, so dass es länger dauert - Time-Box Ihre Time-Box. Machen Sie Pausen, so wie Sie es beim Codieren sein sollten. Nehmen Sie sich alle 30 Minuten 5 Minuten Zeit, um Ihre Beine zu strecken, sich neu zu gruppieren usw. Sie können es jede Stunde zehn Minuten lang machen, aber schieben Sie keinen festen Zeitblock zu weit darüber hinaus. Ihre Leute könnten hungrig werden oder mehr Kaffee oder eine Toilettenpause brauchen. Wenn du sie dazu bringst, es aufzusaugen, wirst du feststellen, dass ihre Gedanken wandern. Darüber hinaus hilft es auch, die Diskussionen kurz, bündig und auf den Punkt zu bringen, wie bereits erwähnt.

Das Sprint-Planungstreffen besteht aus zwei Teilen:

1. Entscheide, was das Team tun wird
2. Entscheide, wie das Team es machen wird.

Der erste Teil ist relativ einfach - basierend auf der Anzahl der Story-Punkte, die das Team annehmen kann, und der Verpflichtung, so viele User-Storys in der Reihenfolge ihrer Priorität fertigzustellen. Getan.

Der zweite Teil ist, was Entwickler eigentlich genießen sollten - die Ausarbeitung der Geschichte und das Entwerfen der Lösung. Die Aufgaben fallen dabei heraus. Lassen Sie sich vom Produktbesitzer oder einem von ihm bereitgestellten KMU eine ausgewählte Geschichte erklären. Lassen Sie dann den Entwickler die Konstruktionsdiskussion leiten. Verwenden Sie eine weiße Tafel. Ideen austauschen. Habe Spaß.

Das war's auch schon. Wenn Designtreffen keinen Spaß machen, stimmt einfach etwas nicht.

Ja, ich weiß, dass dies eine alte Frage ist, aber ich habe eine neue Antwort. : P

Teilen Sie das Meeting auf.

Wir haben unser Sprint-Planungstreffen in 3 separate Minitreffen aufgeteilt

• Rückstandspflege
• Auswahl der Geschichte
• Aufgabenaufschlüsselung

Wir machen jedes an einem anderen Tag, gleich nach unserem täglichen Scrum - sobald das tägliche erledigt ist, rollen wir direkt in die Planungsaktivität ein und sind dann den Rest des Tages frei von (regelmäßig geplanten) Besprechungen.

Also ja, wir haben unsere Planung verwässert: -O

Ich werde in einer Sekunde detaillierter darauf eingehen, was in jeder Sitzung vor sich geht, aber lassen Sie mich erklären, wie wir zu diesem Ergebnis gekommen sind.

Wir hatten wie Sie ein Problem mit wirklich schrecklichen Sprint-Planungstreffen. Wir hatten alle richtigen Elemente, aber alles dauerte nur ewig und war mental und emotional sehr anstrengend, um durchzukommen.

Nachdem ich diesen 5-minütigen Business Insider-Artikel von Pivotal gelesen hatte, in dem es darum ging, unsere Meetings in kürzere Sitzungen aufzuteilen und zu Beginn eines jeden Tages durchzuführen, kam mir diese Idee .

Ich habe es bei einer Retrospektive mit dem Team besprochen. Einige Teammitglieder mochten es sofort, andere waren ein wenig besorgt, aber dann erwähnte unser Praktikant eine Studie, die er über die Pomodoro-Technik las und die er weiterführte , und das half der Idee wirklich, Anklang zu finden.

Also beschlossen wir, es zu versuchen.
Wir haben unser 2-stündiges Meeting in drei 25-minütige Sitzungen unterteilt. (Ja, das ist eine unscharfe Rechnung, aber alle waren der Meinung, dass unsere Besprechungen zu lang waren und dies nur tun wollten, wenn wir Zeit gespart haben.)

Und es hat funktioniert! Wir haben es jetzt für ungefähr 6 Wochen in zwei separaten Projekten gemacht (insgesamt 6 Sprints für 2 Wochen) und es hat einen großen Unterschied gemacht.
Wir sind produktiver. Wir sparen eine Menge Zeit.
Wir bekommen bessere Ergebnisse. Und wir fürchten unsere Planungsgespräche nicht mehr.

Und ehrlich gesagt, unsere 25-minütige Zeitbox ist ziemlich locker - einige Sitzungen verlaufen sehr schnell, wie zum Beispiel 5-10 Minuten bei einigen unserer Pflegesitzungen, und einige dauern lange, wie zum Beispiel, wenn wir am Ende neue Geschichten identifizieren oder Geschichten trennen müssen und Neuschätzung während der Verhandlung. Insgesamt beträgt der Durchschnitt jedoch nicht mehr als 1,5 Stunden für den gesamten Shebang, und ich denke, das ist der Grund, warum es so gut funktioniert.

Auf zu den Details .....

Rückstandspflege

Ganz einfach - wir überprüfen die Geschichten mit der höchsten Priorität, besprechen, was sie beinhalten, und stellen sicher, dass unsere Schätzungen gut sind.

Wir werden die Geschichten bei Bedarf neu schätzen - sagen wir, wir haben sie vor einigen Monaten geschätzt, und nachdem wir festgestellt haben, was für eine ähnliche Geschichte tatsächlich geschah, werden wir uns möglicherweise darauf einigen, sie neu zu schätzen. (Wir verwenden übrigens Story-Punkte ohne Einheiten und schätzen keine Aufgaben ).

Wenn der PO neue Geschichten hinzugefügt hat, die seiner Meinung nach hohe Priorität haben, ist dies der richtige Zeitpunkt, um sie einzuschätzen.

Da wir die Story-Auswahl erst am nächsten Tag durchführen, hat der PO ein wenig mehr Zeit, um endgültig zu beurteilen, was in der nächsten Iteration am wichtigsten ist - und dies hat sich als sehr hilfreich erwiesen.

Diese Besprechung ist bei einigen PO eher kurz und bei anderen eher lang. (Ich persönlich denke, es ist ein großartiger Geruchsindikator dafür, wie es Ihrer Bestellung geht.)

Auswahl der Geschichte

Holen Sie sich Ihren Chris Voss auf, es ist Zeit zu verhandeln.

Bei diesem Treffen nehmen wir die Geschichten mit der höchsten Priorität und definieren für jede eine DoD . Wir verhandeln, worum es geht - teilen und kombinieren Sie Geschichten nach Bedarf -, bis wir uns alle auf unsere Sprint-Ziele einigen können.

Wir profitieren in hohem Maße von einem frischen Geist und der guten Morgenenergie für dieses Treffen. Wenn wir wissen, dass wir an einem anderen Tag Aufgaben erledigen werden, können wir die Zeit aufwenden, die wir benötigen, um wirklich gut zu verhandeln und unsere Verpflichtungen zu verstehen.

Aufgaben

Okay, also werde ich der Erste sein, der sagt, dass Aufgaben in unseren alten eintägigen Besprechungen mein MINDESTPUNKT bei der Planung waren.

Damit sind wir einfach nie vorangekommen. Wir haben versucht, Aufgaben bis zum Ende des Meetings zu speichern - aber bis dahin waren wir alle erschöpft und es war wirklich unproduktiv. Wir haben versucht, Aufgaben gleichzeitig mit unserem DoD während unserer Verhandlungen zu definieren, aber wir fanden es zu ablenkend und zu umständlich - wir würden uns selbst verbrennen, bevor wir alle Geschichten auswählen. Außerdem war es wirklich schwierig, den Fokus / das Denken zwischen Schätzen, Verhandeln, Auswahl von Storys und Generieren von Aufgaben immer wieder zu wechseln. Wir kämpften, und es saugte, und es machte unsere Sitzungen schrecklich.

Aber jetzt, wenn wir das DoD an einem Tag definieren und erst am nächsten Tag Aufgaben erledigen, werden wir nicht ausgebrannt, wir sind immer in der richtigen Verfassung und es gibt uns einen ganzen Tag Zeit, über die Geschichte und wirklich zu marinieren Überlege und verstehe alle Aufgaben, bevor wir anfangen.

Dies allein ist meiner Meinung nach ein totaler Game Changer.

Alles zusammen.

So sieht unser Zeitplan für die Sprint-Zeremonie jetzt aus:

• Montag - Tägliches Gedränge -> Sprint-Rückblick
• Dienstag - Tägliches Gedränge -> Backlog-Pflege
• Mittwoch - Tägliches Gedränge -> Storyauswahl
• Donnerstag - Tägliches Gedränge -> Aufgaben
• Freitag - Tägliches Gedränge -> Rückblick

Es hat wirklich gut für uns funktioniert. Wenn Sie es versuchen, würde ich gerne hören, was Sie denken.

Wir haben einen wöchentlichen Sprint mit einer einstündigen Besprechung, in der wir den vorherigen Sprint besprechen, was noch zu tun ist und dann mit der Planung der kommenden Woche fortfahren. Alles innerhalb einer Stunde.

Dies liegt natürlich daran, dass wir herausgefunden haben, dass in unserem Fall ein zu striktes Verfolgen von Scrum nur zu viel Zeit verschwenden würde. Das liegt daran, dass die meisten Storys bereits mit unseren Teammitgliedern besprochen werden, wenn der Anforderer die User Story erstellt.

Ich sage nur, wenn Ihr Team die Planung von Besprechungen fürchtet, sollten Sie wahrscheinlich einige der "Regeln" des Scrums loslassen.

Diese Frage wurde umfassend beantwortet, aber nur eines ist erforderlich, damit es funktioniert und Spaß macht.

Gib dem Team Kraft. - dh sie an Dingen arbeiten lassen, von denen sie denken, dass sie am wichtigsten sind.