Hat die Agile-Community empfohlene Prozesse für ein einzelnes Scrum-Team, das Aufgaben verwaltet, die aus mehreren Backlogs kommen?
Mein aktueller Plan sieht folgende Aktion vor (aber ich freue mich, dass der Prozess von der SE-Community überprüft wird)
Ich kann mir keine fairere Art vorstellen, gleichberechtigte Funktionen mit schwankenden Business Cases von Sprint zu Sprint zusammenzubringen.
Glücklicherweise basieren alle Anforderungen auf derselben Entwicklungsumgebung, die sich auf die SAP-Funktionalität konzentriert, sodass das Entwicklungsteam (und das Testen) nicht massiv zwischen den User Storys/Funktionen variiert. Was das Marketing verlangt, liegt gut im Bereich dessen, was der Kundendienst verlangt; nur ein anderer Endbenutzer.
Alles, was sich ändert, ist, welcher Stakeholder am Ende des Sprints den Wert erhält, welche Abteilung den Vermögenswert zu ihrem Endergebnis hinzufügt und wer die Rechnung für das Scrum-Team erhält.
Gerne nehme ich Gedanken, Whitepapers oder Anleitungen aus der Community an.
Außerdem habe ich wirklich versucht, diese Frage für SE zu formulieren, also schreiben Sie bitte eine Zeile, wenn das Format nützlich ist, einschließlich Erklärungen usw.
Hat die Agile-Community empfohlene Prozesse für ein einzelnes Scrum-Team, das Aufgaben verwaltet, die aus mehreren Backlogs kommen?
Klar: Tu es nicht.
Mehrere Teams können von einem einzigen Product Backlog aus arbeiten, aber niemals umgekehrt. Ein einzelnes Team, das mit mehreren Product Backlogs arbeitet, ist kein Scrum, nicht agil und es ist äußerst unwahrscheinlich, dass es in irgendeiner Größenordnung funktioniert.
Stellen Sie zunächst fest, ob Sie ein einziges einheitliches Projekt oder viele separate (wenn auch möglicherweise verwandte) Projekte haben. Sobald Sie dieses kritische Datum festgelegt haben, können Sie Ihre Projektmanagementprozesse entsprechend neu gestalten.
Innerhalb des Scrum-Frameworks besteht immer eine Eins-zu-eins-Beziehung zwischen:
Während es Möglichkeiten gibt, Scrum über mehrere Teams und Projekte wie Scrum-of-Scrums oder SAFe zu skalieren , ist Ihre Scrum-Implementierung aus den Fugen geraten, wenn Sie mehr als ein Product Backlog direkt in ein einziges Scrum-Entwicklungsteam leiten.
Die von Ihnen beschriebene Situation, in der es viele Interessenvertreter mit unterschiedlichen Agenden gibt, ist eigentlich ganz normal. Unter der Annahme, dass Sie ein einzelnes Projekt mit einem einigermaßen einheitlichen Ziel haben, besteht der richtige Weg, damit innerhalb des Scrum-Frameworks umzugehen, darin, alle diese Geschäftsinteressen als Stakeholder zu behandeln und dem Product Owner zu erlauben, ein einheitliches Product Backlog auf beliebige Weise zu verwalten am geeignetsten erscheint, um die Interessen der Beteiligten auszugleichen.
Der Product Owner kann Techniken wie Theme Scoring oder Relative Weighting verwenden , um die Stakeholder beim Ausgleich ihrer Interessen zu unterstützen, aber der einzelne Product Owner erstellt letztendlich ein einziges, sequenziertes Product Backlog, mit dem das Scrum-Team arbeiten kann. Dies ist absolut grundlegend für das Framework und nicht verhandelbar, wenn Sie das, was Sie tun, „Scrum“ nennen möchten.
Ein weiteres grundlegendes Konzept von Scrum und agilen Frameworks im Allgemeinen ist, dass Multitasking schlecht ist, weil es Overhead beim Wechseln von Aufgaben verursacht und den Durchsatz und die Effektivität verringert. Ein Projekt wird im Allgemeinen wie folgt definiert :
ein individuelles oder kooperatives Unternehmen, das sorgfältig geplant und entwickelt wurde, um ein bestimmtes Ziel zu erreichen.
Wenn nicht alle Geschäftsbereiche auf das gleiche einheitliche Ziel hinarbeiten, haben Sie kein einheitliches Projekt; Sie haben mehrere Projekte . Mehrere Projekte erfordern, dass Sie Ihre Projekte durch ein Team sequenzieren oder die Projekte auf mehrere Teams verteilen. In jedem Fall sollten Sie Ihre Projektteams und Ihr Projektmanagement-Framework so organisieren, dass sie sich an der Realität ausrichten, dass Sie kein einzelnes, zusammenhängendes Projekt haben. so zu tun, als würdest du das Schwein nicht schminken .
Bei einer meiner früheren Aufgaben als Scrum Master habe ich mit einer Gruppe von Produktmanagern ähnlich wie von Ihnen beschrieben gearbeitet. Außerdem hatten die Produktmanager viele andere Prioritäten, und daher war es schwierig, rechtzeitig eine Klärung der Anforderungen oder einen Kundenakzeptanztest (CAT) von ihnen zu erhalten. Jeder der vier Produktmanager hat sich dafür eingesetzt, dass das Entwicklerteam mehr Zeit für seine Funktionen bekommt, ähnlich wie Sie es beschreiben. Meine Situation war jedoch in zwei Aspekten besser als deine:
Die Lobbyarbeit fand in einem Roadmap- oder Backlog-Grooming-Meeting statt, ohne dass das gesamte Entwicklerteam anwesend war.
Glücklicherweise war einer der Produktmanager Senior und konnte die letzte Entscheidung treffen, wenn es umstritten wurde.
Nachdem wir das mehr als ein Jahr lang gemacht hatten, wurden wir klüger und ernannten einen engagierten Vollzeit-Product Owner (für 3 Scrum-Teams). Der Product Owner arbeitete offline mit den verschiedenen Product Ownern und gab die daraus resultierenden einheitlichen Prioritäten an die Entwicklerteams weiter. Der Product Owner saß auch im Sprint Planning Meeting und stand dem Entwicklerteam zur Verfügung, um Anforderungen übergreifend zu klären und kurzfristig CAT-Tests durchzuführen. Die Verbesserung der Teamproduktivität und -moral war dramatisch.
Aufgrund dieser Erfahrung wird Ihre erwogene Lösung meiner Meinung nach nicht funktionieren. Erwägen Sie mindestens die Implementierung von 1 und 2 oben. Nennen Sie noch besser einen engagierten Vollzeit-Product Owner.
Venture2099