Hat jemand Erfahrung mit Bottom-up-Produktmanagement? Im Wesentlichen ihre Teams dazu bringen, über die Funktionen und die Richtung des Produkts zu entscheiden?
In den meisten meiner früheren Teams haben das Produktmanagement und die Interessengruppen über Funktionen und Themen entschieden, und ich habe dann meine Teams dazu gebracht, Benutzergeschichten und Aufgaben zu schreiben, um diese Roadmap umzusetzen.
Aber mit meinem aktuellen Team haben wir das Glück, dass wir mehr Kontrolle haben. Wir haben immer noch Einschränkungen, aber wir durften im Wesentlichen ein Bottom-up-Produktmanagement betreiben. Die Organisation hat eine hochrangige Richtung für das Jahr festgelegt, aber wir müssen entscheiden, welche Funktionen benötigt werden.
Hat jemand gute Methoden, um Scrum-Teams dazu zu bringen?
Meine ursprüngliche Idee war nur, einen Team-Trichter zu haben, in dem alle Einzelpersonen Ideen einreichen würden, die in einem Wiki oder so etwas festgehalten werden, und die Komplexität und Wirkung ihrer Einsendungen darstellen. Allerdings ist die Idee ein bisschen mies und ich möchte den Feature-Rückstand in ein oder zwei Monaten haben, also ist vielleicht ein Workshop erforderlich.
Sie könnten eine Technik wie Story-Mapping in Betracht ziehen .
Es lohnt sich auch, mit dem Team darüber zu sprechen, wie sie Wert definieren. Mit einer klareren Vorstellung davon sind Sie besser in der Lage, den Rückstand zu priorisieren.
Ich denke, Scrum macht genau das, was Sie wollen. Das Team als Ganzes fügt Elemente zum Backlog hinzu (Backlog Refinement) und der Product Owner ist die Person im Team, die die Prioritäten festlegt.
Wenn Sie noch keine klare Produktverantwortung haben, müssen Sie ausarbeiten, wie Rechenschaftspflicht und Kontrollen ausgeübt werden und vor allem, wie der Geschäftswert gemessen wird. Diese jährlichen Ziele zu haben, ist ein Anfang, aber es ist sehr unwahrscheinlich, dass sie ausreichen, da solche langfristigen Ziele mit einem inhärenten Risiko verbunden sind. Um erfolgreich zu sein, muss das Team bei jeder Iteration Ergebnisse liefern, Feedback von Stakeholdern einholen und dann seinen Ansatz basierend auf diesem Feedback anpassen. Die Rolle des PO besteht darin, dies zu ermöglichen und so den Wert der vom Team geleisteten Arbeit zu optimieren.
Wie in anderen Antworten erwähnt, können Sie sich für eine Story-Mapping-Übung entscheiden, aber zuerst sollten Sie erwägen, alle Beteiligten an einem Priorisierungsrahmen und übergeordneten Zielen/Themen/ Epics (für das Produkt, das Sie erstellen) auszurichten.
Das Hauptproblem beim Bottom-up-Ansatz ist die Divergenz von Ideen verschiedener Personen, die mit den vorliegenden Zielen/Problemen übereinstimmen können oder nicht. Wenn die Teilnehmer die wichtigsten Herausforderungen kennen, die sie lösen müssen, und auch ein allgemeines Gefühl dafür haben, wie ihre Elemente im Vergleich zu anderen Ideen priorisiert werden, wäre der Rückstand von Anfang an verfeinert.
Ein wirklich unterhaltsamer Weg ist ein Design Sprint . Gefolgt von Impact-Mapping und User-Story-Mapping .
Verlassen Sie abhängig von Ihrem Produkt das verdammte Gebäude und lassen Sie die Entwickler mit tatsächlichen Benutzern sprechen. Informieren Sie sich vielleicht über das Shiftup-Programm, das Ihnen hilft, kontinuierliche Innovationen zu fördern.
Bringen Sie das Team mit den Benutzern und wichtigen Interessengruppen zusammen, führen Sie Gespräche und Feedbackschleifen und entdecken Sie die Funktionen GEMEINSAM !
Auch die User Story Mapping Technik kann ich sehr empfehlen. Damit kann man sein Team in eine Richtung ausrichten und alle Teammitglieder können das Projekt planen. Wenn alle am Planungsprozess beteiligt sind, ist die Eigenverantwortung viel höher.
Ich sehe oft Teams, die gleichzeitig einen Top-Down- und einen Bottom-Up-Ansatz verfolgen. Aber andererseits verwende ich den Begriff „bottom-up“ vielleicht etwas anders.
"User Stories" sind für mich von oben nach unten: "Dieses Gebäude wird einen prächtigen Steinbogen über dem Vordereingang haben."
Aber gleichzeitig arbeitet jemand auch von unten nach oben und findet heraus, wie man diese Dinge tatsächlich im größeren Kontext des Ganzen implementiert. „Um dies zu tun, müssen wir an Tag 41 eine temporäre Stützstruktur an Ort und Stelle haben, die in der Lage ist, 2.300 Pfund zu tragen. Die so konstruiert sein muss. Daher müssen bis Tag 36 die Fundamente vorhanden sein und getestet, um sicherzustellen, dass sie das Gewicht halten."
Die Teams teilen sich auf, um beide Enden gleichzeitig zu betrachten, um sicherzustellen, dass sie sich in der Mitte treffen.