Frage

sind nicht nur unsere Sprint-Planungs-Meetings nicht lustig, sie sind gerade rechts schrecklich.

Die Treffen sind langweilig und langweilig, und nehmen für immer (einen Tag, aber es fühlt sich länger an.
Die Entwickler beschweren sich darüber und freut bevorstehende Planungen.

Unsere Routine ist ziemlich standard (Benutzergeschichte, die durch Priorität in Sprint-Backlog eingefügt wird >> Die Geschichte wird auf Tasks ausgelegt >> Aufgaben werden in Stunden geschätzt >> wiederholen), und ich kann nicht herausfinden, was wir falsch machen .

Wie können wir die Meetings angenehmer machen?

...

Weitere Details, als Reaktion auf Anfragen für weitere Informationen:

Warum sind die Backlog-Elemente, die nicht vor dem Sprint-Kickoff eingesetzt und priorisiert sind?

Benutzergeschichten sind in der Tat priorisiert; Wir haben keine Ahnung, wie lange sie dauern, bis wir sie in Aufgaben zusammenbrechen! Von den (ausgezeichneten) Antworten hier sehe ich, dass wir vielleicht keine Aufgaben, nur die Benutzergeschichten schätzen sollten. Der Grund, warum wir Aufgaben (und nicht nicht Geschichten) schätzen, ist, weil wir uns geschützt haben - Schätzungen schrecklich scheinbar - aber ich denke, das ist das Thema für eine völlig andere Frage.

Warum klagten Entwickler?

    .

  1. treffen sind lang.

  2. treffen sind monoton. Geschichte nach der Geschichte, Aufgabe nach Aufgabe, Kämpfen (Ja, Kämpfung), um zu schätzen, wie lange es dauern wird und was es bedeutet.

  3. Schätzungsaufgaben lässt die Anwender-Story-Schätzung sinnlos erscheinen.

  4. Je länger das Treffen ist, desto weniger Fokus im Raum. Die weniger fokussierten Kollegen sind, desto länger dauert das Treffen. Eine rekursive Hass-Spirale entwickelt sich. Wir haben angesehen, das Treffen in zwei Tagen zu spalten, um die Menschen fokussierten, aber die Entwickler würden es nicht davon hören. Ein Tag der Planung ist schlimm genug; Jetzt haben wir zwei ?!

    5. Teil unseres Problems ist, dass wir in sehr kleine Details eingehen (um genauere Schätzungen zu erhalten). Aber wenn wir ungefähr einschätzen, gehen wir weit von der Marke!

    , um die Frage zusammenzufassen:

    • Was machen wir falsch?

    • Welche zusätzlichen Möglichkeiten gibt es, um das Treffen in der Regel angenehmer zu gestalten?

War es hilfreich?

Lösung

Schätzung einfacher

Brechen Sie Ihre Sprint-Planung nach unten.

Benötigen Sie , um die einzelnen Aufgaben zu schätzen? Ich habe SPRINT-Planung zwei Möglichkeiten gemacht:

    .
  1. Die Geschichten werden in Story-Punkten geschätzt und dann werden Aufgaben in Stunden geschätzt
  2. Geschichten werden in Story-Punkten und Aufgaben geschätzt, die einfach darunter fallen, ohne Schätzung

    3. Von den beiden bevorzugen ich die zweite Option. Ich finde, dass keine Schätzung der Aufgaben den Entwicklern mehr Freiheit gibt, um Änderungen umzugehen. Wenn eine Aufgabe keine Aufgabe mehr sinnvoll macht (Wie oft haben Sie herausgefunden, dass eine Aufgabe nicht anwendbar ist oder bereits anwendbar ist Ein früherer Sprint) Sie werfen es einfach ohne Strafe aus, oder Sie müssen möglicherweise eine aktuelle Aufgabe in etwas Neues ändern, möglicherweise brechen Sie es auf. Sie sind wirklich redundant, wenn Sie beide schätzen, da die Summe der Aufgaben die Story-Punkte darstellen sollte und umgekehrt. Welchen Wert gewinnen Sie wirklich von diesem anderen als zu wissen, wie viel Zeit einzelne Aufgaben dauert? Wenn Sie sich mit Taskgrößen befinden, die wirklich variieren, um einen Unterschied zu unterscheiden, würde ich vorschlagen, diese Aufgaben in kleinere, homogenere Brocken zu brechen.

    Indem Sie dies tun, können Sie bei der Zeit, die Sie in der Sprint-Planung in der Sprint-Planung ausgeben, reduzieren. Geschichten werden während der Sprintplanung geschätzt, und wenn Sie den Sprint starten, können Sie alle Aufgaben ablegen, die Sie vorstellen können, die diese Geschichte bilden. Offensichtlich, wenn Sie Punkte gibt, die Sie beim Schätzen der Geschichte stoßen, die Sie wissen, dass Sie in einer Aufgabe behandelt werden müssen, können Sie das auf die Story-Informationen hinzufügen und es als Aufgabe setzen.

    Schätzung in idealen Einheiten

    story punkte sollen in ideal itrhs wie ideale mann stunden oder ideale Arbeitstage sein. Diese sollen bedeuten, dass jeden Tag den perfekten Tag gegeben, in dem Sie keine Unterbrechungen hatten, keine Meetings, und alles, was nach Plan verlief, könnten Sie die Aufgabe in X-Tagen erreichen. Jetzt weiß jeder, dass dies einfach nicht wahr ist, aber das Wunderbare an Statistiken ist, dass es nicht sein muss.

    Was ich damit meine, ist, dass Sie nach einer Weile, dass sie in idealen Tagen schätzt, dies erkennen, dass möglicherweise ein zusätzliches 25% dauert, an dem Sie durchschnittlich einschätzt, um eine Geschichte abzuschließen. Nehmen wir an, Sie hätten geschätzt, dass es 4 ideale Arbeitstage geschätzt hatte, und stattdessen brauchten Sie 5. Im Laufe der Zeit behalten Sie dies denkst, und dann haben Sie eine grobe Vorstellung von der Umwandlung von idealen Tagen bis echten Tagen. Ihr erster Instinkt wäre, dies durch die Schätzung zu versuchen und zu kompensieren, und Sie würden wahrscheinlich falsch sein. Die Hauptsache ist hier, um konsistent zu bleiben. Auf diese Weise bleibt Ihr langfristiger Durchschnitt gleich. Sicher, manchmal ist es unter und manchmal wird es vorbei sein, , aber je mehr Sie schätzen, desto besser sind Sie. Wenn Sie feststellen, dass Sie noch können t eine anständige Schätzung, vielleicht bedeutet dies, dass Sie nicht genug über die Geschichte wissen, um sie richtig abzuschätzen.

    Sprechen Sie über die Geschichten

    Wenn Sie abschätzen, sollten jeder eine grobe Vorstellung davon haben, was getan werden muss, von Anfang bis Ende, dessen, was es für diese Geschichte brauchen wird, um vollständig zu sein. Sie müssen nicht jedes Detail wissen, aber genug, dass Sie Ihnen denkst, dass Sie die Geschichte übernehmen könnten. Wenn Sie dieses Vertrauen nicht haben, sollten Sie es wahrscheinlich nicht schätzen. Wenn Sie sagen, "Nun, diese Geschichte ist zu groß, um die meisten Details zu kennen", dann ist das ein Hinweis darauf, dass die Geschichte zu groß ist, und sollte abgebaut werden. Geschichten, zumindest in meiner Erfahrung, waren klein genug, dass eine Person, wenn es sein muss, allein daran arbeiten und es innerhalb einer oder zwei Wochen erledigen könnte.

    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 Geschichte zu schätzen, schätzen Sie die Geschichte einfach als Ganzes, was dazu beitragen sollte, eine Menge der Schätzung zu entfernen. Um die Treffen weniger monoton zu machen, würde ich vorschlagen, Poker zu planen, den Sie mehr Informationen über oben sehen können.

    Planen Sie mehr Eingriffe

    Schätzung mit Planung von Poker

    Soweit eine Schätzung mehr Spaß macht, haben Sie versucht, Planung Poker ? Es ist das Art und Weise, wie ich immer für alle meine Sprints auf mehreren Teams planen, und es ist eine gute Möglichkeit, alle Beteiligten zu behalten, da jeder Mensch zumindest etwas auswählen muss. Es gibt auch einen angemessenen Betrag, der beteiligt ist, wenn jeder auf dem Team mit 3 passt, und jemand setzt einen 20 ein und muss sich selbst erklären, oder wenn jeder auf dem Team einen 5 legt, aber der Manager setzt einen 8 (der mit dem Gonna argumentiert der Chef, wenn er dir mehr Zeit geben will!).

    Um dies zu tun, alles, was Sie brauchen, sind einige Planung von Poker-Karten , die wir oft auf der Rückseite der Karteikarten machen oder normale Spielkarten mit den an Gesichtskarten befestigten Werten verwenden. Nichts fantastisch, und es bleibt immer mehr

Jone fokussiert.Denken Sie daran, dass der Versuch, eine Aufgabe für einen ganzen Tag (einschließlich Planungspoker) zu erledigen, eine Maut der Produktivität trägt.Viele Kartensätze kommen aus einem bestimmten Grund mit einer Kaffeekarte.Wenn sich jemand verbrannt fühlt, geben Sie dem Mannschaft eine Pause, um aufzuladen und abzuholen, wenn jeder frisch ist!

als Alternative zu physischen Karten , können Sie auch elektronische Karten ansehen.Die eigentlichen Vorteile hier sind automatisierte Verfolgung von Ergebnissen, die Verfolgung von Benutzergeschichten, die geschätzt werden sollen, und ermöglicht es jedem, seine Karten auf einmal zu zeigen, um "Betrug" zu vermeidenNatürlich setzt dies erfordert, dass jeder einen Computer und die Fähigkeit hat, sich auf die zu handhabende Aufgabe zu fokussieren, also nutzen Sie ihn nach eigenem Ermessen.

Andere Tipps

    .

  1. Warum sind die Backlog-Artikel, die nicht vor dem Sprint-Kickoff eingesetzt und priorisiert sind? Verschwenden von Entwicklern Zeit ist nicht lustig. Lassen Sie Ihr Team einige Tage zuvor mit dem Produktinhaber und dem Projektmanager führen, um Sachen zu priorisieren. Dies gilt für die Planung, wer auch in jedem Sprint-Team ist.

  2. warum dauert es einen Tag, um die Dinge in Aufgaben zu brechen? Wenn Sie ein vernünftiges Team (2-4 Entwickler, .5-1,5 QA Personen pro Entwickler, 1- 2 Sonstiges) Dann sollten Sie diesen Sprint 2-4 Benutzergeschichten haben. Verbringen Sie 30 Minuten mit dem Produktinhaber, der Anforderungen klärt, dann 30 Minuten oder so auf ~ 8-Stunden-Aufgaben. Geben Sie nicht die Aufgaben während des Treffens ein. stimmen Sie einfach als Team ein, was die Aufgaben ausreichen, um sie zu verstehen, um sie zu verstehen, die für sie verantwortlich ist, und wie lange sie dauern sollten. Stimme zu, dass "wie lange sie (einschließlich des Tests)" (einschließlich Tests) ", bequem in den Sprint passt.

  3. Wenn es nicht nur Dinge in Aufgaben bricht, was tust du sonst noch? Sicher, Rückblicke können 30-60 Minuten dauern, aber es wird kürzer sein, da die Teams in eine Groove gelangen.

    4. Also zusammenfassend - aufhören, die Zeit der Menschen zu verschwenden, und sie werden die Besprechungen etwas weniger erforschen. Darüber hinaus, Spaß und Comradarie im Team können Sie in Meetings nicht ansprechen können. Gehen Sie zusammen zum Mittagessen, scherzen Sie herum, mischen Sie die Menschen auf, um eine bessere Persönlichkeit zu haben, haben Persönlichkeit, die Schnurrbartwetterwettbewerb haben

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

Einige erfolgreiche Ideen Ich habe entweder persönlich versucht oder von anderen Teams gehört:

  • Machen Sie die Benutzergeschichte-Erstellung und Priorisierung ohne das gesamte Team. Der Produktinhaber- und / oder Scrum-Master kann mit vielen der geschäftigen Arbeit umgehen und lässt das Team einfach anfahren.
  • Machen Sie Ihren Backlog deutlich länger als ein einzelner Sprint. Es kann eine Weile dauern, um es aufzubauen, aber wenn Ihr Backlog lang genug ist, werden die Planungsversammlungen reduziert, um kleine Verbesserungen zu erzielen oder die jüngsten Geschäftsentwicklungen anzusprechen.
  • Haben Sie Senkungstreffen von Sprint-Planung getrennt. Wenn die Leute denken, dass die Treffen zu lang sind, gibt es keinen Grund, sie nicht aufzuteilen.
  • Planen Sie die Pausen in die Agenda. Dies ist nützlich, wenn Sie oft Zeit verschwenden, um auf ein oder zwei Teammitglieder zu warten, um zurückzukehren.
  • brechen Sie in der Mitte des Treffens ein und weisen Sie alle ein, um ein oder zwei Benutzergeschichten aufzunehmen, und treffen Sie sich dann wieder zusammen, um den Konsens zu melden und zu gewinnen.
  • Vergewissern Sie sich, dass Ihr Planet Meeting um ist, was zu tun ist, nicht wie es zu tun ist. Ingenieure fallen sehr leicht in letztere. Wenn Sie müssen, setzen Sie separate Design-Meetings ein, an denen Sie das How diskutieren.
  • Trennen Sie Ihre Geschichten in Untersuchung und Implementierung. Planung von Treffen gehen oft zu lang, wenn Teammitglieder zu wenig darüber wissen, wovor sie arbeiten werden, und versuchen, es während des Treffens herauszufinden.
    Zum Beispiel sagen Sie, dass Sie mit einer API integriert werden müssen, dass Ihr Team keine Erfahrung hat mit. Anstatt zu versuchen, Schätzungen und Aufgaben während des Planungstreffens über etwas zu erstellen, über das Sie ahnungslos sind, machen Sie eine Untersuchungsgeschichte, um die API zu erlernen, eine einfache "Hello World" -App durchführen und es dem Team beibringen. dann Sie sind, um die eigentliche Arbeit zu planen.
  • Bewahren Sie den Track während Ihrer Sitzungen spezifischer Fragen auf. Nicht nur "Planung ist langweilig", sondern ein Maß an Details wie "Wir verbringen viel Zeit, über unklare Anforderungen zu sprechen, und niemand scheint die richtige Antwort zu wissen." Besprechen Sie dann diese spezifischen Probleme in Ihren Rückblicken und Brainstorming für bestimmte Lösungen. Brechen Sie Ihr Problem ab, bis die Teile leicht zu lösen sind.

Wir halten unsere Sprint-Planung und Retrospektive gleichzeitig und sind fast immer in 90 Minuten erledigt, aber wir sind eines der schnelleren Teams. Wir machen eine große unternehmensweite längerfristige Planung aller 5 Sprints, die 4-6 Stunden dauern. Jedes Team ist natürlich anders, aber wenn Sie einen ganzen Tag mit jedem Sprint verbringen, gibt es viel Platz zur Verbesserung.

Ihre Planungssitzungen sind viel zu lang!

Basierend auf meiner Erfahrung sollte ein Sprint-Planungstreffen nicht mehr als 2 Stunden pro Woche dauern (z. B. sollte ein 2-wöchiger Sprint höchstens 1/2 Tag dauern), aber erfolgreiche sollten kürzer sein als das (die Hälfte vones).

In Ihrem speziellen Fall: Warum schätzen Sie Aufgaben?Sie sollten nur Geschichten während der Planung schätzen.Aufgaben können später durch die -Pezifischen Aufgabenbesitzer geschätzt werden.

Eine Art und Weise, die für mich funktionierte:

  • Schnelle Intro zum Sprint von der PO
  • Schätzung der Sprintkapazität
  • Stories rennen herunter und planen Poker (teitend mit 5/10 Minuten pro Story), bis es genügend geschätzte Sachen gibt, um den Sprint
    • abzudecken
  • offizielles Engagement / Prognose vom Team

dann in Parallel- / Paaren / selbst organisiert an unseren Schreibtischen, Tasking- und Aufgabenschätzungen.

Bei meinem vorherigen Job wurde der gesamte erste Tag jedes Sprints (wir nannte sie dort Iterationen an) aufgenommen mit:

  • retrospektiv. Wir haben das am Nachmittag des letzten Tags angefangen, aber wir fanden uns oft retrospektiven über den Sprint und ging dann wieder auf die Arbeit, die die letzten losen Enden der Arbeit dieser Sprints anbinden , also dachten wir, es wäre besser, sicherzustellen, dass die Arbeit alles hinter uns war, bevor er retrospektiviert. Es schien auch logisch zu sein, um alle Besprechung des Scrum-Prozesses zu konsolidieren, sodass die anderen Tage in den anderen Tagen geplant und mit mehr idealer ausgegeben werden könnten. Dies dauerte normalerweise 2 Stunden.
  • Sprint-Planung. Der Backlog wurde während eines Meilenstein-Planungs-Treffens geschätzt (der sowohl für den Devs als auch für POS ein ein ganzen Tag sein könnte) und wurde vor dem Anfang vor dem POS priorisiert worden von jedem Sprint. Wir haben herausgefunden, wie viele Entwicklertage wir zur Verfügung gestellt hatten (Bilanzierung von Feiertagen, Vaca usw.), packte die Arbeit, die wir dachten, wir könnten von der Spitze des Haufens ausmachen, und überprüfte schnell die Anforderungen der Benutzer (zuvor von unserem BAS geprüft von unserem Bas) Erhalten Sie ein kompletteres Gefühl dafür, was die Arbeit als mit der einfachen Übersicht während des MPM erhalten hat. Dies dauerte normalerweise weitere 2 Stunden.
  • Task-Planung. Die Kenntnis der Geschichten und den Akzeptanzkriterien haben wir jede Geschichte in die in idealen Stunden geschätzten Biss-Size-Aufgaben (eine Stunde, die sich ausschließlich auf diese Aufgabe konzentrierte, mit keinen Ablenkungen der Task-Aufgabe einbrochen oder Straßensperren). Die Art und Weise, wie unsere Punktwaage kalibriert wurde, ein 5 war ein Entwickler-Sprint, also könnte A 1 alles bis einschließlich zweier Entwicklertage sein. Aus diesem Grund musste praktisch alles abgebrochen werden, damit Teammitglieder den Fortschritt auf der Scrum Board zeigen können. Dies war ein weiterer 2-Stunden-Block, mit einigen Geben Sie zwischen diesem und dem nächsten Punkt.
  • AAT-Umriss. Unser POS und BAS waren keine Programmierer und kodierten nicht. Der POS versteckte sich hinter einem Vertrag, der festließ, dass er Anforderungen in Form einer Word-Vorlage liefern und damit arbeiten würde, um sie in dieser Form zu verfeinern. SON SE-SEIN-CODE, aber ihre Zeit war die rein Analyse und die endgültige Prüfung (die das System erforderte, so dass sie ihre Makros in Selen aufnehmen konnten). Um zu überprüfen, ob unser Code Akzeptanzkriterien erfüllen würde, als er dazu kam, mussten wir unsere eigenen Aats schreiben, die die Aktionen des "Papiers" -akzeptanztests modellieren. In der Regel taten wir dies in demselben NUnit-Framework, den wir für Einheits- und Integrationstests verwendet haben (wir haben Fitnesse versucht und konnten es nicht schnell genug aufgeben). Dies war der Rest unseres ersten Tags jedes Sprints und setzte sich in die Sekunde fort.

In meinem aktuellen Job haben wir immer noch den Scrum-Prozess angenommen, wir hatten keine teamweite Meilensteinplanung, und viel von dem, was wir arbeiten, nicht strenge Akzeptanzkriterien. Unsere Sprint-Planung ist also so viel eine Erklärung, was jede Geschichte dazu bringt, und was wir anrufen, da es sich um ein Engagement handelt, um die oberen x idealen Arbeitsstunden von oben zu ergreifen. Wir kommen damit weg - zumindest - weil wir ein internes Team sind, und jeder von uns arbeitet persönlich mit den Endbenutzern unserer Software, um Anforderungen und Designlösungen zu sammeln. Sogar dann ist die Sprint-Planung jeden zweiten Montag eine ganzen Morgensache, und der Nachmittag ist damit verbracht, alle persönlichen Straßenblocks zu löschen, um am Dienstag die Entwicklung ernsthaft aufnehmen zu können.

Um die Frage der OP tatsächlich zu beantworten, anstatt andere Kommentare / Antworten zu kontrastieren, sollte es nicht so lange dauern, es gibt Wege, die agile Schätzung, Sprint-Planung und Retrospektive zu nähern, die etwas interessanter sind als Sie möglicherweise verwenden.

Speziell an Ihre Bedenken angesprochen:

  • treffen sind lange - zeitkasten sie. Jedes Treffen, sei es eine retrospektive, Sprintplanung, Task-Zusammenbruch usw., sollte einen bestimmten Zweck und ein Thema Diskussion haben und sollte so weit wie möglich auf eine eingestellte Zeit begrenzt sein. Es ist der Job des Scrum-Meisters, um diese Treffen auf dem Thema zu halten, und rollen Sie zusammen, um die Zeitziele zu erfüllen.

  • treffen sind monoton - es wird etwas davon geben; Sie arbeiten in Biss-Size-Brocken, einer zu einem Zeitpunkt, damit Sie immer wieder das Gleiche tun. Das Team fokussierte und fährt, um den Zweck des Treffens zu erreichen, wird helfen.

    Etwas anderes, was ich höre, ist, dass Ihre Sprint-Planungs-Meetings möglicherweise, um zu viel zu erreichen. Bei meiner letzten Firma wurde die Geschichtenschätzung bei "Milestone Planning Meetings" durchgeführt, die einmal ein Quartal passierte und den ganzen Tag genommen hat. In diesen Treffen wurde alles, was auf dem Backlog aufgebaut war, den wir nicht geschätzt hatten, in Punkten geschätzt. Wenn Sie eine Story-Schätzung in Punkten tun, und dann die Taskschätzung in Stunden, möchten Sie sie nicht gleichzeitig tun (vielleicht am selben Tag).

  • Schätzung von Geschichten in Punkten, dann erscheint Aufgaben in Stunden redundant

EM> - Sie haben zwei verschiedene Zwecke. Der Zweck der Geschichtenschätzung besteht darin, eine grobe Abschätzung der Komplexität bereitzustellen, mit der Sie Ihren Sprint-Backlog basierend auf der an der Vergangenheitsgeschwindigkeit und der erwarteten Bandbreite füllen können. Der Zweck der Taskschätzung besteht darin, die Geschichten in Dinge zu brechen, die einen Entwicklertag oder weniger nehmen (und einem einzigen Kerl zugewiesen werden, der voraussichtlich alles in der Zeit erledigt hat), und stellen Sie sicher, dass Sie es nicht getan haben Es schätzte die Komplexität einer Geschichte noch nicht mehr aus, als Sie in dem Sprint kauen können.

Wenn Ihre Geschichten alle einen Tag oder weniger dauern, dann ist es redundant, aber nicht alle Punktewaagen werden gleichermaßen kalibriert. Bei meinem letzten Job war ein 5 zwei Entwicklerwochen (weil wir zu Beginn eine Menge Epen zu schätzen hatten), was auf einer linearen Skala einen Punkt bis zu 2 Entwicklertagen machte. Angesichts dieser Art von Skala sollte praktisch alles in Aufgaben unterbrechen. An meiner neuen Firma ist ein Punkt näher an einem halben Entwicklertag, also ist ein 1 oder sogar A 2 definitiv seine eigene Aufgabe, und 3-8 ist nebulös, um das Team zu zwingen, es in Aufgaben zu teilen.

  • Es gibt einen bösartigen Zyklus davon, der längere Weise länger macht, dass Menschen weniger fokussiert werden, sodass sie länger dauert - Time-Box Ihr Zeitfeld. Machen Sie Pausen, genau wie Sie sollten, wenn Sie kodieren sollten. Jeden 30 Minuten dauern 5 Minuten, um Ihre Beine zu strecken, umgruppieren usw. Sie können es zehn Minuten pro Stunde schaffen, aber dennoch einen soliden Blockierzeit zu viel weiter als das. Ihre Jungs könnten hungrig werden oder brauchen mehr Kaffee oder eine Badezimmerpause usw. nicht bestreiten; Wenn Sie sie absaugen lassen, finden Sie ihre Gedanken, die wandern. Darüber hinaus hilft Diskussionen kurz, süß und bis zum Punkt, wie zuvor erwähnt.

    • Das Sprint-Planungstreffen hat 2 Teile:

      .
    1. Entscheiden Sie, was das Team tun wird
    2. entscheiden, wie das Team es tut.

      3. Der erste Teil ist relativ direkt vorwärts - basierend auf der Anzahl der Story-Punkte, die das Team anfühlt, fühlt sie an, dass sie sich annehmen können, das Verpflegung, dass viele Benutzergeschichten in ihrer Reihenfolge der Priorität abgeschlossen werden.Fertig.

      Der zweite Teil ist, was Entwickler tatsächlich genießen sollten - Ausarbeitung der Geschichte und der Gestaltung der Lösung.Die Aufgaben fallen davon ab.Also, haben Sie den Produktbesitzer, oder was er, was er zur Verfügung gestellt hat, eine ausgewählte Geschichte erklärt.Dann, woran Entwickler es annehmen möchte, führen Sie die Design-Diskussion an.Verwenden Sie eine weiße Platte.Ideen drehen.Viel Spaß.

      das ist es wirklich.Wenn Design-Meetings nicht lustig sind, dann ist einfach etwas falsch.

    yea Ich weiß, das ist eine alte Frage, aber ich habe eine neue Antwort. : P

    das Treffen aufteilen.

    Wir teilen unser Sprint-Planungstreffen in 3 separate Mini-Meetings auf

    • Backlog-Pflege
    • Story-Auswahl
    • Task-Zusammenbruch

    Wir machen jeden an einem anderen Tag, direkt nach unserem täglichen Scrum -, sobald der Alltag erledigt ist, rollen wir direkt in die Planungstätigkeit, und dann sind wir frei von (regelmäßigen geplanten) Meetings den Rest des Tages.

    yea, wir trennten unsere Planung: -O

    Ich gehe dazu, was in einer Sekunde an jeder Sitzung involviert ist, aber lass mich erklären, wie wir dabei ankamen.

    Wir hatten wie Sie selbst ein Problem mit wirklich schrecklichen Sprint-Planungstreffen. Wir hatten alle richtigen Elemente, aber alles hat nur immer gedauert und war wirklich geistig und emotional, um durchzukommen.

    Dann bekam ich diese Idee nach dem Lesen diesen Business Insider Artikel zu Pivotals 5-minütigen täglich , um unsere Treffen in kürzere Sitzungen zu brechen und zu Beginn eines jeden Tages zu tun.

    Ich habe es mit dem Team in einem Retrospektive mitgebracht. Einige Teammitglieder mochten es sofort, andere waren ein wenig besorgt, aber dann erwähnte unser Praktikant eine Studie, die er über der Pomodoro-Technik und fing an, darüber zu gehen, und das hat der Idee wirklich geholfen, Traktion zu erlangen.

    Wir haben uns also entschieden, es zu versuchen.
    Wir haben unser 2-Stunden-Treffen in drei 25-minütige Sitzungen gebrochen. (Ja, das ist Fuzzy Mathe, aber jeder spürte, dass unsere Treffen zu lang waren und wollten es nur, wenn wir Zeit haben).

    und es funktionierte! Wir haben es seit ungefähr 6 Wochen an zwei separaten Projekten (6 zwei wöchentliche Sprints insgesamt) gemacht, und es ist eine Welt des Unterschieds gemacht.
    Wir sind produktiver. Wir sparen eine Tonne Zeit.
    Wir werden bessere Ausgänge. Und wir färben unsere Planungstreffen nicht mehr.

    und ehrlich gesagt, unsere 25-minütige Zeitbox ist ziemlich locker - einige Sitzungen gehen wirklich schnell, wie 5-10 Minuten bei einigen unserer Pflegesitzungen, und einige gehen lange, wie wir, wie wir neue Geschichten identifizieren oder Brechen Sie Geschichten auf und schätzen Sie während der Verhandlung erneut. Insgesamt wandert dies jedoch in der Regel nicht mehr als 1,5 Stunden für den gesamten Shebang, und ich denke, deshalb funktioniert es so gut.

    auf den Details .....

    Backlog-Pflege

    ziemlich einfach - wir überprüfen die obersten Prioritätsgeschichten, sprechen Sie darüber, was sie dazu bringen, und stellen Sie sicher, dass unsere Schätzungen gut sind.

    Wir werden bei Bedarf die Geschichten neu einschätzen - wie sagen wir, wir hätten vor etwas Monaten geschätzt, und nachdem wir uns erkannt haben, was eine ähnliche Geschichte tatsächlich genommen hat, können wir uns einverstanden, um erneut zu schätzen. (Wir verwenden uneinheitslose Story Points < / a> übrigens, und wir Schätzen Sie keine Aufgaben ).

    Wenn das PO auch neue Geschichten hinzugefügt hat, die er anfühlt, ist die hohe Priorität, dies ist die Zeit, um sie zu schätzen.

    weil wir bis zum nächsten Tag keine Geschichte auswählen, gibt dieser Prozess dem Po ein wenig mehr Zeit, um das endgültige Urteil zu machen, was in der nächsten Iteration am wichtigsten ist, und dies hat sich als sehr hilfreich erwiesen.

    Dieses Treffen neigt dazu, mit einigen Po und längst mit anderen zu laufen. (persönlich denke ich, dass es ein großer Geruchsindikator ist, wie Ihr Po tut)

    Story-Auswahl

    Holen Sie sich Ihre chris voss an, es ist Zeit zu verhandeln.

    Bei diesem Treffen nehmen wir die obersten Prioritätsgeschichten an und definieren einen dod für jeden. Wir verhandeln, was jeder dazu beinhaltet, Geschichten nach Bedarf zu spalten und zu kombinieren - bis wir uns alle auf unsere Sprint-Ziele einigen können.

    Wir profitieren viel davon, frische Gedanken zu haben, und diese gute Morgen-Energie für dieses Treffen - und wissen, dass wir Aufgaben tun werden, ermöglicht es uns, die Zeit zu verbringen, die wir brauchen, um wirklich gut zu verhandeln und unsere Verpflichtungen zu verstehen.

    Aufgaben

    okay, also werde ich der erste sein, der sagt, Aufgaben war mein am wenigsten favoriter Teil der Planung in unseren alten Treffen.

    Wir schlagen nie mit diesem Schritt. Wir haben versucht, Aufgaben bis zum Ende des Treffens zu sparen - aber wir wurden alle gerade dabei abgelassen und es war wirklich unproduktiv. Wir haben versucht, Aufgaben gleichzeitig als unser DOD während unserer Verhandlung zu definieren, aber wir fanden es zu ablenkend und zu umständlich - wir würden uns selbst verbrennen, bevor wir alle Geschichten auswählen. Es war auch sehr schwierig, den Fokus / den Gedanken zwischen der Schätzung, Verhandlung, Story Selection und Task Generati weiterzuwandeln

    auf.Wir hatten Schwierigkeiten und es saugte, und es machte unsere Meetings schrecklich.

    aber jetzt, , indem Sie das DOD an einem Tag definieren, und keine Aufgaben erledigen, bis zum nächsten, wir werden nicht ausgebrannt, wir sind immer im richtigen Mindstate, und es gibt unsEin guter Tag, um die Geschichte zu marinieren und wirklich durchzudenken und alle Aufgaben zu verstehen, bevor wir beginnen.

    Dies allein, IMHO, ist ein totaler Spielwechsler.

    alles zusammenlegen.

    Also, hier sieht unser Sprint-Zeremonie-Zeitplan jetzt aus wie jetzt:

    • montag - täglicher Scrum -> Sprint Review
    • dienstag - täglicher Scrum -> Backlog-Pflege
    • Mittwoch - täglicher Scrum -> Auswahl der Geschichte
    • Donnerstag - täglicher Scrum -> Aufgaben
    • Freitag - täglicher Scrum -> Retrospektive

    Es ist wirklich gut für uns gearbeitet. Wenn Sie es einen Schuss geben, würde ich gerne hören, was Sie denken.

    Wir haben einen wöchentlichen Sprint mit einem einstündigen Treffen, in dem wir den vorherigen Sprint diskutieren, was übrig bleibt und dann zur Planung der nächsten Woche weitergegeben wird. Alles innerhalb einer Stunde.

    Dies ist natürlich, weil wir herausgefunden haben, dass in unserem Fall nach dem Scrum zu strengstens nur zu viel Zeit verschwenden würde.Das ist, weil die meisten Geschichten bereits mit unseren Teammitgliedern diskutiert werden, wenn der Anforderer die Benutzergeschichte erstellt.

    Ich sage nur, dass, wenn Ihr Team, wenn Ihr Team die Planung von Treffen entscheidet, wahrscheinlich einige der "Regeln" des Scrums loslassen sollten.

    Diese Frage wurde umfassend beantwortet, aber nur eine Sache ist erforderlich, um es zu arbeiten und Spaß zu machen.

    Geben Sie dem Team Macht. - I.E. Machen Sie sie an Dingen, die sie denken, ist das Wichtigste.

    Lizenziert unter: CC-BY-SA mit Zuschreibung
    scroll top