Agile Entwicklung für Einsteiger: Scrum-Rollen, Events und Artefakte im ersten Sprint

Projekte & Entwicklung

Agile Entwicklung für Einsteiger: Scrum-Rollen, Events und Artefakte im ersten Sprint

Wer agile Entwicklung neu lernt oder zum ersten Mal in ein Scrum-Team kommt, versteht mit dieser Vorlage für Einsteiger die 3 Rollen, 5 Events und 3 Artefakte und fährt den ersten Sprint. Auf dem Whiteboard stehen die Grundidee der agilen Entwicklung, der Ablauf eines Zwei-Wochen-Sprints in 5 Schritten, drei Rahmen für die 3 Rollen, drei Rahmen für die 3 Artefakte, eine Übersicht der 5 Events, vier MoSCoW-Spalten für die Auswahl dieses Sprints und ein KPT-Rückblick. Das Aufgabenboard hat fünf Spalten - Product Backlog, Sprint Backlog, In Arbeit, Wartet auf Review und Fertig - und startet mit 4 Hauptaufgaben und 12 Teilaufgaben, von den Begriffen bis zu Review und Retrospektive, alle offen. Wer ohne Kenntnis von Scrum einsteigt, verliert schnell den Anschluss an die Begriffe. Gehen Sie dieses Board für einen Sprint von oben nach unten durch, dann wissen Sie auch, was Sie im Daily sagen. Anders als ein Board für eingespielte Teams geht es hier um die Begriffe und den ersten Durchlauf.

0 Likes 0 Kopien Autor: WeProcess
agile Entwicklung Scrum Sprint Entwicklungsteam Einsteiger
Kostenlos registrieren und diese Vorlage nutzen

Mit einem kostenlosen Konto können Sie diese Vorlage aus dem Marktplatz kopieren

Whiteboard-Vorschau

Vorschaumodus Agile Entwicklung für Einsteiger: Scrum-Rollen, Events und Artefakte im ersten Sprint

Whiteboard-Vorschau

1. Was agile Entwicklung ist (in kurz... 2. Ablauf des Zwei-Wochen-Sprints (da... 3. Product Owner 4. Scrum Master 5. Entwickler 6. Product Backlog 7. Sprint Backlog 8. Increment 9. Die 5 Events auf einen Blick Starter-Board für... So geht es: (1) G... Definition of Don... Rollen und Abspra... Hindernisse und P... Erkenntnisse und ... In einem SatzIn etwa zwei Wochen etwas Lauffähiges bauen und zeigen,Rückmeldungen einholen und nachbessern. Das immer wieder. Unterschied zur bisherigen Arbeitsweisez. B. nicht erst alle Anforderungen festschreiben, sonderndie Reihenfolge festlegen und von oben in kleinen Schritten bauen. Die Reihenfolge darf sich ändern. Was das bringtz. B. alle zwei Wochen ist etwas Echtes zu sehen, eine falsche Richtungfällt also binnen zwei Wochen auf. Nachgearbeitet wird nur ein Sprint. 1. Sprint PlanningErster Tag des Sprints. Mit MoSCoW auf Board 2. Entwicklung (zwei Wochen)Nur das Ausgewählte bauen. Auch wenn ein neuer Wunsch kommt, gehört er grundsätzlich nicht in diesen Sprint. z. B. nur die 3 Login-Einträge mit 13 Punkten bearbeiten. 3. Daily Scrum (täglich 15 Minuten)An jedem Tag dieser zwei Wochen 15 Minuten zur festen Uhrzeit. Jede Person sagt, was sie gestern getan hat, was sie heute tut und wo sie hängt. Das läuft täglich parallel zur Entwicklung. z. B. jeden Morgen um 10 Uhr im Stehen. 4. Sprint ReviewLetzter Tag. Den Beteiligten etwas Lauffähiges zeigen und Rückmeldungen einholen. Höchstens 2 Stunden. Nicht Folien, sondern die Oberfläche zeigen. z. B. die neue Login-Maske live bedienen. 5. RetrospektiveDirekt nach dem Review. Nicht auf das Gebaute schauen, sondern auf die Arbeitsweise. Höchstens 1,5 Stunden. Mit KPT auf Board Entscheidet, was zuerst gebaut wird Verantwortet die Reihenfolge im Product Backlog z. B. entscheidet, dass die Login-Verbesserung zuerst kommt Ansprechperson bei Unklarheiten zum Inhalt Achtet darauf, dass die Arbeitsweise eingehalten wird Räumt Hindernisse aus und wahrt die Zeiten der Events z. B. nimmt einen Zwischenwunsch an und terminiert ihn neu Gibt keine Anweisungen und ist nicht zwangsläufig eine Führungskraft Die Bauenden, einschließlich Entwurf, Umsetzung und Test Was in zwei Wochen machbar ist, schätzen die Entwickler selbst z. B. drei Personen teilen sich den Sprint Backlog Entwickler ist ein Rollenname, keine Berufsbezeichnung Alles Gewünschte, sortiert nach Reihenfolge der Umsetzung Oben heißt früher. Die Reihenfolge setzt der Product Owner z. B. Login-Verbesserung / Benachrichtigungen / Suche im Admin Eine Liste ohne Ende. Sie darf unterwegs wachsen Nur das, was in diesen zwei Wochen entstehen soll Im Planning gewählt, unterwegs kommt nichts hinzu z. B. die 3 Login-Einträge mit zusammen 13 Punkten Hier ist auch zu sehen, wer was übernommen hat Das Lauffähige, das am Ende der zwei Wochen vorliegt Was die Definition of Done (die vorab im Team vereinbarten Bedingungen, ab wann etwas fertig heißt) nicht erfüllt, zählt nicht dazu z. B. die Login-Verbesserung samt Test und Abnahme Genau das wird im Sprint Review gezeigt Was passiert Wer nimmt teil Zeitrahmen Sprint SprintDer Zwei-Wochen-Rahmen für die anderen vier. Er wird nie verlängert. Das ganze Scrum-Team(Product Owner, Scrum Master, Entwickler) Zwei WochenFest, höchstens ein Monat Planning Sprint PlanningAuswählen, was in zwei Wochen entsteht, und den Sprint Backlog bilden. Das ganze Scrum-Team Bis 4 StundenVormittag des ersten Tages Daily Scrum Daily ScrumSagen, was gestern war, was heute ansteht und wo es hakt. Entwickler(die beiden anderen Rollen hören zu) 15 MinutenTäglich, gleiche Zeit und gleicher Ort Review Sprint ReviewLauffähiges zeigen und Rückmeldungen einholen. Oberfläche statt Folien. Scrum-Team und Beteiligte(Auftraggeber, Nutzende) Bis 2 StundenAm letzten Tag Retrospektive Sprint-RetrospektiveNicht auf das Gebaute schauen, sondern auf die Arbeitsweise. Das ganze Scrum-Team Bis 1,5 StundenDirekt nach dem Review 10. Auswählen, wa... Must (unverzichtbar) Nur das, ohne das das Sprintziel nicht erreichbar ist.z. B. den Fehler beheben, dass die Mail zum Zurücksetzen nicht ankommt Should (wichtig) Wichtig, aber das Ziel hält auch, wenn es diesmal entfällt.z. B. unverständliche Fehlermeldungen neu formulieren Could (wenn Zeit bleibt) Kommt in den Sprint, fliegt aber bei Zeitmangel als Erstes heraus. Ohne diesen Punkt hält das Ziel.z. B. das Logo auf der Login-Maske austau… Won't (diesmal nicht) Bewusst nicht gemacht. Nicht löschen, sondern im Product Backlog (Board #6) lassen.z. B. Benachrichtigungen und Suche im Admin auf einen späteren Sprint schieben 11. Rückblick auf... Keep (beibehalten) Seit das Daily fest um 10 Uhr liegt, sind alle vollzählig dabei Weil Hindernisse sofort genannt wurden, war die Blockade in einem halben Tag weg Problem (nicht gelungen) Von den gewählten 13 Punkten wurden 5 in zwei Wochen nicht fertig Zwischenwünsche ließen sich nicht ablehnen, der Sprint Backlog wuchs Try (als Nächstes testen) Den nächsten Sprint mit 8 Punkten beginnen und nur bei Luft aufstocken Zwischenwünsche nimmt zuerst der Scrum Master entgegen
100%

Zum Verschieben ziehen, zum Zoomen scrollen

Inhalt des Aufgabenboards

Product Backlog 16 Einträge

Scrum-Begriffe
Sprint 1 planen
Daily halten
Review und Retro
3 Rollen notieren
5 Events ordnen
3 Artefakte prüfen
Termine festlegen
Backlog füllen
Nur 2 Wochen
Gestern und heute
Hindernisse nennen
Karten bewegen
Lauffähiges zeigen
Feedback ins Backlog
Ein Try aus KPT

Sprint Backlog 0 Einträge

In Arbeit 0 Einträge

Wartet auf Review 0 Einträge

Fertig 0 Einträge