SCRUM und Nexus Frameworks – 1 Team mit mehreren Projekten

Ich arbeite im Wesentlichen für 3 Unternehmen. Ein Entwicklungsteam aus Mitgliedern der 3 verschiedenen Unternehmen wird gebildet, um 1 verwandtes Produkt (mit mehreren Versionen) zu erstellen. Der komplexe Teil ist, dass, da unser Team aus Mitgliedern verschiedener Unternehmen besteht, manchmal andere Mitglieder des Entwicklungsteams Aufgaben für verschiedene Projekte erledigen. Wir haben Jira verwendet, um die Probleme zu verfolgen, an denen wir arbeiten müssen. Wäre es besser, 1 Produkt- und Sprint-Backlog für das 1 Entwicklungsteam und alle Elemente für alle Projekte in diesen Backlogs zu behalten? Würde dies auch bedeuten, dass es nur einen Product Owner für alle Projekte geben sollte, der mit verschiedenen Stakeholdern, Produktmanagern, der Geschäftsleitung usw. verschiedener Projekte interagiert?

Der Punkt, den ich in diesem Setup (1 Product Backlog und 1 PO) anzusprechen versuche, ist, wenn ein Entwickler bereits für einen Sprint des Projekts verpflichtet ist, dann sollte niemand außer dem Product Owner neue Aufgaben für diesen Entwickler zuweisen können . Nur der Product Owner sollte mit dem Zuweiser der neuen Aufgaben (die von Stakeholdern oder Kunden verschiedener Projekte kommen) kommunizieren, um das Sprint-Engagement aufrechtzuerhalten, richtig?

Würden Sie näher erläutern, wie groß das Team des Produkts ist und wie abhängig die Versionen voneinander sind? Du kannst immer ein Backlog haben, aber basierend auf anderen Faktoren entscheidest du, ob es ein Board/Sprint/PO oder mehrere sind
Das Entwicklungsteam besteht nur aus etwa 3-5 Mitgliedern und ein Teammitglied kann mehrere Projekte oder gar kein Projekt für mehrere Tage in einem 2-Wochen-Zyklus durchführen. Die meisten von uns arbeiten im selben Büro, mit Ausnahme von 1 Teammitglied, das Teilzeit ist und remote arbeitet. Die Versionen des Hauptprodukts sind stark voneinander abhängig, während andere Projekte für andere Produkte gelten. Ich stelle mir vor, dass, wenn wir unterschiedliche Backlogs für jedes Produkt von 1 Dev-Team haben, der Sprint des Hauptprodukts Teilsprints für einige Mitglieder enthalten würde und es schwieriger wäre, ihre Verpflichtungen für das Hauptprodukt sicherzustellen.

Antworten (1)

Meiner Meinung nach macht die Idee eines Product Backlogs/PO bei dieser Größe des Teams Sinn. Um die Auswirkungen neuer Aufgaben aus anderen Projekten zu minimieren, wäre es auch die Idee, ein paar feste Tage für externe Arbeit zu reservieren und dies im Sprint zu berücksichtigen. Zum Beispiel umfasst der Sprint 10 Arbeitstage, aber wenn Sie die Planung durchführen, berücksichtigen Sie nur acht Tage, da die anderen zwei Tage externe Arbeit sind, und Sie können ein Ticket für ungeplante Aufgaben hinzufügen, um zu sehen, wie sich die externe Arbeit auf den Sprint auswirkt bei Bedarf an die Stakeholder kommunizieren können.