Verbessere jetzt dein Backlog Refinement

Was kann ich für dich tun?

Du hast Fragen zu deinen Scrum-Projekten? Stell mir deine Frage oder kontaktiere mich gerne direkt.

Frage zu Scrum

Kontakt

Warum ich Sie hier duze?

Zum Scrum Kurs

Zum Scrum SkalierungsKurs

Ich habe seit knapp zwei Jahren das Vergnügen gemeinsam mit Sebastian in einem Produkt mit mehreren skalierten Teams als Coach zu arbeiten und zu wirken. An Sebastian schätze ich vor allem sein sympathisches Auftreten, seine kreative Herangehensweise an Problemstellungen und die Anwendung seines systemischen Know-Hows auf agile Frameworks. Sein Wirken zeigt sich vor allem auf der Ebene des agilen Portfoliomanagements, indem er bei unseren Partnern immer wertvolle Impulse setzt und das bigger Picture nie aus den Augen verliert. Ich kann die Zusammenarbeit mit ihm nur empfehlen. (Translated by Google) For almost two years I have had the pleasure of working and acting as a coach with Sebastian in a product with several scaled teams. What I particularly appreciate about Sebastian is his personable demeanor, his creative approach to problems and the application of his systemic know-how to agile frameworks. His work is particularly evident at the level of agile portfolio management, by always providing valuable impulses to our partners and never losing sight of the bigger picture. I can only recommend working with him.Lisa OrdnerMarch 11, 2021

Herr Schneider berät uns durchgehend bei Fragen oder Problemen zur agilen Softwareentwicklung und unterstützt uns derzeitig unser Scrum mit LeSS zu skalieren. Hierbei sieht er das große Ganze, das uns oft verborgen bleibt und kann uns so durch seine Expertise maßgeschneiderte Prozesse entwerfen. Wir schätzen Ihn aufgrund seiner freundlichen und professionellen Art und hoffen auf eine weiterhin tolle Zusammenarbeit. (Translated by Google) Mr. Schneider advises us continuously on questions or problems regarding agile software development and currently supports us in scaling our Scrum with LeSS. Here he sees the big picture, which is often hidden from us, and can use his expertise to design tailor-made processes for us. We appreciate him because of his friendly and professional nature and hope to continue working with him.Bernd FechtMarch 10, 2021

Agile Skalierung auf höchstem Niveau: Egal ob LeSS, SAFe oder maßgeschneidert, hier stehen die Kundenbedürfnisse im Mittelpunkt. Neben dem Entwickeln von Prozessen werden auch die agilen Rollen durch Schulungen, Coaching und Mentoring begleitet, um nachhaltig Agilität im Unternehmen zu etablieren. (Translated by Google) Agile scaling at the highest level: Regardless of whether LeSS, SAFe or tailor-made, the focus here is on customer needs. In addition to developing processes, the agile roles are also accompanied by training, coaching and mentoring in order to establish sustainable agility in the company.Oliver MonnekeNovember 12, 2020

Herr Schneider hat uns über einen längeren Zeitraum bei einer agilen Transformation unterstützt. Sein Wissen hat uns stark bereichert und wir haben stets seine Kompetenz geschätzt. Wir freuen uns auch in Zukunft wieder mit ihm zusammen arbeiten zu dürfen. Herzlichen Dank, Christoph Wagner (Translated by Google) Mr. Schneider supported us with an agile transformation over a longer period of time. His knowledge has greatly enriched us and we have always valued his competence. We look forward to working with him again in the future. Thank you very much, Christoph WagnerChristophSeptember 8, 2020

Ich schätze Herrn Schneider vor allem für seine Kreativität und schnelle Lösungsfindung. Sehr professionell, kundenorientiert und auf den Punkt. Das Coaching mit Herrn Schneider ebenso wie die hoch professionellen Scrum Kurse haben mich beruflich und persönlich sehr stark weitergebracht. Klare Empfehlung! Vielen Dank dafür! (Translated by Google) I particularly appreciate Mr. Schneider for his creativity and quick solution finding. Very professional, customer-oriented and to the point. The coaching with Mr. Schneider as well as the highly professional Scrum courses have brought me a lot forward professionally and personally. Clear recommendation! Thanks a lot for this!Christina B.June 26, 2020

Sehr kompetente Kollegen - ich schätze die undogmatische Herangehensweise und den Methodenmix (Translated by Google) Very competent colleagues - I appreciate the undogmatic approach and the method mixBirgit MallowFebruary 23, 2019

Die Einführung zum agilen Management sowie die Trainings zu Scrum waren äußerst informativ und exzellent aufgearbeitet. Der Inhalt wurde effektiv und nachhaltig vermittelt. (Translated by Google) The introduction to agile management and the training on Scrum were extremely informative and excellent. The content was conveyed effectively and sustainably.Nadine ErnstNovember 21, 2018

Hervorragende Beratung, kann man uneingeschränkt weiterempfehlen. (Translated by Google) Excellent advice, can be recommended without reservation.Jah TafariNovember 14, 2018

Interessante Artikel

Unterschiedliche Sprintlängen (und welche Auswirkungen es hat)

Entwicklungsbegleitende Tätigkeit

Planung in Scrum: diese 3 Varianten kommen vor (mit Vergleich)

Die häufigsten Scrum Fragen (und die richtigen Antworten)

Das Flow Board (5 Schritte für schnelleres Scrum)

Muster: Ebenen oder Einheiten

Das Backlog Refinement ist ein sehr wichtige Tätigkeit in Scrum. Durch das Backlog Refinement versetzt sich das Scrum Team in die Lage, das Backlog kontinuierlich aufzubereiten und ein gemeinsames Verständnis über die enthaltenen Product Backlog Items zu bekommen. Alles was das Product Backlog Refinement verlassen hat und von allen verstanden ist, kann in einer Sprint Planung betrachtet werden.

Inhaltsverzeichnis

Das Backlog Refinement

1.1

Das Backlog Refinement im Scrum Guide

1.2

Das Ziel für das Backlog Refinement

1.3

Ablauf des Backlog Refinements

1.3.1

Voraussetzungen für die Durchführung

1.3.2

Das Refinement im Ablauf

1.3.3

Nach dem Refinement

Die wichtigen Punkte für das Backlog Refinement

2.1

Meine Erfahrungen zum Backlog Refinement

2.2

Backlog Refinement im Jira richtig durchführen

Zeitpunkt für das Backlog Refinement

3.1

Keine Zeit zwischen zwei Sprints

3.2

Backlog Refinement nach der Planung und vor dem Review

Vorlage für die Einladung

Das Backlog Refinement

Das Backlog Refinement in Scrum ist eine sehr wichtige entwicklungsbegleitende Tätigkeit, die im Scrum Guide mit etwa 10% der Entwicklungskapazität des Team berechnet wird. Ziel dieser Aktivität ist es, dass Anforderungen aus dem Product Backlog eine gewisse Reife erlangen, um in der Sprint Planung für einen Sprint geplant werden zu können. Das Entwicklungsteam und der Product Owner haben in diesem Backlog Refinement die Möglichkeit das Verständnis zu schärfen: sie detallieren Anforderung, schätzen und schneiden diese so, dass sie sinnvoll in einen Sprint bearbeitet werden können.

Das Backlog Refinement im Scrum Guide

Scrum Guide

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner's discretion.

Das Ziel für das Backlog Refinement

Das Backlog Refinement hat das Ziel, die Anforderungen die sich im Product Backlog befinden, so weit aufzubereiten, dass diese in die Sprint Planung gelangen können. Diese Anforderungen werden Product Backlog Items genannt. Damit das geschehen kann, sind in der Regel die folgenden Schritte nötig

Häufig spricht man auch von der sogenannten Definition of Ready. Dabei musst du beachten, dass eine Definition of Ready nicht zu einem sequentiellen Vorgehen führt und du dir unnötige Schwierigkeiten und weitere überflüssige Arbeitsschritte einhandelst. Details findest du in meinem Artikel, warum wir keine Defintion of Ready benötigen.

Im Folgenden findest du die notwendigen Schritte für das Backlog Refinement:

Diskussion und Vorstellung der Product Backlog Items durch den Product Owner. Er muss die Anforderungen (also das "was" will der Kunde) vom Kunden verstanden haben und kann diese dem Team vorstellen und Fragen dazu beantworten.
Festlegen von Akzeptanzkriterien. Durch die Diskussion mit Kunden und dem Entwicklungsteam schärft der Product Owner das Verständnis über die Product Backlog Items. Er hält der mit Akzeptanzkriterien fest, wann für ihn die Anforderung erfüllt ist. Dafür verwendet er typischerweise Ausdrücke, die ein Erlebnis oder eine erlebbare Aktion beschreiben.
Schneiden von Product Backlog Items. Die Einträge, die sich im Product Backlog befinden, benötigen die richtige Größe. Sie müssen nämlich in einen Sprint passen. Je kleiner wertvolle Einträge sind, desto besser.
Schätzen der Einträge. Alle Einträge im Product Backlog sollten geschätzt sein. Das Entwicklungsteam schätzt die Einträge, der Product Owner schätzt nicht mit.

Ablauf des Backlog Refinements

Zum Ablauf direkt sagt der Scrum Guide nicht viel aus und lässt Freiheiten. Es bleibt dir überlassen eine angemessene Lösung dafür zu finden. Eine Möglichkeit für den Ablauf im Backlog Refinement könnte so aussehen.

Voraussetzungen für die Durchführung

Einigung auf einen Termin. Bevor du das eigentlich Backlog Refinement starten kannst, benötigst du natürlich den Termin. Diesen stimmen das Entwicklungsteam und der Product Owner gemeinsam ab. Dieser Termin kann auch eine spontane Session sein. Da eine Backlog Refinement eine entwicklungsbegleitende Tätigkeit ist, kann diese auch einfach zur richtigen Zeit stattfinden.
Wer lädt ein? Nicht jedes neue Team macht sich gleich an die Arbeit, wenn es Unklarheiten gibt. Es lohnt sich zu überlegen, wer "Meeting-Host" ist. Dabei bietet sich der Scrum Master an, wenn er alle anderen Termine auch verwaltet. Damit liegen dann alle Termine in einer Hand. Durch den Product Owner kann eine gewisse Wichtigkeit ausgedrückt werden, wenn er zu diesem Event einläd. Wenn er das bei dir auch schon beim Sprint Review macht, bietet sich dieser Termin ggf. auch an.

Das Refinement im Ablauf

Der Ablauf im Backlog Refinement ist eine Schleife über alle Product Backlog Items, bis die Zeit um ist oder bis kein Diskussionsbedarf mehr über weitere Anforderungen herrscht.

Vorstellung des Product Backlog Items. Der Product Owner stellt das entsprechende Product Backlog Item vor. Dazu liest er es in der Regel vor und erklärt dem Entwicklungsteam, was damit gemeint ist. Im Vorfeld kann der Product Owner schon Akzeptanzkriterien eingefügt haben.
Fragen des Entwicklungsteam. Nach der Vorstellung fragt das Entwicklungsteam den Product Owner zu diesem Product Backlog Item. Das Ergebnis dieser Diskussion wird im Product Backlog Item festgehalten. Es kann bei dieser Diskussion auch herauskommen, dass zu wenig Informationen vorliegen oder noch weitere Akzeptanzkriterien nötig sind.
Aktualisierung / Hinzufügen von Akzeptanzkriterien. Durch die Diskussion und das Lernen entstehen oft neue Erkenntnisse, die sich in Form von neuen bzw. erweiterten Akzeptanzkriterien ausdrücken lassen.
Schneiden von PBIs. Das Team versucht möglichst kleine Anforderungen zu behandeln. Mindestens muss so eine Anforderung in den Sprint passen. Deshalb müssen zu große Einträge weiter geschnitten (verkleinert) werden.
Schätzen von Einträgen. Die eben erstellten oder besprochenen Product Backlog Einträge werden geschätzt. Am besten in einer Art und Weise, die dem agilen Schätzen naheliegt.

Nach dem Refinement

Optimalerweise konnten alle Fragen und Anmerkungen direkt im Backlog Refinement geklärt werden. Durchaus wird eine Frage im Nachgang noch geklärt, vielleicht nicht mehr zwischen allen. Diese Informationen müssen dann selbstständig und gewissenhaft durch die entsprechenden Personen im Product Backlog aufgenommen werden.

Die wichtigen Punkte für das Backlog Refinement

Aus meiner Sicht, sind die folgenden Punkt immer wieder wichtig. Wenn Probleme im Backlog Refinement auftreten, dann oft genau in den folgenden Hinweisen.

Achte darauf, dass ausreichend Zeit für das Backlog Refinement vorgesehen ist. Unterschätze nicht die Zeit, die es benötigt, um Anforderungen "fertig zur Bearbeitung" zu bekommen.
Stelle sicher, dass eine klare Definition of Done existiert. Existiert diese nicht, wird viel zwischen Akzeptanzkriterien und der Defintion of Done hin und herspringen. Dabei machen Sie sehr wahrscheinlich redundante Kommunikation, die überflüssig sein kann. Zudem kann das Entwicklungsteam schlechter schätzen, wenn nicht klar ist, was fertig bedeutet.
Frage immer aktiv nach, ob die Product Backlog Items beim Entwicklungsteam auch wirklich verstanden sind. Hast du reife Teams, die die Scrum Werte schon verinnerlicht haben, braucht es diese Nachfrage weniger. Ansonsten gilt gerade für den Scrum Master: Augen auf, die richtigen Fragen stellen und zudem Augenmerkt auf die richtigen Teilnehmer legen.

Meine Erfahrungen zum Backlog Refinement

Im folgenden findest du noch einige Erfahrungspunkte zum Backlog Refinement von mir aus der Praxis:

Bevor der erste Sprint startet, finde ich es als hilfreich mit dem Entwicklungsteam und dem Product Owner ein bis zwei Refinements durchzuführen, um das initiale Backlog auf einen guten Stand zu bringen. Das musst du nicht tun, es hilft in meinen Augen aber sehr, dass die nachfolgenden Events in Scrum schnell und gut durchgeführt werden können, da die Basis der Anforderungen auf einem guten Stand ist.
Es kann Projekte geben, in denen das Backlog Refinement nur minimale Zeit in Anspruch nimmt. Plane es aber trotzdem. Wenn du beginnst, orientiere dich bitte immer an der 10%-Regel aus dem Scrum Guide.
Ich nutze eine klare Vereinbarungen (wie ein Team Charter) zwischen Team und Product Owner: das Backlog Refinement ist - wie die anderen Events auch - ein fester Termin mit Agenda, um das Thema der Komplexität zu verringern und einen Rahmen zu schaffen. Zusätzliche spontane Session werden meistens trotzdem benötigt.
Können die Product Backlog Items im Refinement innerhalb von ca. 20 Minuten besprochen werden, dass das "was" klar ist? Wenn nein, dann sind sie in der Regel zu groß oder benötigen noch weitere Verfeinerungen. Auch das ist sehr abhängig vom Kontext, stellt für mich aber einen Wert bei der Analyse von neuen Teams dar.

Backlog Refinement im Jira richtig durchführen

Wenn du auch das Tool Jira von Atlassian nutzt, dann kannst du das Refinement mit allen Punkten, die hier genannt sind, durchführen. Wenn du noch einen Tipp für das Marieren und Finden von relevanten Product Backlog Items suchst, dann schaue dir gerne noch mein YouTube Video dazu an!

Zeitpunkt für das Backlog Refinement

Das Backlog Refinement ist eine entwicklungsbegleitende Tätigkeit und hat keinen festen Platz, wie ein Event in Scrum. Schauen wir uns einmal die Möglichkeiten an, wo und wie das Backlog Refinement am besten untergebracht werden kann.

Keine Zeit zwischen zwei Sprints

Grundsätzlich findet das Backlog Refinement innerhalb des Sprints statt. Es gibt keine Zeit zwischen zwei Sprints. Bedenke, es kostet dich immer Kapazität innerhalb des Sprints!

Backlog Refinement nach der Planung und vor dem Review

Meistens liegen die Sprintwechsel in Organisationen so, dass nach ein paar Tagen, üblicherweise nach etwa der Hälfte des Sprints ein Refinement stattfindet. Wenn du zwei Termine machst, findet das Refinement üblicherweise nicht in den ersten Stunden nach der Sprint Planung statt und auch nicht in den letzten Stunden vor dem Sprint Review.

Vorlage für die Einladung

Vorlage

Liebes Team,

ich möchte euch hiermit zu unserem Backlog Refinement einladen. In diesem Regeltermin kümmern wir uns um die Reife der Einträge im Backlog.

Datum & Zeit:

xx.xx.xxxx (ggf. auch Serientermin), um xx.xxUhr

Ziel:

Verfeinerung der Product Backlog Items und Schaffen eines gemeinsames Verständnis über Anforderungen

Agenda:

Vorstellung neuer oder wichtiger Product Backlog Items (PBIs) durch den Product Owner
Fragen zu dem PBI durch das Entwicklungsteam
Verfeinerung des PBI durch Überprüfung und ggf. Erweiterung der Akzeptanzkriterien
Überprüfung auf die richtige Größe: kann das PBI im Sprint umgesetzt werden? Wenn nicht, wie schneider wir diese Anforderung?
Schätzen der Anforderungen

Vielen Dank im Voraus für eure Teilnahe und Engagement,

[Scrum Master oder Product Owner]

Sebastian

Ein paar Worte über den Autor

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt. Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben. Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen. Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.