Skip to content

Scrum Primer

Jump to bottom
robme91 edited this page Nov 9, 2014 · 9 revisions

#Scrum Info

####Scrum :

  • Entwicklunsg-Framework für iterative Projektentwicklug durch Teams
  • Entwicklung wird in Arbeitszyklen geteilt

####Sprint:

  • Entwicklungszyklus
  • Sprintlänge wird zu Beginn festgelegt
  • alle Teams am gleichen Projekt, gleiche Sprintlänge
  • maximal 4 Wochen Sprintlänge (meistens 2 Wochen)
  • niemals Verlängerung, Sprints enden zu einem bestimmten Zeitpunkt egal ob fertig oder nicht

####Crossfunctional Team:

  • funktionsübergreifendes Entwickler Team
  • meistens 7 Personen

####Items:

  • Kundenanforderungen(customer requirements) in priorisierter Liste
  • Items(Einträge) werden zu von Team am Anfang eines Sprints ausgewählt und zu einem Ziel zusammengefasst
  • während Sprint keine neuen Items hinzufügen

##Scrum Roles

Scrum Team besteht aus 3 Parteien:

  • Product Owner
  • Team
  • Scrum Master

####Product Owner (PO):

  • verantwortlich für:
    • Übertragung von Product Features in priorisierte Liste
    • Entscheidung wichtigste Items für nächsten Sprint
    • Wert der Arbeit Return on Investment(ROI)
  • nur eine/n Product Owner
  • kann der Kunde sein oder ein interner Mitarbeiter der die Rolle stellvertretend für eine Zielgruppe übernimmt

####Team:

  • Entwicklungs-Team
  • erstellt das vom PO vorgegebene Produkt
  • funktionsübergreifend, alle für das Produkt nötigen Expertisen sollten vorhanden sein
  • managed sich selbst
    • Aufgaben verteilung
    • wie viele von den vorgegebenen Items in einem Sprint erstellt werden
  • selbst lernend, Teammitglieder passen sich Aufgaben an und Entwickeln Fähigkeiten weiter/ neu

####ScrumMaster:

  • hilft Produktgruppe Scrum zu lernen/anzuwenden
  • nicht der Vorgesetzte
  • schützt vor äußeren Störungen
  • hilft bei Einführung neuer Entwicklungstechniken
  • hilft bei allen Problemen eine Lösung zu finden

##Product Backlog

  • priorisierte Liste von Items
  • kundenorientierte Features
  • technische Verbesserungen
  • Forschung/Recherche
  • bekannte Defekte
  • besteht/entwickelt sich über das gesamte Projekt
  • einzige Darstellung von allem was Team jemals liefern könnte
  • beinhaltet keine User Stories, sondern Items!!
    • Items können als User Stories oder ähnliches formuliert sein
  • auf Kunden Mehrwert achten

####Detailed appropriately:

  • höher priorisierte Items sollten detaillierter beschrieben werden
  • z.B. vorderen 10% des Backlogs gut analysierte kleine Items, Rest eher grob formuliert

####Estimated:

  • Aufwand und technisches Risiko geschätzt werden für jedes Item
  • möglichst nach jedem Sprint neue Schätzung → durch neue Infos genauer

####Emergent:

  • nach jedem Sprint können Items im Backlog hinzugefügt, verfeinert, angepasst, herausgenommen werden
  • Product Owner passt also Backlog nach neuen Ideen Aktionen Einschätzungen immer wieder an

####Prioritized:

  • Items on Top vom Backlog sollen am höchsten priorisiert sein
  • höchst priorisierte Items sollten nach Kosten/Nutzen (bang for your buck) geliefert werden

####bang for your buck:

  • bang → buisness value (Geschäftswert)
  • buck → Kosten

####guesstimate:

  • Schätzung aus dem Bauch heraus

####Story Points:

  • Technik für Aufwandsschätzung
  • relative Größen (z.B. Fibonacci Zahlen)

####Velocity:

  • Durchschnittswert der pro Sprint geschafften Points
  • gleiche Maßeinheit wie bei Story Points verwenden

####Actionable Size:

  • handhabbare Größe, bezogen auf Items

##Sprint Planning

  • 2 Teile, „wie“ und „was“

####Participants:

  • Teilnehmer:
    • komplettes Scrum Team
    • im zweiten Teil ist der PO optional

####Sprint Planning Part One(was)

  • PO und Team begutachten die hoch priorisierten Items des Backlogs
  • Ziele und Kontext der Items → Team bekommt Einblick in die Gedanken des PO
  • was braucht der PO und warum wird es gebraucht
  • Sprint Goal kann festgelegt werden

####Sprint Planning Part Two(wie)

  • wie sollen die abgesprochenen Backlogeinträge implementiert werden
  • Team geht von oben nach unten Backlog und entscheidet wie viele der Items es im Sprint fertig stellen kann
  • Items mit niedriger Prio. können mit Items hoher Prio. zusammengelegt werden
  • durch Story Points oder ähnliches Arbeitsaufwand abschätzen

####Sprint Goal

  • anvisiertes Ziel
  • etwas Fertiges liefern

####Sprint Backlog

  • To Do Liste des Sprints

####forecast

  • Prognose was bis zum nächsten Sprint Meeting voraussichtlich geschafft wird

####Scrum Board

  • Übersichtsboard mit Arbeitsaufträgen, Verteilung etc. (bei uns JIRA)

####Daily Scrum

  • 15 minütiges Meeting
  • jeden Morgen
  • alle Team Mitglieder auf neusten Stand bringen
  • evtl. Probleme mitteilen

####Sprint Burndown Chart:

  • zeigt wie viel Arbeit noch zu tun ist bis zum Sprint Goal
  • idealerweise ein Graph der jeden Tag weiter nach unten zeigt

Sprint Review

  • Software live vorführen
  • keine Präsi/Folien
  • dient zum inspizieren und anpassen des Produktes

##Sprint Retrospective

  • Austausch über Prozesse und Arbeitsumgebung
  • was hat funktioniert, was nicht

##weiteres

####done

  • vollständig ein goal gelöst

####Estimated Work Remaining

  • Schätzung der Rest Arbeitszeit für ein Item
  • nach jedem Arbeitstag aktualisiert

####Increment

  • Produktfunktionalität die während des Sprints entwickelt wird

####Stakeholder

  • jemand mit Interesse am Ergebnis des Projektes, weil er es bezahlt, einsetzen will, mitarbeitet etc. interne / externe stakeholder

####Timebox

  • festgelegter Zeitraum der normalerweise nicht verlängert werden kann(z.B. Sprint Länge)

Generelles

Technologien / Tools

meteor

Lösungen

etc

Sprints

Clone this wiki locally