Sprint Review & Retrospektive mit Scrum for Team System

In diesem Teil beschreibe ich, wie wir Scrum for Team System bei Sprint Reviews und bei Sprint Retrospektiven nutzen. Und weshalb wir Impediments nicht mit Scrum for Team System verwalten…

Teil 1: Sprint Planung
Teil 2: Daily Scrums
Teil 3: Sprint Review & Retrospektive

Teil 3: Sprint Reviews & Retrospektive

3.1 Sprint Review
Zu dem Sprint Review treffen sich die Team-Mitglieder, die Product Owner oder Fachexperten. Es wird an einem Beamer das Product Increment vorgestellt.
War die Implementierung erfolgreich, werden die entsprechendes Product Backlog Items auf "done" gesetzt. Entspricht ein Product Backlog Item aber nicht den Vorstellungen, muss nachgebessert werden. Solch ein Product Backlog Item verweilt mit dem Status "in Progress" im Product Backlog und steht mit der höchsten Priorität für den Folgesprint an oberster Stelle. Wir nutzen üblicherweise das Task Board, um den Status von PBIs zu setzen.

3.2 Retrospektive
Zur Retrospektive treffen wir uns nach einem Sprint für eine Stunde, um die Aktivitäten des Sprints zu reflektierene:

• Was war gut?
• Was war nicht so gut?
• Was wollen wir besser machen? 

Jeder im Team liefert "Input".Die Ergebnisse halten in einem Work Item Type "Retrospective" fest:


Da war doch noch was? Richtig die Impediments…

3.3 Impediments (Hindernisse) besser auf einem Whiteboard!
Impediments hindern das Team daran das Produkt-Inkrement fertig zu stellen. Hindernisse müssen schnell aus dem Weg geräumt werden. Dies zu tun ist Aufgabe des SCRUM Masters. Ein Hindernis kann beispielsweise "Mehr RAM für den Build-Server" sein, oder "es fehlt noch die Prozessabsprache mit Fachabteilung XY". Unsere Hindernisse sind vielschichtig und meist nur kurzlebig. Darum verwalten wir sie nicht über das WorkItemType "Impediments" in TFS, sondern auf einem Whiteboard - für jeden im Team sichtbar!