Scrum Cheat Sheet (Jan 2012)
Upcoming SlideShare
Loading in...5
×
 

Scrum Cheat Sheet (Jan 2012)

on

  • 1,351 views

Anhand dieses Dokuments haben wir bis Februar 2012 unsere Produktentwicklung organisiert.

Anhand dieses Dokuments haben wir bis Februar 2012 unsere Produktentwicklung organisiert.

Das Cheat Sheet wurde gemeinsam mit dem Team erarbeitet und nach jeder Retrospective angepasst.

Statistics

Views

Total Views
1,351
Views on SlideShare
1,350
Embed Views
1

Actions

Likes
0
Downloads
10
Comments
0

1 Embed 1

http://www.slashdocs.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Scrum Cheat Sheet (Jan 2012) Scrum Cheat Sheet (Jan 2012) Presentation Transcript

    • Das ultimativeScrum-Cheat-Sheet des ultimativen flinc-Teams Version 11 (18.01.2012) Cheat  Sheet   Seite  1  
    • Das Scrum-Team Michael Alex, Andreas, Benedikt, Christian, Konstantin, Stefan Wir alle sind dafür Verantwortlich, den Scrum-Prozess einzuhalten! In den Nebenrollen: Laura, Philipp, Silvia Benni, Klaus Und was ist mit Android? Cheat  Sheet   Seite  2  
    • Verantwortlichkeiten Verwaltet das Product Backlog Entwickeln fertige, deployfähige Produktinkremente. -  Verfasst klar verständliche Dazu gehört Konzept, Design und Umsetzung. Product Backlog Items -  Ordnet die Items nach Business Value Organisieren sich selbst und tragen die Verantwortung -  Macht den Fortschritt für alle sichtbar für die Funktionsfähigkeit des Produktes. Ist dafür verantwortlich, dass das Development Team Obwohl das Team aus unterschiedlichen Spezialisten sein Leistung bringen kann. besteht, liegt die Verantwortung immer beim ganzen Team Cheat  Sheet   Seite  3  
    • Definition of Done Wir als Development-Team legen fest, dass ein Produktinkrement fertig ist, wenn die folgenden Kriterien erfüllt sind: ü  Alle Akzeptanzkriterien sind erfüllt ü  Das Product Backlog Item wurde dem Product Owner vorgestellt, alle im Development Team haben das Item gesehen und Änderungswünsche eingebracht. ü  Das Product Backlog Item ist getestet ü  Das Product Backlog Item kann jederzeit deployed werden Cheat  Sheet   Seite  4  
    • Meetings Cheat  Sheet   Seite  5  
    • Sprint Planning Meeting Teilnehmer Leitung Dauer: 4 Std. Vorbereitung ü  Getränke, Gläser, Obst, Beamer, Stoppuhr, Stifte, Karteikarten (A7, A8) ü  Issues, die sich im letzten Sprint ergeben haben, wurden vom Team aufgeschrieben und an den Product Owner übergeben (Neu!) Meeting 0: Rahmenbedingungen klären (5 min) 1.  Zeitplan festlegen. Wie lange geht der Sprint 2.  Fehlzeiten, Jour-Fixes und andere Termine erfassen Meeting 1: Was machen wir im nächsten Sprint (10 min) 1.  Product Owner stellt Product Backlog Items vor 2.  Development-Team prognostiziert welche Issues sie im Sprint umsetzen können 3.  Development-Team prognostiziert welche Product Backlog Items (Storys) sie im Sprint umsetzen können 4.  Es wird ein gemeinsames Sprint-Ziel definiert Meeting 2: Workshop - Wie werden die ausgewählten Ziele umgesetzt 1.  Das Development-Team organisiert sich im Wie-Meeting selbst. 2.  Zu jedem gewählten Item werden Akzeptanzkriterien / Ziele abgestimmt. 3.  Wie wird die Story umgesetzt? Es werden Tasks aufgeschrieben, die max. 1 Tag lang sind. Dazu können Gruppenarbeiten und kleine Workshops gemacht werden. 4.  Jede Story erhält eine Ownership plus eine Supportership. Cheat  Sheet   Seite  6  
    • Daily Scrum Teilnehmer Leitung Dauer: 15 min Während des Daily Scrums beantwortet jedes Teammitglied diese drei Fragen: 1.  Welche Tasks habe ich seit dem letzten Daily Scrum fertiggestellt 2.  Welche Tasks werde ich bis zum nächsten Daily Scrum fertigstellen 3.  Was hindert mich am Ausführen meiner Arbeit? Außerdem: Welche Tasks sind neu im Sprint Backlog? Cheat  Sheet   Seite  7  
    • Sprint Review Teilnehmer Leitung Dauer: 2 Std. Vorbereitung ü  Getränke, Gläser, Obst, Beamer, Stoppuhr, Stifte, Karteikarten (A7, A8) Ablauf 1.  Product Owner stellt Akzeptanzkriterien der Story vor 2.  Development-Team präsentiert die Umsetzung Für jede Story 3.  5-10 Minuten Diskussion wiederholen 4.  Product Owner nimmt die Story ab oder weist sie zurück 5.  Development-Team präsentiert umgesetzte Issues 6.  Development-Team berichtet über aufgetretene Probleme 7.  Product Owner gibt Überblick über das Product Backlog. Was steht als nächstes an? Wie liegen wir im Zeitplan? Allgemeine Verhaltensregeln •  Keine Detaildiskussionen •  „Ehrliche“ Präsentationen •  Gefundene Bugs und Issues werden vom Development-Team direkt auf Zettel notiert und in das Product Backlog einsortiert Cheat  Sheet   Seite  8  
    • Sprint Retrospective Teilnehmer Leitung Dauer: 90min Die Retrospective findet alle 2 Sprints nach dem Review statt. Der genaue Ablauf variiert und wird im Meeting festgelegt. Ziele des Meetings: -  Reflektion des letzten Sprints. Was lief gut? Was kann verbessert werden? -  Erarbeiten von konkreten Verbesserungen -  Erarbeiten eines Plan wie die Verbesserungen umgesetzt werden Die erarbeiteten Verbesserungen müssen für alle sichtbar im Büro angebracht werden. In der folgenden Retrospective muss überprüft werden ob die Verbesserungen umgesetzt wurden und sich etabliert haben. Cheat  Sheet   Seite  9  
    • Estimation Meeting Es gibt kein gesondertes Estimation / Planning Poker Meeting mehr. Stattdessen wird die Estimation in den Konzept-Workflow mit eingebunden. Das erste Rating findet nach dem Grobkonzept statt. Das zweite Rating findet nach dem Design statt. Es wird immer der Gesamtaufwand bewertet. D.h. beim 1.Rating Feinkonzept, Design, Umsetzung. Beim 2.Rating nur Umsetzung. Das Rating wird in Personentagen nach der Fibonnacci-Reihe geschätzt. 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 Ein Sprint hat 49,5 Personentage (9 Tage * 5 1/2 Personen) Cheat  Sheet   Seite  10  
    • Prozesse Cheat  Sheet   Seite  11  
    • Konzept-Workflow 1 Grobkonzept 2 Feinkonzept 3 Techn. Konzept 4 DesignZiel: Ziel: Ziel: Ziel:Funktion und Umfang Zustände und Inter- Techn. Umsetzung Alle Elementesind verständlich aktionen sind definiert beschlossen sind gestaltetDefinition of Done: Definition of Done: Definition of Done: Definition of Done:- User Stories - Wireframes aller Zustände - Dokumentation - Alle Elemente gestaltet- Scribbles - Akzeptanzkriterien - Rücksprache mit Designer - Grafiken sind exportiert- Textbeschreibung - Interaktionen als Kommentar - Synchron mit Feinkonzept- Rating - Finale Texte in DE/EN - Re-Rating Finales Konzept Der Fortschritt des Konzeptes wird im Product Backlog mit farbigen Punkten gekennzeichnet Cheat  Sheet   Seite  12  
    • i18n Workflow Konzeption Regel 1: DE und EN werden intern während des Feinkonzepts finalisiert Regel 2: Die finalen dt. Texte werden in die Konzept-Ordnerstruktur als de.rtf eingepflegt Regel 3: Oft gebrauchte Begriffe oder Formulierungen werden im Term Base von WebTranslateIt festgehalten 2 Feinkonzept Konzepter + -> Alex (QA) -> Sabine -> Alex (QA) -> de.rtf (Dropbox)   Team Alex im Urlaub: Konzepter -> Silvia (QA) -> Sabine -> Silvia (QA) -> de.rtf (Dropbox)   de.rtf -> Sabine -> Silvia (QA) -> Alex (QA) -> en.rtf (Dropbox)   Alex im Urlaub: de.rtf-> Sabine -> Silvia (QA) -> en.rtf (Dropbox) Silvia im Urlaub: de.rtf -> Sabine -> Alex (QA) -> en.rtf (Dropbox)   Cheat  Sheet   Seite  13  
    • i18n Workflow Umsetzung Regel 1: Devs arbeiten nur mit DE als Masterlanguage Regel 2: Übersetzt wird nur in WebTranslateIt Regel 3: Für jede Sprache gibt es 1 Übersetzer und 1 Korrektor. Jeder Übersetzer/Korrektor erhält eine Einladung zu WebTranslateIt. Regel 4: Fallback für alle nicht deutschstämmigen Sprachen ist EN. Umsetzung 1.  Developer updated die de.yml 2.  Alex aktualisiert WebTranslateIt und pflegt die engl. Übersetzungen ein 3.  Alex informiert die Übersetzungsteams für andere Sprachen, dass neue Übersetzungen vorliegen 4.  Übersetzer pflegen ihre Übersetzungen ein (Untranslated -> Unproofread) 5.  Korrektoren setzen die Übersetzungen auf Proofread und korrigieren gegebenenfalls. Bei Fragen und Unklarheiten wird das Discussion Tool von WebTranslateIt genutzt. Alex ist der Anlaufpunkt für alle Übersetzer/Korrektoren. 6.  Alex kontrolliert die Übersetzungen ein letztes mal, exportiert die Project File und updated die Repositories. Cheat  Sheet   Seite  14  
    • Support-Workflow 1st-Level-Support: Florian, Stefan, Kathrin 2nd-Level-Support: Silvia (Alex als Vertretung) Dev-Support: Alex & Support Chat Silvia ist dafür verantwortlich alle Supportanfragen an das Dev Team via Lighthouse zu überprüfen und ggf. an Alex weiterzuleiten . Alex ist dafür verantwortlich die Supportanfragen innerhalb des Development-Teams zu verteilen. Siehe „Bug/Issue-Workflow“. Wenn Alex im Urlaub ist, übernimmt Silvia diese Aufgabe und weist in Absprache mit einem DEV die Tickets den DEVs zu. Support-Chat Während der Arbeitszeit befindet sich immer mindestens eine Person des Development-Teams im Campfire-Room „Tech. Support“. Cheat  Sheet   Seite  15  
    • Supportprozess – Allgemein (1 s t Level) User Anfrage Zendesk Muss diese Anfrage bearbeitet werden? Nein (Automatisierte Antwort ist ausreichend) Solved Ja Ist die Anfrage Nein Rückfragen verständlich? Ja Nein Ist es eine technische Frage? Ja Habe ich alle benötigten Infos Nein Ja Ist es ein Feature Lighthouse ticket anlegen und request? Ja Excel Liste 2nd Level Support zuweisen. eintragen Nein Kann das Ticket geschlossen werden? Kann die Frage von mir beantwortet Ja werden? Ja User Informieren Nein Nein Nicht Public Comment mit allen relevanten Infos schreiben und dem 2nd Level Support zuweisen. User informieren und täglich auf Updates prüfen. Cheat  Sheet   Seite  16  
    • Bug/Issue-Workflow Regel 1: ALLE Arbeiten müssen im Sprint Backlog sichtbar gemacht werden Regel 2: Siehe Regel 1 Panic Kritisch? Critical Ja Wird als nächste Task umgesetzt Mode Swimlane + Lighthouse Nein Issue Wird innerhalb des aktuellen Sehr wichtig? Ja Swimlane Sprints umgesetzt + Lighthouse Nein Product Backlog oder Wird in kommenden Sprints umgesetzt Lighthouse Cheat  Sheet   Seite  17  
    • Definition: Bugs, Issues, Stories, Epics Critical Bugs: Kritischer Fehler => Lighthouse, Critical Swimlane. Bugs & Issues: Kleine Änderungen oder Verbesserungen (Dauer max. 1 Tag) => Lighthouse, ggf. Issue-Swimlane Stories: Neue Features (Dauer max. 1 Sprint) => Product Backlog Epics: Übergeordnete Konzepte. Cluster für Stories Cheat  Sheet   Seite  18  
    • QA/Testing Grundsätze Webseite/API: •  Stories werden während deren techn. Umsetzung und nach der Umsetzungsphase auf Staging getestet •  Nach API Änderungen müssen die Clients weiterhin funktionsfähig sein Clients: •  Stories/Features werden als Lighthouse Tickets mit allen nötigen Daten den Client Entwicklern zugewiesen •  Die Änderungen müssen auch auf Production getestet werden Issues (LH Tickets): •  Issues werden in Form von Lighthouse Tickets festgehalten •  Das Issue muss reproduziert werden können •  Nur ein Issue pro Lighthouse Ticket •  Das Lighthouse Ticket beinhaltet immer die Testumgebung und alle nötigen IDs zum Nachvollziehen (ggf. die App- und Firmware-Version) •  Issues werden mit Prio „normal“ eingestellt. Prio „High“ ist eine Ausnahme und sollte vorher persönlich kommuniziert werden. •  Tickets werden nur getestet, wenn sie „committed“ sind Cheat  Sheet   Seite  19  
    • QA bei Stories 1 Grobkonzept 2 Feinkonzept 3 Techn. Konzept 4 Design Ziel: Ziel: Ziel: Ziel: Freigabe für Feinkonzept Freigabe für techn. Techn. Umsetzung Freigabe zur Umsetzung Konzeption und Design beschlossen ToDo: ToDo: ToDo: ToDo: -  Check: User Stories? -  Check: Wireframes aller -  Check: Layout liegt als PSD vor -  Check: Techn. Umsetzung -  Check: Scribbles? Zustände? mit allen nötigen Elementen? synchron mit Feinkonzept und -  Check: Textbeschreibung? -  Check: Eindeutige -  Check: Grafiken exportiert? Akzeptanzkritieren? -  Präsentation und Abnahme im Akzeptanzkriterien? -  Check: Layout synchron mit -  Check: Techn. Umsetzung Rating -  Opt: Cucumber User Stories Feinkonzept und dokumentiert? -  Check: Interaktionen als Akzeptanzkriterien? Kommentar? -  Opt: Usabilitytests -  Check: Texte für DE/EN? -  Präsentation und Abnahme im -  Opt: Interaktionsdiagramm? Re-Rating Pre Production Post Production 5 Umsetzung 6 Review 7 8 Deploy Deploy Ziel: Ziel: Ziel: Ziel: Freigabe für Review Freigabe für Production Alle Issues gefixt, Story Server ist stabil, es gab ToDo: Deploy kann deployed werden keine neuen Konflikte -  Check: Layout umgesetzt? ToDo: -  Check: Abnahme durch DEV- ToDo: ToDo: -  Präsentation auf Staging und Buddy? -  Opt: Lighthouse Tickets wurden -  Check: Funktionale Abnahme im Review -  Opt: Pull Request auf „committed“ gesetzt und Änderungen auf Production -  Check: Funktionale -  Check: Crossbrowser? ALK zugewiesen getestet? Änderungen an Team -  Check: Auf Staging deployed? -  Opt: Production Server in -  Opt: Issues wurden als -  Funktionaler Test auf Staging kommuniziert? Maintenance Mode versetzen Lighthouse Tickets eingestellt -  Opt: Crossplattform -  Opt: Issues wurden als und dem zuständigen -  Check: Dokumentiert? Lighthouse Tickets eingestellt Entwickler zugewiesen -  Opt: Änderungen an Externe und dem zuständigen (Entwickler) kommuniziert Entwickler zugewiesen -  Opt: Unit/Integrations/ Cucumbertests -  Opt: PTS erweitern/updaten Cheat  Sheet   -  Check: Alle Tasks in QA? Seite  20  
    • QA bei Stories (Workflow): Part 1 (techn. Sicht) 2 Feinkonzept 5 Umsetzung Pending Fail Cucumber User Cucumber User Story Steps + Story Fail Pass Pass until Cucumber User RSpec Code Story + RSpec ... ... Pull Request Not OK Not OK Dev QA durch Buddy OK QA Part 2 Deploy Staging Merge OK Done Konzepter Developer Cheat  Sheet   Seite  21  
    • QA bei Stories (Workflow): Part 2 (Nutzersicht) Story Story Alle Tasks Tasks offen in QA Deploy Staging Keine Story Probleme? Ja Alle Tasks Review in Done nein Keine Für jedes Issue ein Ticket erstellen/ Probleme? Nein Ticket updaten und dem Für jedes Issue ein Ticket erstellen/ zuständigen DEV assignen Ticket updaten und dem zuständigen DEV assignen Bugfixing + Deploy Staging Bugfixing + Ja Deploy Staging Alle Tickets Pre Production Alle Tickets Nein Ja Ja Nein gelöst? Deploy Test gelöst? Staging Server Deploy Production Post Production Keine Deploy Test Probleme? Nein Production Server Done Ja Cheat  Sheet   Seite  22  
    • QA bei Lighthouse Tickets (Workflow) Mit Fehlerbeschreibung an zuständigen Dev zurück assignen nein Deploy Staging + Assign ALK! Ticket Ticket Ticket Problem Ja Ticket new Open/wip committed gelöst? resolved Assign ALK! Ticket Problem Ticket Ja Invalid gelöst? Invalid nein Mit Begründung an zuständigen Dev assignen Ticket Problem Ticket Ja hold gelöst? hold nein Mit Begründung an zuständigen Dev assignen Staging Server Cheat  Sheet   Seite  23  
    • QA Web vs. Client (Workflow) Web Deploy Staging Alle 2 Wochen Review/ Ticket/ Ticket/ Production Feature Feature Deploy Staging Server mit mehreren Browsern Client New build Releasezyklus Ticket Ticket Release Production Server mit mehreren Clients Testumgebung Cheat  Sheet   Seite  24  
    • SCSS-Workflow 1.  Layoutelemente werden zuerst im Styleguide umgesetzt und dort Crossbrowser getestet 2.  STZ kontrolliert das Ergebnis und gibt die Elemente zum Einbau frei 3.  Danach werden die Elemente in der View zusammengesetzt Cheat  Sheet   Seite  25  
    • Sonstiges Cheat  Sheet   Seite  26  
    • Product Backlog Zu wenige Impediments RAM! Issues Stehen ab sofort im Lighthouse Storys EPIC! EPIC! EPIC! Als Nutzer Als Nutzer Als Nutzer möchte ich! möchte ich! möchte ich! Als Nutzer Als Nutzer möchte ich! möchte ich! Die Karteikarten sind horizontal und vertikal geordnet. Die farbigen Punkte zeigen den Fortschritt im Konzept Cheat  Sheet   Seite  27  
    • Sprint Backlog Todo WIP QA Done Task! Critical Task! Task! Issues Task! Storys Als Nutzer Task! Task! möchte ich! Als Nutzer Task! Task! möchte ich! Als Nutzer Task! Task! möchte ich! Task! Task! Die Tasks in der Critical-Swimlane werden priorisiert abgearbeitet. Cheat  Sheet   Seite  28  
    • Kriterien für User Stories I – Independent N – Negotiable V – Valuable E – Estimable S – Small T – Testable CCC-Kriterien: Card, Conversation, Confirmation Benutzerrolle Ziel Grund Als Nutzer.. möchte ich.. damit.. Cheat  Sheet   Seite  29  
    • Kriterien für gute Tasks S – Specific M – Measurable A – Achievable R – Relevant T – Time-boxed Cheat  Sheet   Seite  30  
    • Änderungen Ab 18.08.2011 •  Verbesserter Konzept-Workflow •  Issue, Bug und Support-Workflow •  Estimation nach Personentagen •  Estimation-Meeting fällt in den Konzept-Workflow •  Retrospective alle 4 Wochen, bzw. nach Bedarf •  Strukturierteres Planning Meeting (kürzeres Was-Meeting) •  Strukturierteres Review Meeting (Leitung durch Product Owner) •  Company Backlog = Product Backlog •  Storys sind geordnet nicht priorisiert •  Sprint-Forecast statt Commitment •  Das Team verpflichtet sich alle Arbeiten sichtbar zu machen •  Keine Releases mehr im Product Backlog Cheat  Sheet   Seite  31