Scrum

• priorisierte Übersicht über die in einem Sprint zu erledigenden Aufgaben / Tasks
• steht in Beziehung zu Items aus dem Product Backlog (i.d.R. 1 Item = n Tasks
• enthält eine Vorhersage der im Sprint abzuschließenden Arbeit, sowie einen Durchführungsplan
• Status wird durch das Team täglich aktualisiert
• Scrum Master kontrolliert Status und sorgt für die Einhaltung des Sprint Goals
• Taskboard: 4 Spalten: 1. Spalte User Stories, 2.-4. Spalte Tasks Offen / in Bearbeitung (WiP) / Erledigt (Done) (evtl. noch ToVerify) Markieren von nicht fertigen Tasks mit einem roten Punkt
• Consists of committed PBIs negotiated between the team and the Product Owner during the Sprint Planning Meeting
• Scope commitment is fixed during Sprint Execution
• Initial tasks are identified by the team during Sprint Planning Meeting
• Team will discover additional tasks needed to meet the fixed scope commitment during Sprint execution
• Visible to the team
• Referenced during the Daily Scrum Meeting
• Eigentum des Teams

• Specifies the what more than the how of a customer-centric feature
• Often written in User Story form
• Has a product-wide definition of done to prevent technical debt
• May have item-specific acceptance criteria
• Effort is estimated by the team, ideally in relative units (e.g., story points)
• Effort is roughly 2-3 people 2-3 days, or smaller for advanced teams
• hat einen "geschäftlichen Mehrwert"
• das Team muss einen Eintrag innerhalb eines Sprints erledigen können

anstelle Pflichtenheft: dynamische Liste der priorisierten User Stories, die vom Product Owner aufgenommen und priorisiert wurden

• enthält Schätzungen in Form von "Story Points"
• Product Backlog Einträge, die bald implementiert werden sollen, werden verfeinert
• Einträge können vom PO, vom Team oder von Stakeholdern kommen

Ein guter Product Backlog ist DEEP:

• D - detailed appropriately, angemessen detailiiert
• E - estimated, geschätzt
• E - emergent, entwickelt sich im Projekt weiter
• P - prioritized, priorisiert

• Visible to all stakeholders
• Constantly re-prioritized by the Product Owner
• Items at top are more granular than items at bottom
• Maintained during the Backlog Refinement Meeting

• Product Backlog
• Sprint Backlog
• Produktinkrement
• Burndown-Charts
  • Story-Burndown-Chart
  • Sprint-Burndown-Chart
• Impedient Backlog

Most Product Backlog Items (PBIs) initially need refinement because they are too large and poorly understood. 

• dauerhafte Aktivität während eines Srum-Projektes von allen Beteiligten
• Neu-Priorisierung
• Verfeinerung, Aufspillten, Verschmelzen von Einträgen
• Schätzen von Einträgen
• Einträge sollten immer vor einem Sprint aktualisiert worden sein
• 10% ihrer Zeit sollte das Team dafür Zeit haben

Lessons Learned

ist der Rückblick nach jedem Sprint, in dem das Team den Entwicklungsprozess und die 
Zusammenarbeit in der vorangegangenen Phase darauf hin analysiert, welche Dinge 
hinderlich und welche förderlich waren. Ziel ist es, die gewonnenen Erkenntnisse bereits 
im Projektverlauf umzusetzen, sodass ein kontinuierlicher Verbesserungsprozess 
entsteht.  

Time: 1h pro Sprintwoche

Each Sprint ends with a retrospective. At this meeting, the team reflects on its own process. They inspect their behavior and take action to adapt it for future Sprints. Dedicated ScrumMasters will find alternatives to the stale, fearful meetings everyone has come to expect. An in-depth retrospective requires an environment of psychological safety not found in most organizations. Without safety, the retrospective discussion will either avoid the uncomfortable issues or deteriorate into blaming and hostility. A common impediment to full transparency on the team is the presence of people who conduct performance appraisals. Another impediment to an insightful retrospective is the human tendency to jump to conclusions and propose actions too quickly. Agile Retrospectives, the most popular book on this topic, describes a series of steps to slow this process down: Set the stage, gather data, generate insights, decide what to do, close the retrospective.1 Another guide recommended for ScrumMasters, The Art of Focused Conversations, breaks the process into similar steps: Objective, reflective, interpretive, and decisional (ORID).2 A third impediment to psychological safety is geographic distribution. Geographically dispersed teams usually do not collaborate as well as those in team rooms. Retrospectives often expose organizational impediments. Once a team has resolved the impediments within its immediate influence, the ScrumMaster should work to expand that influence, chipping away at the organizational impediments. ScrumMasters should use a variety of techniques to facilitate retrospectives, including silent writing, timelines, and satisfaction histograms. In all cases, the goals are to gain a common understanding of multiple perspectives and to develop actions that will take the team to the next level.

am Ende eines Sprints ist ein Termin, in dem das Team die im Sprint umgesetzten 
Features beziehungsweise Tasks (=Produktinkrement) dem Product Owner und gegebenenfalls weiteren 
Stakeholdern demonstriert und der Product Owner diese abnimmt. 

Dauer: 1h je Sprintwoche

Feedback von User und Customer

nicht fertige Ergebnisse / CR in Product Backlog.

wegen der erzielten Ergebnisse wird das Product Backlog aktualisiert 

Hindernisse in Impedient Backlog

Teilnehmer können auch andere Stakeholder sein

• Was habe ich seit dem letzten Daily Scrum erreicht?
• Was plane ich, bis zum nächsten Daily Scrum zu erreichen?
• Was behindert mich bei der Arbeit (Impediments)?
• "aktueller Status"
• es werden keine Probleme gelöst.
• Nicht erledigte Tasks werden gesplittet
• Probleme werden notiert
• Product Owner und Scrum Master nehmen als passive Zuhörer Teil, Stekeholder ggfs. auch
• ggfs. Folge-Gespräche unter den Entwicklern
• Dauer: 15 Minuten
• führt zu Transparenz, Vertrauen und höheren Leistungsfähigkeit

• wichtigstes Artefakt
• jeder Sprint bringt ein Produktinkrement hervor
• muss qualitativ so hochwertig sein, dass es den Benutzern ausgehändigt werden kann
• muss der aktuellen Definition of Done entsprechen
• und in jedem Bereich vom PO abnehmbar sein

Zeitraum, in dem das potenziell auslieferbare Produktinkremente entwickelt werden. Sollte immer einen identischen Zeitraum umfassen (>= 1 Woche, <= 4 Wochen)

SMART

• "Specific": spezifisch genug, damit jeder verstehen kann, was sich dahinter verbirgt
• "Measurable": können wir feststellen, ob er erledigt ist?
• "Achievable": ist es (im Sprint) erreichbar?
• "Relevant": trägt er zur Realisierung der Story bei?
• "Timely" kann man schätzen, wie viel Aufwand seine Realisierung braucht?

• Teil2: Wie" sollen die Arbeit (=die User Stories) umgesetzt werden?
• Arbeit am Produktinkrement in Übereinstimmung mit der Definition of Done
• Das wie liegt in der Verantwortung des Teams
• Das was liegt in der Verantwortung des PO
• der PO kann an dem Meeting teilnehmen
• Ergebnis: Sprint Backlog: Liste an Dingen, die erledigt werden müssen
• Tasks (= Arbeitspakete) von max. 1 Tag, die auf dem Taskboard (Pinnwand) zusammen mit den User Stories vermerkt werden.

Teil 1: Welche Arbeit wird im Sprint erledigt?

• Kickoff: Vorstellung Product Backlog
• Definition Abnahmekriterien (Definition of Done) und Sprint-Ziel (zur Fokussierung)
• Product Owner macht einen Vorschlag, welche User Stories umgesetzt werden sollen
• Festlegung durch das Team wieviele der am höchsten priorisierten User Stories in einem Sprint umgesetzt werden sollen.
• Das Team übersetzt Features / Stories in Aufgaben (Tasks). Am Ende des Meetings steht ein abgestimmtes Sprint-Ziel, zu dem sich das Team commitet.

Dauer: 60 Minuten pro Sprint-Woche für das ganze Sprint Planning Teil 1 und Teil 2

• Product Backlog Verfeinerung / Refinement
• Sprint Planning Meeting1
• Sprint Planning Meeting2
• Daily Scrum
• Sprint Review
• Sprint Retrosperspektive Meeting

in this chronology.

All Scrum Meetings are facilitated by the ScrumMaster, who has no decision-making authority at these meetings.

• Cross-functional (e.g., includes members with testing skills, and often others not traditionally called developers: business analysts, domain experts, etc.)
• Self-organizing / self-managing, without externally assigned roles
• Negotiates commitments with the Product Owner, one Sprint at a time 
• Has autonomy regarding how to reach commitments 
• Intensely collaborative
• Most successful when located in one team room, particularly for the first few Sprints
• Most successful with long-term, full-time membership. Scrum moves work to a flexible learning team and avoids moving people or splitting them between teams.
• 7 ± 2 members
• updates the sprint backlog daily

• Schnittstelle zur "Außenwelt" / Product Owner
• kontrolliert Scrum Regeln und Prozesse
• verantwortlich für korrekte Umsetzung von Scrum
• beseitigt anfallende Hindernisse
• moderiert die Scrum-Meetings
• agiert als "Servant Leader" = dienende Führungsperson
• hat die Verantwortung über die Scrum-Dokumente (Product Backlog, Sprint Backlog, Burndown Charts)
• schützt das Team vor Einflüssen während des Sprints
• ist kein Teil des Entwickler Teams
• ist kein PO in demselben Projekt
• fördert Selbstorganisation. Probleme sollten wann immer möglich vom Team gelöst werden
• hilft dem Team, bei der Sache und produktiv zu bleiben und seine Fähigkeiten zu verbessern
• Captures empirical data to adjust forecasts
• Enforces timeboxes
• Keeps Scrum artifacts visible
• Has no management authority over the team (anyone with authority over the team is by definition not its ScrumMaster)
• no line manager

Der Product Owner 

• definiert Produkt-Features und beantwortet Fragen zur geforderten Funktionalität,  
• priorisiert Product Backlog-Einträge abhängig von ihrem geschäftlichen Wert und ihrem Risiko und konsolidiert die Anforderungen der anderen Stakeholder,  
• entscheidet über Release-Daten und den Umfang des Produkts,
• passt die Feature-Liste beziehungsweise Product Backlog-Einträge und Prioritäten vor jedem Sprint an,
• akzeptiert Ergebnisse als „done“ oder weist sie zurück, 
• ist verantwortlich für das finanzielle Ergebnis des Projekts (engl. „Return On Invest“, ROI).  
• hat keinen Einfluss auf Sprints oder Daily Scrums. Wohnt diesen lediglich bei
• May contribute as a team member (aber eher nein)
• Has a leadership role
• can be line manager

• Product Owner: Business Analyst, legt in Absprache mit Customer die Priorisierung der User Stories im Product Backlog fest
• Entwicklungsteam (Architekt, Entwickler, Tester) 7+-2
• ScrumMaster: nicht Teil des Entw.Teams, sorgt dafür das Scrum gelingt. Moderiert die Meetings. Führt alle Hindernisse im Impediment Backlog auf und beseitigt diese

• Individuen und Interaktionen über Prozesse und Werkzeuge
• Laufende Software über umfassende Dokumentation
• Kooperation mit dem Kunden über Vertragsverhandlungen
• Reaktion auf Veränderung über Festhalten an einem Plan

Scrum is a management framework for incremental product development using one or more cross-functional, self-organizing teams of about seven people each. It provides a structure of roles, meetings, rules, and artifacts. Teams are responsible for creating and adapting their processes within this framework. Scrum uses fixed-length iterations, called Sprints, which are typically two weeks or 30 days long. Scrum teams attempt to build a potentially shippable (properly tested) product increment every iteration.

Ready bezieht sich auf die Anforderung: Ein Feature muss vollständig geklärt sein (das 
heißt: priorisiert, geschätzt und verstanden), damit sich das Team zu seiner Umsetzung 
verpflichten kann. Nur wenn es in diesem Sinne „ready“ ist, darf es in einen Sprint 
aufgenommen werden. 

• verstanden
• geschätzt
• priorisiert

Eine Umsetzung ist „done“, wenn sie den vereinbarten Qualitätskriterien genügt (Definition von Done) und wenn sie im Sprint Review präsentiert und abgenommen wurde. 

• implementiert
• getestet (auch Regressionsgetestet)
• integriert

Produktinkrement ist so hochwertig, dass es ausgeliefert werden könnte.

• Pair-Programming
• Kollektives Eigentum
• Permanente Integration
• Testgetriebene Entwicklung bzw. Permanentes Testen
• Kundeneinbeziehung
• Refactoring
• Keine Überstunden
• Kurze Iterationen
• User-Stories zum einfacheren Verständnis zwischen Entwickler und Fachseite
• Coding-Standards
• Einfaches Design
• Planning Poker

1. Wert: Spezifiziere präzise den Wert deines Produktes
2. Wertstrom: Erkenne den Wertstrom
3. Flow: Erzeuge einen Wertstromfluss ohne Unterbrechungen
4. Pull: Lasse den Kunden den Takt der Bearbeitung bestimmen
5. Perfektion: Verbessere die Dinge kontinuierlich

Wer? Was? Wozu?

Als<>  möchte ich <> um <> zu haben

die 3 C's:

• Card: Stories werden traditionell auf Karteikarten geschrieben
• Conversation: Die Details hinter einer Story offenbaren sich oft erst während einer Diskussion
• Confirmation: Akzeptanzkriterien und daraus abgeleitete Akzeptanztests

INVEST in Good Stories

• Independent - vermeidet Probleme beim Priorisieren von Stories und unabhängiger Nutzen hilft auch, früh zu delivern
• Negotiable - verhandelbar a story is not a contract
• Valuable (wertvoll) and Vertical - bringt Mehrwert oder vertikal: Funktionalität über verschiedene Softwareschichten
• Estimable - schätzbar. die Stories stellen über den Product Backlog die Basis unseres Projektplans dar. Mit der Schätzung werden häufig verborgene Anforderungen sichtbar
• Sized appropriately - large stories should be decomposed before they are accepted into a sprint
• Testable - if a story is not testable maybe it doesn't have any real value?

• Fokus
• Mut
• Offenheit
• Selbstverpflichtung
• Respekt

• hochwertige Features mit geschäftlichem Mehrwert werden zuerst entwickelt
• bezieht Kundenfeedback früher ein
• offen für Veränderung
• das Wasserfallmodell hängt von einem perfekten Verständnis der Produktanforderungen ab und erlaubt nur minimale Fehelr in jeder Phase
• Wasserfall ist Plan getrieben, Agile ist Wert-getrieben
• Scrum fördert Selbstorganisation, Kommunikation und Vertrauen

• nicht in Zeiteinheiten wie Personentagen denken
• sondern zunächst eine Basisgröße für eine User Story wählt und dann die Größe der anderen Stories in Bezug dazu setzt
• Story Point: abstrakte Einheit
• Umrechnung in PT nach Sprint wieder möglich. 

Vorteile:

• schnellere Schätzung
• Komplexität und Größenverhältnisse werden sichtbar
• weil sie nur eine Vergleichsgröße sind, bleiben sie stabil, selbst wenn erste Aufwandsschätzungen korrigiert werden müssen
• Schätzen in T-Shirt-Größen oder Fibonacci-Reihe