Mehr Scrum Wissen: Hier erfahren Sie alles über Scrum
Scrum Assessment Preparation
Der erfolgreiche Weg zum Professional Scrum Master Zertifikat
Legt der Product Owner soviele Backlog Items in den Sprint, wie die Stakeholder wünschen?
Nein. Das Development Team wählt soviele Product Backlog Items in den Sprint Backlog, wie es meint innerhalb des Sprints umsetzen zu können. Der Product Owner wählt die Product Backlog Items mit dem höchsten Produktnutzen aus. Damit versucht er immer mit jedem Sprint den höchsten Nutzen aus dem Produkt heraus arbeiten zu lassen. Die Stakeholder können dem Product Owner Input geben, doch verantwortlich ist nur der Product Owner selbst.
Mehr Scrum Wissen: Hier erfahren Sie alles über Scrum
Wer ist für die Schätzung der Arbeit im Sprint verantwortlich?
Das Entwicklungsteam ist immer als Ganzes verantwortlich. Schätzungen dürfen nur von denen gemacht werden, die auch die Arbeit machen werden. Damit fällt dies auf das Development Team.
Mehr Scrum Wissen: Hier erfahren Sie alles über Scrum
Was sollte das Development Team machen, wenn der CEO eine sehr dringende Änderung in den laufenden Sprint einbringt?
Das Entwicklungsteam schätzt die Backlog Einträge und verpflichtet sich auf die Umsetzung einer bestimmten Menge an Einträgen. Nach kurzer Zeit bleibt die Menge gleich. Das ermöglicht eine Release Planung. Der Product Owner ist in der Lage eine gute Schätzung zu erstellen, was wann fertig sein könnte. Störungen von außen reduzieren den Produktivität des Teams. Eine richtige Vorhersage über die erreichten Teilproduktziele ist nicht mehr möglich. Das Team wird unruhig und kann sich nicht mehr auf die vorgestellten Einträge verlassen. Es wird anfangen einen Puffer in der Planung einzubauen. Items die von außen, also nicht vom Scrum Team kommen, stören die Planung des Product Owners. Er wird gehindert den geplanten Nutzen des Produktes zu erreichen. Da der Product Owner die Planung im Blick hat, sollten neue Anfragen an das Produkt nur über den Product Owner in den tatsächlichen Product Backlog einfließen. Er muss über neue Anforderungen informiert sein. Eventuell müssen dadurch anderen Backlog Einträge erheblich angepasst werden.
Um eine hohe Produktivität des Entwicklungsteams zu gewährleisten, plant das Team auch selbst die Umsetzung der Sprint Backlog Items. Ein Item dass später im Sprint eingeworfen wird, könnte die Erreichung des aktuellen Sprintziels gefährden und auch eine erneute Planung erfordern. Diese erneute Planung von unvorhergesehen neuen Items kostet entsprechend Zeit und verhindert eventuell die Umsetzung von anderen Items im Sprint Backlog.
Der Product Owner priorisiert seine Product Backlog Einträge nach dem höchsten Produktnutzen. Dieser Reihenfolge entlang werden Items für den Sprint ausgewählt. Keine Anpassung oder Änderung sollte das Sprintziel gefährden. Es dürfen keine Änderungen am Sprint Backlog dem Entwicklungsteam aufgedrückt werden. Es dürfen keine Änderungen am Product Backlog dem Product Owner aufgedrückt werden. Diese entscheiden jeweils selbst.
Eine Einmischung von außen untergräbt das Vertrauen in den Product Owner. Die Stärke von Scrum beruht neben dem Timeboxing auch auf Vertrauen. Das Vertrauen ist für alle Rollen wichtig. Wenn das Entwicklungsteam nicht darauf vertrauen kann, ob die ausgewählten Items nun richtig sind, wird
es in der Umsetzung gehemmt. Unnötige Rückfragen am Product Owner vorbei verzögern und andere zwischenmenschliche Probleme können das gesamte Produkt gefährden. Das Team gerät in Gefahr sich zu destabilisieren.
Um eine hohe Produktivität des Entwicklungsteams zu gewährleisten, plant das Team auch selbst die Umsetzung der Sprint Backlog Items. Ein Item dass später im Sprint eingeworfen wird, könnte die Erreichung des aktuellen Sprintziels gefährden und auch eine erneute Planung erfordern. Diese erneute Planung von unvorhergesehen neuen Items kostet entsprechend Zeit und verhindert eventuell die Umsetzung von anderen Items im Sprint Backlog.
Der Product Owner priorisiert seine Product Backlog Einträge nach dem höchsten Produktnutzen. Dieser Reihenfolge entlang werden Items für den Sprint ausgewählt. Keine Anpassung oder Änderung sollte das Sprintziel gefährden. Es dürfen keine Änderungen am Sprint Backlog dem Entwicklungsteam aufgedrückt werden. Es dürfen keine Änderungen am Product Backlog dem Product Owner aufgedrückt werden. Diese entscheiden jeweils selbst.
Eine Einmischung von außen untergräbt das Vertrauen in den Product Owner. Die Stärke von Scrum beruht neben dem Timeboxing auch auf Vertrauen. Das Vertrauen ist für alle Rollen wichtig. Wenn das Entwicklungsteam nicht darauf vertrauen kann, ob die ausgewählten Items nun richtig sind, wird
es in der Umsetzung gehemmt. Unnötige Rückfragen am Product Owner vorbei verzögern und andere zwischenmenschliche Probleme können das gesamte Produkt gefährden. Das Team gerät in Gefahr sich zu destabilisieren.
Mehr Scrum Wissen: Hier erfahren Sie alles über Scrum
Wie kann der Scrum Master das Development Team auf hohen Niveau halten?
Das Entwicklungsteam ist selbst organisiert. Damit versucht es sich auch selbst zu optimieren. Der Scrum Master kann Empfehlungen für eine bessere Arbeitsumgebung abgeben. Das Team entscheidet ob es diese ausprobieren möchte. Der Scrum Master schafft dann die optimierten Arbeitsumgebungen, welche das Team als Beste einstuft. Im Daily Scrum werden auch die Impediments durch das Entwicklerteam benannt. Die Beseitigung der Impediments ist die Aufgabe vom Scrum Master. Dabei sollten einfache Probleme durch den Entwickler selbst gelöst werden. Der Scrum Master soll die produktive Umgebung schaffen aber nicht das Mädchen für alles darstellen.
Mehr Scrum Wissen: Hier erfahren Sie alles über Scrum
Abonnieren
Posts (Atom)