Autor: vpadmin

Die Sprint-Retrospektive findet nach dem Sprint-Review und vor der nächsten Sprint-Planung statt. Bei einmonatigen Sprints dauert diese Sitzung höchstens drei Stunden. Die Retrospektive ist im Grunde ein “Verbesserungs”-Treffen, das dazu dient, Mittel und Wege zu finden, um potenzielle Fallstricke und Fehler aus der Vergangenheit zu identifizieren und neue Wege zur Vermeidung dieser Fehler zu finden, und an dem alle teilnehmen – der Product Owner, der Scrum Master, die Mitglieder des Entwicklungsteams und optional die Stakeholder.

Scrum selbst ist ein einfaches Framework für die effektive Zusammenarbeit von Teams an komplexen Produkten. Der Scrum-Leitfaden soll Scrum klar und prägnant erklären. Dieser Leitfaden enthält eine Definition von Scrum. Diese Definition besteht aus den Scrum-Rollen, Ereignissen, Artefakten und den Regeln, die sie miteinander verbinden. Jede Komponente innerhalb des Rahmens dient einem bestimmten Zweck und ist für den Erfolg und die Anwendung von Scrum unerlässlich. Die Regeln von Scrum binden die Rollen, Ereignisse und Artefakte zusammen und regeln die Beziehungen und die Interaktion

Ein Scrum Master ist ein Mitglied eines Scrum-Teams. Ihre Aufgabe ist es, ein produktives Arbeitsumfeld zu schaffen und andere anzuleiten, die Werte, Prinzipien und Praktiken von Scrum zu verstehen. Scrum Directors sind in der Regel menschenorientiert, haben einen hohen EQ und finden Freude daran, ihren Teammitgliedern zu helfen, sich zu entwickeln.

Ein Product Owner, der im Namen des Unternehmens für das Produkt verantwortlich ist, gehört zu einem Scrum-Team. Ein Product Owner hat jedoch keine Weisungsbefugnis gegenüber anderen Teammitgliedern, genau wie der Scrum Master. Ein Product Owner ist für die Betreuung eines Produkts über einen längeren Zeitraum hinweg verantwortlich und trägt die Verantwortung für den Erfolg des Produkts. Als Product Owner sollten Sie direkt mit den Kunden und Nutzern, dem Entwicklungsteam und anderen wichtigen Stakeholdern interagieren, wie die folgende Abbildung zeigt.

Ein Sprint Review ist mehr als nur eine Demo; es ist ein Review des abgeschlossenen Sprints, des Product Backlogs und des Marketplace. Zugegeben, Demos sind ein wichtiger Teil des Sprint Reviews. Der Zweck des Sprint-Review-Meetings besteht darin, dass das Team den Kunden und Stakeholdern zeigt, welche Arbeit es im Laufe des Sprints geleistet hat, und diese mit den zu Beginn des Sprints gemachten Zusagen vergleicht.

Ein Scrum-Entwicklungsteam hat die Autonomie zu entscheiden, wie es seine Arbeit am besten erledigt, anstatt von anderen außerhalb des Teams geleitet zu werden. Im Gegensatz zu den traditionellen Managementprinzipien werden die selbstorganisierenden, befähigten Teams nicht von oben gelenkt und kontrolliert, sondern sie entwickeln sich aus der aktiven Beteiligung der Teammitglieder an allen Scrum-Praktiken und -Ereignissen.

Die Kolokation ist nützlich für Besprechungen, bei denen ein genaues Zuhören erforderlich ist, z. B. bei Planungsgesprächen. Es ist auch praktisch, wenn neue Mitarbeiter geschult werden und ein gewisses Maß an Unterstützung oder Ermutigung benötigen. Das Whiteboard ist für Teams, die an einem Ort zusammenkommen, sehr effektiv, kann aber auch mit Online-Tools verwaltet werden.

Release early, release often ist eine Softwareentwicklungsphilosophie, die die Bedeutung von frühen und häufigen Releases betont, um eine enge Feedbackschleife zwischen Entwicklern und Testern oder Benutzern zu schaffen, im Gegensatz zu einer feature-basierten Release-Strategie.

Nicht alle Elemente im Product Backlog werden gleichzeitig die gleiche Größe und den gleichen Detaillierungsgrad haben (d.h. Features/Eprics/User Stories und Tasks). PBIs, an denen wir bald arbeiten wollen, sollten ganz oben im Backlog stehen, kleiner sein und sehr detailliert, damit sie im nächsten Sprint bearbeitet werden können. PBIs, an denen wir in nächster Zeit nicht arbeiten werden, sollten am unteren Ende des Backlogs stehen, größer und weniger detailliert sein.