Feature Breakdown: schnell User Stories finden und grob schätzen

Die Produktwerker

Adrian Salamon im Gespräch mit Tim

In dieser Folge haben wir Adrian Salamon von tarent solutions zu Gast. Adrian ist Scrum Master und stellt uns das von ihm mit seinem Team entwickelte Vorgehen des sogenannten "Feature Breakdown" vor.

Ihr wollt gegenüber euren Stakeholdern aussagefähig sein, wann ein Feature kommt? Ihr wollt alles splitten? Zugleich wollt ihr nicht in irrsinnig langen Refinement Sessions sitzen? Dann hört euch diesen spannenden Erfahrungsbericht des Teams von tarent solutions an.

Ausgangslage: Der Product Owner (vom Auftraggeber) und das externe Team waren mit ihrem Refinement Prozess nicht sonderlich zufrieden. Die User Stories waren schlecht geschnitten und hin und wieder fehlte auch mal eine Story, um den vollen Nutzerwert liefern zu können. Die Refinement Meetings waren tendenziell zu lang und zu detailliert. Zugleich baten die Stakeholder schon oft sehr früh um zumindest grobe Schätzungen (Zeit/Geld) für einzelne Features. Keiner war so richtig zufrieden mit der Situation.

Dies war der Startpunkt einer Lernreise mit verschiedenen Experimenten, über die Adrian im Gespräch ausführlich berichtet und seine Learnings teilt. Dabei ist das Team an Behavioral Driven Development, Three-Amigos-Meetings und mehrstufigen QA-Checks vorbeigekommen. Aber immer blieb eine Unzufriedenheit: entweder mit der Geschwindigkeit der Meetings und/oder mit der Qualität und Sinnhaftigkeit der User Stories.

Nach einigen Iterationen fand Adrian zusammen mit seinen Teammitgliedern von tarent sowie den Stakeholdern auf Kundenseite ein Vorgehen ("Feature Breakdown"), welches allen Beteiligten sehr hilft, (zu) große Features in effektiver Weise runter zu brechen. Dabei wird durch Adrian als Scrum Master auf ein sehr striktes Timeboxing geachtet, was zu großer Effizienz führt.

Das vorgestellte Verfahren wird in dem international verteilten Team von tarent natürlich komplett remote durchgeführt.

Adrian Salamon hat das ganze Vorgehen auch in einem Blogpost seiner Firma ausführlich beschrieben: https://www.tarent.de/blog/improving-the-flow

Im Kontext dieser Folge könnten auf diese Episoden für euch relevant sein:

• Hilfe, mein Backlog ist explodiert
• Mein Freund der Scrum Master

Wenn ihr direkten Kontakt zu Adrian aufnehmen möchtet, um weitere Fragen zu stellen, erreicht ihr ihn z.B. per Mail: [e-mail]

Wenn euch die Folge gefällt, freuen wir uns über eine positive Bewertung in eurer Podcast App oder als Feedback auf produktwerker.de, per Mail an [e-mail] oder via Instagram oder Twitter.

Kapitel

1. Intro (00:00:00)

2. Gesprächsbeginn (00:01:25)

3. Vorstellung Adrian Salamon (00:01:58)

4. Was war der Schmerz, der die Überlegung ausgelöst hast? (00:03:47)

5. Three-Amigos-Meeting (00:05:35)

6. Was war der konkrete Auslöser? (00:06:30)

7. Der Auftraggeber will frühzeitig Schätzungen (00:08:05)

8. Welche Experimente habt ihr gemacht? (00:09:32)

9. Rolle des Scrum Masters bei der Lösungssuche mit dem Product Owner (00:16:20)

10. Wie läuft das Feature Breakdown genau ab? (00:18:20)

11. Welche Vorteile seht ihr durch das Feature Breakdown? Wo sind Grenzen? (00:25:15)

12. Offenes Verhältnis Dienstleister zum Kunden (00:28:00)

13. Developer schreiben User Stories (00:29:30)

14. Was sagen die Developer und Stakeholder dazu? (00:32:23)

15. Wie guckt das Umfeld auf das Feature Breakdown? (00:35:30)

16. Was sind die Herausforderungen für Dich als Scrum Master dabei? (00:36:30)

17. ...und das alles geschieht remote und mehrsprachig? (00:39:18)

18. Wie verbreitet Ihr solche Learnings bei tarent solutions? (00:40:23)

19. Outro (00:42:00)