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.

1. Das ultimative
Scrum-Cheat-Sheet
des ultimativen flinc-Teams
Version 11 (18.01.2012)
Cheat
Sheet
Seite
1

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

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

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
4

5. Meetings
Cheat
Sheet
Seite
5

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

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

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

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

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)
Cheat
Sheet
Seite
10

11. Prozesse
Cheat
Sheet
Seite
11

12. Konzept-Workflow
1 Grobkonzept 2 Feinkonzept 3 Techn. Konzept 4 Design
Ziel: Ziel: Ziel: Ziel:
Funktion und Umfang Zustände und Inter- Techn. Umsetzung Alle Elemente
sind verständlich aktionen sind definiert beschlossen sind gestaltet
Definition 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

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

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

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

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

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

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

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

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

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

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

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

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

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

26. Sonstiges
Cheat
Sheet
Seite
26

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

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

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

30. Kriterien für gute Tasks
S – Specific
M – Measurable
A – Achievable
R – Relevant
T – Time-boxed
Cheat
Sheet
Seite
30

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