Was bedeutet Stakeholder Scrum Rolle
Scrum wurde nicht entwickelt, um die Stakeholder von der Interaktion mit dem Team (mehr dazu Team Schulungen) abzuhalten. In der Tat wurde Scrum (mehr Infos Scrum Training) entwickelt, um diese Leute näher zusammenzubringen. Was Scrum versucht, ist, den Stakeholdern einen sinnvolleren, strukturierten Weg zu geben, um zu interagieren und dem Team über den Sprint Review Feedback zu geben. Dies ist die Gelegenheit für das Team, direktes, ungeschminktes Feedback zu hören, was sie wirklich denken. Die Rollen eines Scrum Teams sind im Wiki Scrum Team detailiert.
Zu den Stakeholdern gehören alle Kunden eines Scrum-Teams. Dies sind die Endanwender des zu entwickelnden Produkts. Mit dem Input der Stakeholder erstellen die Entwickler das gewünschte Produkt/den gewünschten Service. Aber nicht ohne Anleitung durch den Product Owner. Diese Person steht in Kontakt mit den Stakeholdern und sorgt dafür, dass die Wünsche, Anforderungen und Anmerkungen bei den Entwicklern ankommen.
Stakeholder spielen eine wichtige Rolle bei der Zusammenstellung des Product Backlogs. Als Kunde können sie den Entwicklern deutlich machen, welche Arbeiten durchgeführt werden müssen, um das gewünschte Produkt zu erhalten. Dabei geben sie genau an, welche Wünsche sie in Bezug auf das Produkt haben. Deshalb ist es wichtig, den Stakeholdern Aufmerksamkeit zu schenken, indem man ihnen aufmerksam zuhört. Es liegt in der Verantwortung des Product Owners, sich um die Kommunikation (mehr dazu Kommunikation Seminar) zwischen dem Scrum-Team und den Stakeholdern zu kümmern.
Um den Wünschen der Endanwender des Produkts Gestalt zu geben, werden User Stories erstellt. Dies sind kurze Beschreibungen von Merkmalen eines (Teil-)Produkts, gesehen aus der Sicht des Endanwenders. In einer User Story wird der Endbenutzer erwähnt, was er/sie will und warum. Die erstellten User Stories werden dann in überschaubare Sprints unterteilt. Auf diese Weise wird nach jedem Sprint ein Teil des Produkts ausgeliefert. Sprints sind im Wiki Scrum näher erläutert.
Product Owner helfen, das Backlog des Scrum-Teams zu definieren und helfen auch bei der Priorisierung der Arbeitseinheiten des Scrum-Teams und kommunizieren kontinuierlich den Fortschritt an die Stakeholder.
Stakeholder sind der Zweck, für den ein Produkt oder eine Dienstleistung überhaupt erst erstellt wird. Stakeholder sind die Menschen, die bestimmte Bedürfnisse, Wünsche und Sehnsüchte haben, also betriebswirtschaftlich gesehen bestimmte Anforderungen, die erfüllt werden müssen. Es liegt in der Verantwortung des Scrum-Teams, die Anforderungen der Stakeholder zu erfüllen und sie zufrieden zu stellen. Normalerweise haben die Stakeholder kein klares Verständnis davon, was sie brauchen, und selbst wenn sie es haben, ändern sie ihre Meinung sehr oft. Um die tatsächlichen Bedürfnisse eines Stakeholders herauszufinden, bedarf es in der Regel vieler Meetings mit den Stakeholdern und auch einer Menge Versuch und Irrtum.
Die Stakeholder sind sehr wichtig für den Erfolg des Scrum-Teams, da sie die Produkte und den Fortschritt des Teams ständig überprüfen und kontinuierlich Feedback geben. Es kann viele Personen geben, die ein echtes Interesse am Produkt haben, aber nicht alle sollten als Stakeholder berücksichtigt werden - manche sind reine Schaulustige. Die klare Identifizierung der Stakeholder, die Anforderungen haben, ist ebenso wichtig wie die Bestimmung des genauen Marktsegments, das Sie für Ihre Produkte ansprechen müssen.
Damit ergibt sich eine weitere wichtige Frage. Wer oder welche Eigenschaften machen einen guten Stakeholder in Scrum aus?
Gute Stakeholder sind diejenigen, die dem Scrum-Team konstantes und konstruktives Feedback geben und dabei helfen, das Produkt zu verbessern. Eine große Herausforderung ist es, andere Stakeholder zu managen, die nicht unterstützen oder nur Teil der Szene werden. Gute Teams brauchen eine starke Führung, die positive Diskussionen ermöglicht und bessere Dienstleistungen oder Produkte schafft.
Um in einem Scrum-Projekt erfolgreich zu sein, spielt das Verständnis für die Bedürfnisse und Anforderungen der Stakeholder eine sehr wichtige Rolle und entscheidet oft über Erfolg oder Misserfolg des Projekts.
Agile Projekte konzentrieren sich auf die frühe Erstellung von funktionierender Software. Nur diese kann einen Wertbeitrag für ein Unternehmen leisten. Ein integrierter Requirements-Engineering- und Entwicklungsprozess reduziert Risiken, weil die Ergebnisse regelmäßig evaluiert werden und eine kontinuierliche Wertschöpfung stattfindet.
In der Realität steht das Projektbudget oft schon fest, bevor es mit den Stakeholdern diskutiert wurde und bevor alle Anforderungen definiert sind. Es gibt jedoch verschiedene Möglichkeiten, mit diesem Problem umzugehen und eine Bewertung unter Unsicherheit zu ermöglichen:
Eine Grundvoraussetzung für eine gute Schätzung und Planung ist ein gutes Verständnis der Anforderungen. Um dies zu erreichen, gibt es in Scrum verschiedene Methoden:
Zu den Stakeholdern gehören alle Kunden eines Scrum-Teams. Dies sind die Endanwender des zu entwickelnden Produkts. Mit dem Input der Stakeholder erstellen die Entwickler das gewünschte Produkt/den gewünschten Service. Aber nicht ohne Anleitung durch den Product Owner. Diese Person steht in Kontakt mit den Stakeholdern und sorgt dafür, dass die Wünsche, Anforderungen und Anmerkungen bei den Entwicklern ankommen.
Stakeholder spielen eine wichtige Rolle bei der Zusammenstellung des Product Backlogs. Als Kunde können sie den Entwicklern deutlich machen, welche Arbeiten durchgeführt werden müssen, um das gewünschte Produkt zu erhalten. Dabei geben sie genau an, welche Wünsche sie in Bezug auf das Produkt haben. Deshalb ist es wichtig, den Stakeholdern Aufmerksamkeit zu schenken, indem man ihnen aufmerksam zuhört. Es liegt in der Verantwortung des Product Owners, sich um die Kommunikation (mehr dazu Kommunikation Seminar) zwischen dem Scrum-Team und den Stakeholdern zu kümmern.
Um den Wünschen der Endanwender des Produkts Gestalt zu geben, werden User Stories erstellt. Dies sind kurze Beschreibungen von Merkmalen eines (Teil-)Produkts, gesehen aus der Sicht des Endanwenders. In einer User Story wird der Endbenutzer erwähnt, was er/sie will und warum. Die erstellten User Stories werden dann in überschaubare Sprints unterteilt. Auf diese Weise wird nach jedem Sprint ein Teil des Produkts ausgeliefert. Sprints sind im Wiki Scrum näher erläutert.
Product Owner helfen, das Backlog des Scrum-Teams zu definieren und helfen auch bei der Priorisierung der Arbeitseinheiten des Scrum-Teams und kommunizieren kontinuierlich den Fortschritt an die Stakeholder.
Stakeholder sind der Zweck, für den ein Produkt oder eine Dienstleistung überhaupt erst erstellt wird. Stakeholder sind die Menschen, die bestimmte Bedürfnisse, Wünsche und Sehnsüchte haben, also betriebswirtschaftlich gesehen bestimmte Anforderungen, die erfüllt werden müssen. Es liegt in der Verantwortung des Scrum-Teams, die Anforderungen der Stakeholder zu erfüllen und sie zufrieden zu stellen. Normalerweise haben die Stakeholder kein klares Verständnis davon, was sie brauchen, und selbst wenn sie es haben, ändern sie ihre Meinung sehr oft. Um die tatsächlichen Bedürfnisse eines Stakeholders herauszufinden, bedarf es in der Regel vieler Meetings mit den Stakeholdern und auch einer Menge Versuch und Irrtum.
Die Stakeholder sind sehr wichtig für den Erfolg des Scrum-Teams, da sie die Produkte und den Fortschritt des Teams ständig überprüfen und kontinuierlich Feedback geben. Es kann viele Personen geben, die ein echtes Interesse am Produkt haben, aber nicht alle sollten als Stakeholder berücksichtigt werden - manche sind reine Schaulustige. Die klare Identifizierung der Stakeholder, die Anforderungen haben, ist ebenso wichtig wie die Bestimmung des genauen Marktsegments, das Sie für Ihre Produkte ansprechen müssen.
Damit ergibt sich eine weitere wichtige Frage. Wer oder welche Eigenschaften machen einen guten Stakeholder in Scrum aus?
Gute Stakeholder sind diejenigen, die dem Scrum-Team konstantes und konstruktives Feedback geben und dabei helfen, das Produkt zu verbessern. Eine große Herausforderung ist es, andere Stakeholder zu managen, die nicht unterstützen oder nur Teil der Szene werden. Gute Teams brauchen eine starke Führung, die positive Diskussionen ermöglicht und bessere Dienstleistungen oder Produkte schafft.
Um in einem Scrum-Projekt erfolgreich zu sein, spielt das Verständnis für die Bedürfnisse und Anforderungen der Stakeholder eine sehr wichtige Rolle und entscheidet oft über Erfolg oder Misserfolg des Projekts.
Agile Projekte konzentrieren sich auf die frühe Erstellung von funktionierender Software. Nur diese kann einen Wertbeitrag für ein Unternehmen leisten. Ein integrierter Requirements-Engineering- und Entwicklungsprozess reduziert Risiken, weil die Ergebnisse regelmäßig evaluiert werden und eine kontinuierliche Wertschöpfung stattfindet.
In der Realität steht das Projektbudget oft schon fest, bevor es mit den Stakeholdern diskutiert wurde und bevor alle Anforderungen definiert sind. Es gibt jedoch verschiedene Möglichkeiten, mit diesem Problem umzugehen und eine Bewertung unter Unsicherheit zu ermöglichen:
- Machen Sie keine Schätzungen. Liefern Sie häufig hochwertige, lauffähige Software und stellen Sie Ihre Arbeit ein, wenn das Budget aufgebraucht ist.
- Reduzieren Sie die Unsicherheit durch verschiedene Schätzmethoden, wie z. B.:
- Parametrische Schätzungsmodelle mit historischen Projektdaten
- Funktions-Punkt-Analyse
- Work-Breakdown-Strukturen mit Pert-Schätzungen
- Regelmäßige Planungspoker-Sitzungen
- Zuweisung von Budgets zu Feature Sets oder Epics. Sobald Sie ein Budget zugewiesen haben, können Sie den Requirements-Engineering-Prozess so steuern, dass das gesamte spezifizierte Feature-Set in das zugewiesene Budget passt. Zu diesem Zweck sind regelmäßige Reviews erforderlich.
Eine Grundvoraussetzung für eine gute Schätzung und Planung ist ein gutes Verständnis der Anforderungen. Um dies zu erreichen, gibt es in Scrum verschiedene Methoden:
- Refinement. Reservieren Sie 10-15% der Sprint-Zeit für die Verfeinerung des Product Backlogs. Überlassen Sie es dem Team, wie es sich auf ein effektives Planungsmeeting vorbereitet. Unerfahrene Teams sind mit dieser Freiheit oft überfordert und bereiten sich nur wenig vor. Stattdessen nutzen sie diese Zeit oft, um die Features zu verbessern, die sie gerade entwickeln.
- Planen Sie bestimmte Zeitfenster ein, in denen Sie gemeinsam mit dem Product Owner Anforderungen verfeinern oder an technischen Details arbeiten (z. B. Konzepte oder Work-Breakdown-Strukturen).
- Halten Sie regelmäßig geplante Planning-Poker-Sitzungen ab, um neue Anforderungen zu verfeinern und mit Story-Points zu bewerten.