Das Einführen von Scrum fühlt sich für Unternehmen sehr attraktiv an. Sie sehen Scrum in Verbindung mit Teamwork, Lieferung funktionierender Software, einer engen Zusammenarbeit mit dem (internen) Auftraggeber und ein Arbeiten in einem fest definierten Zeitrahmen. Eine der größten Hürden für Unternehmen ist offensichtlich die Suche nach einem eindeutigen Product Owner und der Aufbau eines Product Backlogs.

Wie kann nun Scrum als Vorgehensmodell helfen, in einer Abteilung auf die Organisationsstruktur einzuwirken und die fachlichen, kreativen Ideen und Diskussionen zu bündeln und als User Stories in einem Product Backlog abzubilden?

Die Organisationsstruktur setzt ein dediziertes Entwicklerteam, einen ScrumMaster und einen Product Owner voraus. Was aber, wenn neben dem neuen Produkt auch noch ein Legacy-System unterhalten werden muss? Oder wenn es den eindeutigen Product Owner auf den ersten Blick nicht gibt?

Der Aufbau eines Product Backlogs ist häufig kein triviales Unterfangen, da bei der Einführung von Scrum die meisten Teammitglieder nur langsam mit der Grundphilosophie der Agilität vertraut werden. Sie fragen sich wie User Stories geschrieben werden? Desweiteren benötigen sie Zeit um den kompletten Scope zu spezifizieren und schließlich zu priorisieren? Und – wie finden sie sich zurecht in Ihrem neuen Team? Die Fragenkette scheint an dieser Stelle endlos zu sein.

Dieser Vortrag zeigt anhand des Praxisbeispiels bei 1&1 Development Hosting auf, wie eine Abteilung in kurzer Zeit der Weg von einem leeren Blatt hin zu einem verlässlichen, geschätzten und priorisierten Product Backlog aussehen kann. In diesem Rahmen wird auch die Methodik der „Ähnlichkeitsschätzung“ (engl. Affinity Estimation) vorgestellt, die es erlaubt bspw. mehr als 300 - 400 User Stories an einem Tag zu schätzen.