Produktspezifikation für Scrum-Teams

Der Product Owner muss eine Release-Roadmap entwickeln

Entgegen der landläufigen Meinung bedeutet Scrum kein Sitz-in-der-Hose-Management ohne Vorausplanung. Der Product Owner muss eine Release-Roadmap entwickeln. Es gibt jedoch zwei wesentliche Anforderungen an eine Release-Roadmap in Scrum:

1. Der Zeitplan in der Release-Roadmap sollte auf der tatsächlichen Geschwindigkeit des Teams basieren.
2. Es sollte klargestellt werden, dass die nächste Version festgeschrieben ist, aber weiter draußen ist eine Prognose, die sich basierend auf den Marktbedingungen und den Vertragsunterzeichnungen der Kunden ändern wird.

Wenn Sie Hilfe bei der Entwicklung einer solchen Release-Roadmap und dem Format für deren Präsentation benötigen, kann ich Ihnen die Goal Oriented (GO) Product Roadmap von Roman Pichler empfehlen.

Für mich ist das betreffende Wort hier "Spezifikation". Ich weiß nicht, was es in Ihrer Organisation bedeutet, aber ich bin daran gewöhnt, dass es eine umfassende Beschreibung des Umfangs des Produkts bedeutet. Das Entwicklungsteam sollte versuchen, die Bedürfnisse Ihrer Benutzer zu erfüllen, und nicht eine Liste von Anforderungen in einem Spezifikationsdokument erfüllen. Auch hier weiß ich nicht, was eine Produktspezifikation in Ihrer Organisation ist, aber die Sorge wäre, dass Sie damit arbeiten Ein Projekt mit festem Umfang, bei dem die Entwickler dafür belohnt werden, dass sie Aufgaben gemäß einer Spezifikation erledigen und keine wertvolle Software erstellen.

Wie Ashok erwähnt hat, kann eine Roadmap sehr hilfreich sein. Denken Sie jedoch daran, dass wir bei Agile Wert darauf legen, auf Veränderungen zu reagieren, anstatt einem Plan zu folgen. Jeder Schritt des Projekts ist eine Gelegenheit, mehr über die Bedürfnisse Ihrer Kunden zu erfahren. Daher stellen die meisten Projekte fest, dass ihre Roadmap irgendwann im Laufe des Projekts falsch ist. Es ist wichtig, dass Sie die Roadmap bei Bedarf ohne unangemessenen Aufwand und ohne Probleme für sich selbst in Ihrer Organisation ändern können.

Die Antwort hier ist leider ... vielleicht .

Es hängt von Ihrer Organisation und der Art der Entwicklung ab, in der Sie arbeiten.

In unserer Abteilung haben wir neben dem Product Backlog auch Business Requirement Specifications.

Der Grund dafür ist zweifach

• Wir haben mehrere Projekte, die in dasselbe Scrum-Team kommen
• Wir haben umfangreiche Abhängigkeiten, die von anderen Abteilungen abgeschlossen werden müssen, bevor das Scrum-Team mit seiner Arbeit beginnt. Da sie ein BRS erfordern und wir darin etwas eingeben, ist es sinnvoll, dass wir beim Schreiben des BRS helfen und sicherstellen, dass unser Backlog reflektierend ist.

Beispielsweise kümmert sich unsere Abteilung um das Frontend Business Warehouse und die Entwicklung von Geschäftsobjekten, und der Product Owner kann im Namen des Unternehmens sprechen.

Die SAP R/3-Architekten (separat) benötigen jedoch detaillierte Spezifikationen bezüglich der Vorbereitungsarbeiten für das Business Warehouse Backend. Daher wird die Geschäftsanforderungsspezifikation erstellt, obwohl wir ein komplexeres Product Backlog haben, auf das wir für die Sprintplanung auf Aufgabenebene zurückgreifen können.

Ich würde argumentieren, dass Sie unbedingt ein detailliertes Anforderungsdokument haben sollten, wenn einer der folgenden Punkte zutrifft

• Das Scrum-Team ist einem anderen nicht agilen Team vor- oder nachgelagert, das dasselbe Produkt oder ein Derivat dieses Produkts herstellt
• Das Scrum Team / PO muss die geschäftlichen Anforderungen mehrerer Projekte, Workstreams oder Backlogs antizipieren
• Nicht-traditionelle Scrum-Prozesse verwässern das Scrum-Framework aufgrund geschäftlicher Einschränkungen
• Das Product Backlog ist sehr technisch oder ein komplexes Projekt und resistent gegen User Story Breakdown ZB SAP-Stammdaten mit mehr als 1000 Stakeholdern in der globalen Landschaft. Es gibt nur sehr wenige Möglichkeiten, die Notwendigkeit eines großen Dokuments zu umgehen, das den genauen Umfang, den Umfang und das Risikomanagement dieser Arbeit beschreibt.

Die Wahrheit ist, dass die meisten Scrum-Beispiele immer die einfachstmögliche Erklärung verwenden, ohne die maßgeschneiderte Arbeitsumgebung zu berücksichtigen.

Nicht jeder Rückstand kann sein

Als Amazon-Kunde möchte ich Artikel für zukünftige Bezahlvorgänge in einen Warenkorb legen können.

Die Vorteile von Scrum für unser Team sind, dass wir außergewöhnlich schnell auf Projektänderungen reagieren können, wir können mehrere Projekte gleichzeitig als zusammengeführtes Backlog filtern und bearbeiten, unsere Kapazitätsplanung und unser Sprintzyklus bieten realistischere Planungszeitpläne (sie erhalten eine Iterationszeit Box und sie können in dieser Box etwas Arbeit erledigen, wenn die Arbeit die Box übersteigt, fragen Sie nach einer anderen Box) und vor allem können wir Innovation und funktionsübergreifende Entwicklung fördern.

Sicherlich sollte die Produktspezifikation die Merkmale und Themen sein, die mit dem Product Owner als Teil der Produktvision definiert und vereinbart wurden (oder welchen Namen Sie ihr auch geben möchten)?

Ich ziehe es vor, „Roadmap“ dafür nicht zu verwenden, da Roadmap für mich die Vorstellung vermittelt, wie Sie dorthin gelangen werden, z. B. Veröffentlichungsplan.