Scrum Cheat Sheet (Jan 2012)

Cheat Sheet Seite 1

Das ultimative Scrum-Cheat-Sheet

des ultimativen flinc-Teams

Version 11 (18.01.2012)

Cheat Sheet Seite 2

Das Scrum-Team

In den Nebenrollen:

Wir alle sind dafür Verantwortlich, den Scrum-Prozess einzuhalten!

Alex, Andreas, Benedikt, Christian, Konstantin, Stefan

Michael

Laura, Philipp, Silvia Benni, Klaus Und was ist mit Android?

Cheat Sheet Seite 3

Verantwortlichkeiten

Verwaltet das Product Backlog -  Verfasst klar verständliche

Product Backlog Items -  Ordnet die Items nach Business Value -  Macht den Fortschritt für alle sichtbar

Ist dafür verantwortlich, dass das Development Team sein Leistung bringen kann.

Entwickeln fertige, deployfähige Produktinkremente. Dazu gehört Konzept, Design und Umsetzung. Organisieren sich selbst und tragen die Verantwortung für die Funktionsfähigkeit des Produktes. Obwohl das Team aus unterschiedlichen Spezialisten besteht, liegt die Verantwortung immer beim ganzen Team

Cheat Sheet Seite 4

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 5

Meetings

Cheat Sheet Seite 6

Sprint Planning Meeting

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.

Teilnehmer Leitung Dauer: 4 Std.

Cheat Sheet Seite 7

Daily Scrum

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?

Teilnehmer Leitung Dauer: 15 min

Cheat Sheet Seite 8

Sprint Review

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 3.  5-10 Minuten Diskussion 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

Für jede Story wiederholen

Teilnehmer Leitung Dauer: 2 Std.

Cheat Sheet Seite 9

Sprint Retrospective

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.

Teilnehmer Leitung Dauer: 90min

Cheat Sheet Seite 10

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)


Prozesse


Definition of Done: - User Stories - Scribbles - Textbeschreibung - Rating

Definition of Done: - Alle Elemente gestaltet - Grafiken sind exportiert - Synchron mit Feinkonzept - Re-Rating

Konzept-Workflow

1 Grobkonzept 2 Feinkonzept

Definition of Done: - Wireframes aller Zustände - Akzeptanzkriterien - Interaktionen als Kommentar - Finale Texte in DE/EN

Ziel: Zustände und Inter-aktionen sind definiert

3 Techn. Konzept

Definition of Done: - Dokumentation - Rücksprache mit Designer

Ziel: Techn. Umsetzung beschlossen

Finales Konzept

Ziel: Funktion und Umfang sind verständlich

Der Fortschritt des Konzeptes wird im Product Backlog mit farbigen Punkten gekennzeichnet

4 Design

Ziel: Alle Elemente sind gestaltet


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

Konzepter +

Team

2 Feinkonzept

-> Alex (QA) -> Sabine -> Alex (QA) -> de.rtf (Dropbox)

de.rtf -> Sabine -> Silvia (QA) -> Alex (QA) -> en.rtf (Dropbox)

Alex im Urlaub: Konzepter -> Silvia (QA) -> Sabine -> Silvia (QA) -> de.rtf (Dropbox)

Alex im Urlaub: de.rtf-> Sabine -> Silvia (QA) -> en.rtf (Dropbox) Silvia im Urlaub: de.rtf -> Sabine -> Alex (QA) -> en.rtf (Dropbox)


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.


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“.


Supportprozess – Allgemein (1st Level)

Muss diese Anfrage bearbeitet werden?

Ist die Anfrage verständlich?

Ist es eine technische Frage?

Ist es ein Feature request?

Solved

Rückfragen

Excel Liste eintragen

User Informieren

Zendesk

Nicht Public Comment mit allen relevanten Infos schreiben und dem 2nd Level Support zuweisen.

Habe ich alle benötigten Infos

Lighthouse ticket anlegen und 2nd Level Support zuweisen.

Kann das Ticket geschlossen werden?

User informieren und täglich auf Updates prüfen.

Ja

Nein

Ja

Nein

Ja

Ja

Nein

Ja

Nein

Nein

Nein

Nein

Ja

Ja

User Anfrage

(Automatisierte Antwort ist ausreichend)

Kann die Frage von mir beantwortet werden?


Bug/Issue-Workflow

Regel 1: ALLE Arbeiten müssen im Sprint Backlog sichtbar gemacht werden

Regel 2: Siehe Regel 1

Panic Mode

Kritisch? Critical Swimlane + Lighthouse

Issue Swimlane + Lighthouse

Product Backlog oder Lighthouse

Sehr wichtig?

Ja

Ja

Wird als nächste Task umgesetzt

Wird innerhalb des aktuellen Sprints umgesetzt

Wird in kommenden Sprints umgesetzt

Nein

Nein


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


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


QA bei Stories

ToDo: -  Check: User Stories? -  Check: Scribbles? -  Check: Textbeschreibung? -  Präsentation und Abnahme im

Rating

1 Grobkonzept

Ziel: Freigabe für Feinkonzept

ToDo: -  Check: Wireframes aller

Zustände? -  Check: Eindeutige

Akzeptanzkriterien? -  Opt: Cucumber User Stories -  Check: Interaktionen als

Kommentar? -  Check: Texte für DE/EN? -  Opt: Interaktionsdiagramm?

2 Feinkonzept

Ziel: Freigabe für techn. Konzeption und Design

ToDo: -  Check: Techn. Umsetzung

synchron mit Feinkonzept und Akzeptanzkritieren?

-  Check: Techn. Umsetzung dokumentiert?

3 Techn. Konzept

Ziel: Techn. Umsetzung beschlossen

ToDo: -  Check: Layout liegt als PSD vor

mit allen nötigen Elementen? -  Check: Grafiken exportiert? -  Check: Layout synchron mit

Feinkonzept und Akzeptanzkriterien?

-  Opt: Usabilitytests -  Präsentation und Abnahme im

Re-Rating

4 Design

Ziel: Freigabe zur Umsetzung

ToDo: -  Check: Layout umgesetzt? -  Check: Abnahme durch DEV-

Buddy? -  Opt: Pull Request -  Check: Crossbrowser? -  Check: Auf Staging deployed? -  Funktionaler Test auf Staging -  Opt: Crossplattform -  Check: Dokumentiert? -  Opt: Änderungen an Externe

(Entwickler) kommuniziert -  Opt: Unit/Integrations/

Cucumbertests -  Opt: PTS erweitern/updaten -  Check: Alle Tasks in QA?

5 Umsetzung

Ziel: Freigabe für Review

ToDo: -  Präsentation auf Staging und

Abnahme im Review -  Check: Funktionale

Änderungen an Team kommuniziert?

-  Opt: Issues wurden als Lighthouse Tickets eingestellt und dem zuständigen Entwickler zugewiesen

6 Review

Ziel: Freigabe für Production Deploy

ToDo: -  Opt: Lighthouse Tickets wurden

auf „committed“ gesetzt und ALK zugewiesen

-  Opt: Production Server in Maintenance Mode versetzen

7 Pre Production Deploy

Ziel: Alle Issues gefixt, Story kann deployed werden

ToDo: -  Check: Funktionale

Änderungen auf Production getestet?

-  Opt: Issues wurden als Lighthouse Tickets eingestellt und dem zuständigen Entwickler zugewiesen

8 Post Production Deploy

Ziel: Server ist stabil, es gab keine neuen Konflikte


QA bei Stories (Workflow): Part 1 (techn. Sicht)

Feinkonzept Umsetzung 2 5

... ...

Cucumber User Story

Konzepter Developer

Steps Cucumber User Story

RSpec Code Cucumber User Story RSpec

Pull Request

Dev QA durch Buddy

Merge Deploy Staging QA Part 2

Done

+

+

Pending Fail

Fail Pass Pass

OK

OK

until

Not OK Not OK


QA bei Stories (Workflow): Part 2 (Nutzersicht)

Keine Probleme?

Für jedes Issue ein Ticket erstellen/Ticket updaten und dem

zuständigen DEV assignen

Story Tasks offen

Deploy Staging

Story Alle Tasks

in QA

Pre Production Deploy Test

Post Production Deploy Test

Ja

nein

Story Alle Tasks

in Done Review

Alle Tickets gelöst?

Ja

Keine Probleme?

Ja

Alle Tickets gelöst?

Nein

Für jedes Issue ein Ticket erstellen/Ticket updaten und dem

zuständigen DEV assignen

Staging Server

Production Server

Nein

Ja Nein

Keine Probleme? Nein

Done Ja

Deploy Production

Bugfixing + Deploy Staging

Bugfixing + Deploy Staging


QA bei Lighthouse Tickets (Workflow)

Ticket committed

Problem gelöst?

Ticket resolved

Ja Ticket Open/wip

Mit Fehlerbeschreibung an zuständigen Dev zurück assignen

Ticket Invalid

Ticket hold

Ticket new

Ticket Invalid

Ticket hold

Ja

Ja

Problem gelöst?

Problem gelöst?

nein

Deploy Staging + Assign ALK!

Mit Begründung an zuständigen Dev assignen

Mit Begründung an zuständigen Dev assignen

nein

nein

Staging Server

Assign ALK!


QA Web vs. Client (Workflow)

Web

Client

Testumgebung

Ticket/ Feature

Ticket

Staging Server mit mehreren Browsern

Production Server mit mehreren Clients

Ticket/ Feature

Ticket

Review/Production

Deploy

Release

Deploy Staging

New build Releasezyklus

Alle 2 Wochen


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


Sonstiges


Product Backlog

Als Nutzer möchte ich!



Impediments

Issues

Storys

Zu wenige RAM!

EPIC! EPIC!

Die Karteikarten sind horizontal und vertikal geordnet. Die farbigen Punkte zeigen den Fortschritt im Konzept



EPIC!

Stehen ab sofort im Lighthouse


Sprint Backlog


Critical

Issues

Storys

Task!

Die Tasks in der Critical-Swimlane werden priorisiert abgearbeitet.

Todo WIP QA Done

Task! Task!

Task!



Task! Task!

Task! Task!

Task! Task!

Task! Task!


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..


Kriterien für gute Tasks

S – Specific M – Measurable A – Achievable R – Relevant T – Time-boxed


Ä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

Technology

Scrum Cheat Sheet (Jan 2012)