Thomas: Also ich sitze hier mit Sebastian zusammen. Er ist der Tech-Mentor bei uns in der Product Masterclass. Grüß dich, Sebastian!
Sebastian: Hi. Servus, Thomas.
Thomas: Servus. So, wir haben heute ein schönes Thema, nämlich Refinements. Sebastian, erzähl mal, was sind Refinements?
Sebastian: Also wie Refinements, ursprünglich kommt es aus dem Scrum-Framework, was jeder sicherlich schon mal gehört und beschreibt einfach den Prozess oder das Meeting, was du regelmäßig hast, wo der Produktmanager, der Product Owner quasi die Requirements mit dem Team refined, also sprich durchspricht detailliert und im Endeffekt, wie man so schön sagt: Ready for Development. Also fertig für die Implementierung.
Thomas: Und warum macht man das genau?
Sebastian: Also grundsätzlich ist es so, es gibt zwei, es gibt zwei Gründe beziehungsweise zwei Seiten. Es gibt ja einmal die Seite des Managers, des POs, und einmal die Seite des Entwicklungsteams. Und der PO kümmert sich, also da muss ich jetzt mal einen kleinen Tacken ausholen, also der PO kümmert sich ja grundsätzlich darum, von den Stakeholdern auch ein Stück weit das "Warum" abzuholen. Warum brauchen wir gewisse Dinge? Oder warum wollen wir irgendwie einen gewissen Wert schaffen? Und das Entwicklungsteam arbeitet quasi von unten rein in das "Wie"? Wie muss ich das konkret implementieren, um diesen Wert zu schaffen? Und was wir in dem Refinement machen, ist über die Zwischenebene zu sprechen, nämlich das "Was". Also was müssen wir konkret schaffen, bauen, um diesen Wert abbilden zu können? Und das bedeutet, man macht diese Refinements vor allen Dingen, um sich gegenseitig auf dieses "Was" zu verständigen. In der Praxis ist es oft so, dass der PO vielleicht vorher auch schon mit einem Designer zusammen, gewisse Flows erarbeitet hat, die Requirements schon mal runtergeschrieben hat, der Stakeholder. Und man geht halt her und spricht dann zusammen mit dem Entwicklungsteam, um auch die technische Perspektive reinzubringen, die unterschiedlichen Lösungsvarianten, die man dort hat.
Thomas: Und auf welcher Ebene machst du Refinements? Also machst du das wirklich Epic-Leben-Ebene und sprichst quasi schon über das Big-Picture. Oder ist es wirklich auf granularer Ebene, Story-Ebene, wo du die einzelnen Details quasi durchsprichst?
Sebastian: Es kommt ein bisschen darauf an. Also ich persönlich habe ganz gute Erfahrungen damit gemacht, herzugehen und so zwei Ebenen von Refinements machen. Also sprich, ich gehe vielleicht, wenn man jetzt mal in so einem typischen Scrum-Sprint-Modus ist, ich habe irgendwie zwei Wochen, macht einmal die Woche vielleicht ein Refinement. Ja, dann gehe ich vielleicht in der ersten Woche hin und mache eher so ein grobes Refinement. Das ist eher so, um ein bisschen Ideen zu sammeln. Also ist eher auf Epic-Ebene, wo man sagt, okay, ein Stakeholder, sagen wir mal, wir müssen vielleicht eine Registrierstrecke bauen und dann überlegen wir einfach, wie wir diese Registrierstrecke mit den Anforderungen, die ich jetzt schon aufgenommen habe, wie wir die irgendwie bestmöglich in das Produkt reinbauen. Und auf Basis dessen würde ich dann wahrscheinlich hingehen und diese Ideen mitnehmen und das ganze mal etwas granularer zerschneiden und würde das dann halt in wirkliche Stories auseinander schneiden. Und diese Stories würde ich dann aber auch noch einmal in einem Refinement, vielleicht zweite Runde nehmen, um im Endeffekt diesen Input des Entwicklungsteams schon mal mitgenommen zu haben und dann wirklich mit konkreten, gegebenenfalls mit Designern ausgearbeiteten Sichten, in Designs reinzugehen und wirklich auf Detail-Level-Requirements zu gehen.
Thomas: Das sind ja natürlich jetzt auch wieder, ich sage mal, Overhead-Kosten, ja also Meetingzeit et cetera. Hast du irgendwie Best Practices? Machst du das immer mit einem kompletten Team oder nimmst du manchmal einzelne Personen raus, um auch Zeit zu sparen? Oder wie gehst du dort eben am besten, am smartesten vor?
Sebastian: Ich glaube, das kommt auch ganz stark auf das Setup an. Also grundsätzlich bin ich ein Fan davon, mit dem ganzen Team Refinements zu machen. Also vor allen Dingen Detail-Refinements mache ich sehr, sehr gerne mit dem ganzen Team. Wenn es um Grob-Refinements geht, dann kann man auch im Endeffekt über eine Ebene, also ich nenne das jetzt mal Feature Squad, ja, wenn man mal auf dem Epic-Level beispielsweise, dann geht vielleicht der PO mit rein, dann gibt es vielleicht einen Entwickler aus dem Team, dann kommt ein Designer mit rein und dann bereitet man schon mal Grob-Requirements vor, auf einer Epic-Ebene. Das kann ich mir dann gut vorstellen, dass auch nicht mit dem kompletten Team zu machen, aber wenn es dann wirklich um Detail-Refinements geht, finde ich immer schön eigentlich das ganze Team dabei zu haben. Jeder hat ja auch noch mal eine andere Sicht ein bisschen auf die Dinge. Du hast gegebenenfalls Front- and Backend Position in so einem Team. Dann holt man sich halt einfach so diesen maximalen Input von allen Seiten ab. Und vor allen Dingen ist es ja auch die Aufgabe von einem Entwicklungsteam dann diese Requirements zu challengen. Und ich sage mal, jeder hat mal einen schlechten Tag. Deswegen ist es halt auch ganz gut, dann mit dem ganzen Team das zusammen zu machen.
Thomas: Perfekt. Vielleicht noch, wie oft machst du das? Oder in welchem Abstand machst du das?
Sebastian: Also dadurch, dass wir iterativ arbeiten, also dass ich in der Regel iterativ arbeite, ist es jetzt nicht so, dass man es einmal am Anfang von einem Projekt macht und dann am Ende oder irgendwie alle drei Monate oder ähnliches, sondern wir machen das halt schon während der Produktentwicklung regelmäßig. Also auch das kommt stark darauf an, in welcher Phase man sich befindet. Also zu Anfang braucht man wahrscheinlich häufiger diese Refinements, also vielleicht sogar einmal pro Woche. Nachher reicht vielleicht alle zwei Wochen aus. Das hat immer so ein bisschen damit zu tun, wie groß ist das Team? In welcher Phase befinde ich mich? Es kann auch teilweise sein, also was ich immer mache, ist, feste Slots für die Refinements. Und ich sage lieber dann eins ab und alle freuen sich über die Fokus-Zeit, als dass ich das On-Demand mache, weil die Erfahrung zeigt doch schon, dass einfach wirklich gute und regelmäßige Refinements uns dazu beitragen, dass man einfach wirklich ein gleiches Bild für die Dinge, die wir halt implementieren wollen, schaffen kann. Und das ist eigentlich so aus Produktsicht, finde ich persönlich immer, einer der größten Risiken, die wir da haben. Das heißt, der Stakeholder sagt, dass eine, der PO versteht das andere und das Entwicklungsteam baut dann irgendwie was Drittes. Und das heißt, diese Refinements, vielleicht das noch dazu, auch in einem Refinement kann gegebenenfalls ein Stakeholder mit eingeladen werden, damit er vielleicht noch mal das eine oder andere mit reingeben kann. Das ist bestimmt in der Praxis nicht so die Situation, die häufig passiert, aber das kann einfach auch helfen. Diese User Stories, und darüber haben ja auch schon gesprochen. User Stories sind im Endeffekt ein Alignment Instrument. Also wir wollen eine gemeinsame Sicht auf das, was nachher das Endergebnis sein soll. Und letzten Endes sind die Refinements quasi das Mittel, um in diesen User Stories das gemeinsame Verständnis zu formen.
Thomas: Ja, cool. Okay. Gibt es ansonsten noch irgendwie Best Practices oder sonstige Gedanken, die wir jetzt noch nicht angesprochen haben? Sieht nicht so aus.
Sebastian: Ich glaube, wir haben eigentlich so alle wichtigen Punkte.
Thomas: Perfekt. Also Refinements regelmäßig machen mit dem Team fürs Alignment und eben auch ganz wichtig als PO reinbringen, ja, was ist das "Warum". Das wird wahrscheinlich oft in der Praxis auch nicht ganz so gelebt und dann habt ihr eine gute Zeit, wenn ihr vorher schon eine feste Schedule gehabt und nicht peu à peu Ecke kommt und noch mal einen Termin ausmachen müsst mit den Entwicklern.
Sebastian: Ganz gut zusammengefasst.
Thomas: Super, vielen Dank dir Sebastian.
Sebastian: Danke Thomas.
