When it comes to successful product development, there’s one technique that stands out: refining the work you need to do to deliver real value. In Scrum, this is known as Product Backlog refinement, and it’s a game-changer. Think of it as the process where big ideas get shaped into clear, actionable tasks that can be tackled within a Sprint. According to the Scrum Guide, refinement is “the act of breaking down and further defining Product Backlog items into smaller more precise items.”. This isn’t a one-time thing—it's an ongoing practice that happens throughout a Sprint. The goal? To ensure you're always moving in the right direction. But refinement is more than just breaking tasks down. It's about adding enough detail so that when the work is done, you know it’s done right. This includes setting acceptance criteria, estimating effort, and sometimes even prioritizing what comes next. It’s all about setting your team up for success, step by step.
As an Agile Coach, whenever I join new teams, I notice a common pattern during most Product Backlog refinement sessions:
On the surface, this process seems efficient. The Product Backlog gets updated, and the team leaves with a list of items ready for the next Sprint Planning session. However, I believe that this approach often misses key opportunities for a truly effective Product Backlog refinement. In this article, I’ll share a few strategies that can elevate your refinement sessions, ensuring you unlock the full potential of this critical activity:
Let’s dive into each of these ideas and explore how they can supercharge your Product Backlog refinement process:
This approach is particularly effective when multiple teams are working on the same product. If refinement is done informally during the Sprint, teams tend to focus only on items related to their current work, which they’ll likely select for the next Sprint. While this may seem efficient, it limits knowledge-sharing between teams and reduces the flexibility to redistribute work as needed. In agile organizations, adaptability is key. Teams should be able to help each other and take on tasks that may not be tied to their previous Sprint but are more valuable or higher-priority in the Product Backlog.
For different teams to pick the most valuable items, it’s essential that all teams are familiar with those key items. This is why frameworks like LeSS (Large-Scale Scrum) recommend holding Product Backlog refinement as a cross-team event. It encourages shared learning and opens up coordination opportunities between teams. One practical way to ensure teams have a broad understanding of the most important backlog items is to create mixed groups of developers from different teams to refine the items together.
Another significant reason for scheduling Product Backlog refinement as a formal event, as suggested by LeSS, is to consolidate non-Sprint related work into a timeboxed session. This frees up developers to focus exclusively on Sprint-related tasks during the rest of the Sprint. The key here is that the event should be strictly timeboxed—usually no more than 10% of the Sprint duration, which means about one day in a two-week Sprint. And importantly, you only need to hold the refinement session if there’s an insufficient number of detailed backlog items to last through the next two or three Sprints.
As I mentioned earlier, the key goals of Product Backlog refinement is twofold: (1) to ensure there are enough refined items in the backlog so that teams can move through Sprint Planning quickly, selecting the most important tasks from the top of the backlog without needing further clarification, and (2) to effectively distribute the most critical work across all teams working on the product. By conducting Product Backlog refinement as a shared event for all teams, as highlighted in tip number one, you’re already helping to spread knowledge across multiple teams. Since the Product Owner is responsible for maximizing the product’s return on investment, they are the best person to determine which items should be prioritized for the next Sprint and whether it’s necessary for all teams to work on a single topic or to proceed in parallel on different topics. In the first scenario, the PO may want to coordinate the refinement so that mixed groups from all teams break down a single topic into smaller tasks that can then be distributed among the teams. In the second scenario, the PO may organize the refinement such that mixed groups from some teams focus on one topic, while other groups tackle different topics in parallel.
Generally, I recommend that the Agile Coach or Scrum Master collaborate with the PO to prepare for Product Backlog refinement in advance by reviewing the current state of the backlog, considering the outcomes of the last Sprint Review (more on this in the next idea), and identifying additional business or user problems and requests to be discussed. It can also be beneficial to involve a few product developers in the preparation phase to provide input on technical aspects the PO might overlook. The preparation should result in a clear agenda with topics and timeframes for the event. One agenda item could be to gather and add any new topics (such as issues or requests) to the list of items for refinement, but the responsibility for leading the event should remain with the PO, with support from the Scrum Master or Agile Coach.
Agile product development is frequently equated with iterative and incremental approaches. However, if we merely take a large requirement or project, break it down once into smaller pieces, and implement those pieces iteratively and incrementally, we miss the true essence of agile product development. In such a scenario, we might as well have used the traditional waterfall model, potentially achieving even greater efficiency. The true strength of agile lies in its capacity to navigate the uncertainty inherent in complex product development, where our understanding of what needs to be delivered can evolve over time.
Tim Harford, in his book Adapt, references Russian engineer Peter Palchinsky, who highlighted three unpredictable dimensions—local, time, and human factors—that can lead us to misunderstand what customers really want. By embracing principles such as variation (exploring new ideas and testing them), survivability (operating at a scale where failures are manageable), and selection (gathering feedback and learning from it), we can take small steps to iterate and determine whether we're heading in the right direction.
As I noted in a previous article, one effective method for assessing whether we’re delivering the right product is the Sprint Review in Scrum. However, it’s crucial to dedicate a significant portion of the Sprint Review to gathering essential feedback that will inform our next steps. Unless we extend the time allocated for the Sprint Review to adequately sort, filter, and evaluate all feedback in detail, we need to postpone this important task. I believe that the ideal time for this is during the Product Backlog Refinement event, where we can intentionally discuss the work planned for future Sprints. This event provides an invaluable opportunity for the team to assess customer feedback, grasp customer needs, and clarify the purpose of the product.
Who better to explain the real problems and needs a product should solve than the actual users themselves? If you're developing an internal tool, such as a marketing or sales platform, the people who will use the product are the best to clarify functionality requirements and, more importantly, to discuss the underlying purpose of these features. Including these individuals in your Product Backlog Refinement (PBR) sessions could be one of the most impactful steps you take to improve developers' understanding of the product's true needs.
When developing a mass-market product, direct access to users may not be as simple. In some cases, your product developers may be part of the target audience, which allows their perspectives to be integrated naturally. By creating mixed groups of developers from different teams during PBR, you can incorporate diverse end-user viewpoints into the refinement process. However, for mass-market products where developers may not fully represent key personas, you have several alternatives:
While bringing real users into PBR can yield highly valuable feedback and feature suggestions, it can also lead to conflicting opinions. In these cases, it's essential that the Product Owner (PO) remains involved in decision-making, as they are ultimately responsible for maximizing the return on investment (ROI) for the product.
Additionally, it’s critical that the entire discussion during your PBR events is conducted in the language of the customer. If you notice the conversation becoming overly technical—using jargon the customer wouldn't understand—this is a red flag. It may indicate you're working with component teams rather than true end-to-end (or feature) teams, which are necessary to deliver complete value to customers. In such situations, the value of real Product Backlog refinement as described here may be compromised, and an organizational change might be needed before you can fully benefit from the approach and ideas presented.
As mentioned earlier, the primary goal of Product Backlog refinement is to compile a list of work items for the team(s) to tackle during the next iteration, aiming to deliver maximum value or uncover what needs to be delivered to create that value. These items must be detailed and clear enough that the developers who will implement them understand roughly what needs to be done and how long it might take to complete the work in the upcoming Sprint. Some call this having the items "ready” for the next Sprint. From my perspective, achieving this readiness is truly an art! It involves finding the right balance between over-discussion, which can lead to excessive detail, and not diving deep enough into understanding what needs to be done. Over-refining an item could result in waste if the Product Owner (PO) decides the team no longer needs to work on it (which is always possible). On the other hand, under-refining can lead to wasting time by building the wrong thing, or taking much longer to complete the Sprint than originally planned, leaving insufficient time for other work.
The best way to ensure understanding isn’t just through reading or hearing but through meaningful discussion with others. One highly effective technique for refining items is “Specification by Example” by Gojko Adzic, where you articulate clear examples of how you will know that what you are building is exactly what is needed. This method can be done using Gherkin syntax, following the Given-When-Then format, or through tables that document the start and end state along with the action to be performed. By creating small, cross-functional groups of developers with different skill sets (such as testing, front-end, back-end development, business analysis, and design), and having them collaboratively discuss and document examples, you ensure that a wide range of perspectives is captured. Additionally, this approach reinforces everyone’s understanding of why the item is being implemented in the first place.
I recommend forming several smaller groups (each with 4-6 people) to work on refining the items. This way, (1) you incorporate diverse skills, viewpoints, and insights into the discussions, and (2) you avoid having groups that are too large, ensuring everyone participates actively. If multiple teams are working on the same product, it’s even more beneficial to mix team members from different teams (as outlined under idea number 2). This cross-team knowledge-sharing allows multiple teams to confidently pick up items during Sprint Planning, as each team has developers who are already familiar with them.
In some cases, it may be helpful to have different groups refine the same item for a timeboxed period of 30 to 40 minutes, followed by a session where each group shares their results. This process can reveal different approaches, enhance learning, and lead to a better understanding of both the problem to solve and the best way to address it. The sharing of insights can be done by having a representative from each group present to the entire team, or through group rotations, where one person stays behind at each "booth" to explain the group's findings to others.
By creating small, diverse groups of product developers, refining items within timeboxed periods, and then sharing insights, you ensure that developers remain fully engaged throughout the refinement process. This fosters a deeper understanding of what and why something needs to be developed, aligning the team with the ultimate goal of meeting customer needs—the true purpose of refinement.
This is, without a doubt, a vast and crucial topic. If your Product Backlog refinement isn't done effectively, you could be wasting valuable time instead of leveraging it to drive success in your product development activities. It's essential that everyone involved in the product development process is educated in advanced techniques. This goes beyond just breaking down large requirements into smaller ones, but involves defining clear acceptance criteria, properly sizing and ranking items, and excelling at product discovery—all of which are critical for success.
I highly recommend diving deeper into some key resources: Inspired by Marty Cagen, Impact Mapping by Gojko Adzic, the Product Backlog & Product Backlog Refinement guides from Large-Scale Scrum by Craig Larman & Bas Vodde, and of course, the previously mentioned Specification by Example by Gojko Adzic.
You may have noticed that the approaches discussed here don’t necessarily prioritize work efficiency. There may be more time-efficient ways for a single developer to grasp a requirement—such as simply receiving it from the Product Owner (PO) or another stakeholder. If the PO spends time understanding user problems and writing clear requirements, it could indeed be faster for developers to implement them without prolonged discussions. However, I strongly believe that while this might save time upfront, it often leads to a greater waste of time later by implementing features that aren’t truly needed by the customer or missing opportunities to deliver a better solution.
By encouraging product developers to spend more time thoroughly understanding customer problems and needs, I’m confident that you will enhance overall effectiveness by delivering the right things in the right way.
I’d love to hear your thoughts on this and any other suggestions you might have on improving Product Backlog refinement efforts.
Wenn es um erfolgreiche Produktentwicklung geht, gibt es einen Bereich, der besonders hervorsticht: die Erstellung und Verfeinerung der Einträge, die umgesetzt werden müssen, um echten Mehrwert zu liefern. Im Scrum wird dies als Product Backlog Refinement bezeichnet, und es ist ein echter Gamechanger. Man kann es als den Prozess betrachten, in dem große Ideen in klare, umsetzbare Aufgaben geformt werden, die innerhalb eines Sprints bearbeitet werden können. Laut dem Scrum Guide ist das Refinement „der Vorgang, durch den Product-Backlog-Einträge in kleinere, präzisere Elemente zerlegt und weiter definiert werden“. Dies ist kein einmaliges Ereignis – es ist eine fortlaufende Praxis, die während des Sprints stattfindet. Das Ziel? Sicherzustellen, dass man immer in die richtige Richtung geht. Aber Refinement bedeutet mehr als nur das Zerlegen von Aufgaben. Es geht darum, genug Details hinzuzufügen, damit, wenn die Arbeit abgeschlossen ist, sie auch tatsächlich abgeschlossen ist. Dazu gehört die Festlegung von Akzeptanzkriterien, die Schätzung des Aufwands und manchmal sogar die Priorisierung der nächsten Schritte. Es geht darum, das Team Schritt für Schritt auf Erfolg auszurichten.
Als Agile Coach fällt mir bei den meisten Teams, denen ich beitrete, ein gemeinsames Muster bei den Product Backlog Refinements auf:
Auf den ersten Blick scheint dieser Prozess effizient zu sein. Das Product Backlog wird aktualisiert, und das Team verlässt die Sitzung mit einer Liste von Elementen, die für die nächste Sprint-Planung vorbereit sind. Ich bin jedoch der Meinung, dass dieser Ansatz oft wichtige Chancen für ein wirklich effektives Product Backlog Refinement verpasst. In diesem Artikel teile ich einige Strategien, die Ihre Refinement auf ein höheres Niveau heben und sicherstellen, dass Sie das volle Potenzial dieser wichtigen Aktivität ausschöpfen:
Schauen wir uns jedes dieser Vorschläge im Detail an, um zu sehen, wie sie Ihr Product Backlog Refinement effizienter gestalten können:
Dieser Ansatz ist besonders effektiv, wenn mehrere Teams am selben Produkt arbeiten. Wenn das Refinement informell während des Sprints durchgeführt wird, neigen Teams dazu, sich nur auf Punkte zu konzentrieren, die mit ihrer aktuellen Arbeit zusammenhängen und die sie wahrscheinlich für den nächsten Sprint auswählen werden. Obwohl dies effizient erscheinen mag, schränkt es den Wissensaustausch zwischen den Teams ein und reduziert die Flexibilität, Arbeit bei Bedarf neu zu verteilen. In agilen Organisationen ist Anpassungsfähigkeit entscheidend. Teams sollten sich gegenseitig unterstützen und Aufgaben übernehmen können, die nicht mit ihrer Arbeit im vorherigen Sprint verbunden sind, aber wertvoller oder höher im Product Backlog priorisiert sind.
Damit verschiedene Teams die wertvollsten Elemente auswählen können, ist es wichtig, dass alle Teams mit diesen Elementen vertraut sind. Deshalb empfehlen Frameworks wie LeSS (Large-Scale Scrum), das Product Backlog Refinement als ein teamübergreifendes Ereignis durchzuführen. Es fördert das gemeinsame Lernen und eröffnet Koordinationsmöglichkeiten zwischen den Teams. Eine praktische Möglichkeit, sicherzustellen, dass die Teams ein breites Verständnis der wichtigsten Backlog-Elemente haben, besteht darin, gemischte Gruppen von Entwicklern aus verschiedenen Teams zu bilden, um die Elemente gemeinsam zu verfeinern.
Ein weiterer wichtiger Grund, das Product Backlog Refinement als formales Ereignis anzusetzen, wie es LeSS vorschlägt, besteht darin, nicht sprintbezogene Arbeit in einer zeitlich begrenzten Sitzung zu konsolidieren. Dadurch wird den Entwicklern der restliche Sprint freigehalten, um sich ausschließlich auf sprintbezogene Aufgaben zu konzentrieren. Der Schlüssel hierbei ist, dass die Sitzung strikt zeitlich begrenzt sein sollte – in der Regel nicht mehr als 10 % der Sprint-Dauer, was etwa einem Tag in einem zweiwöchigen Sprint entspricht. Wichtig ist auch, dass das Refinement nur durchgeführt werden muss, wenn es nicht genügend detaillierte Backlog-Elemente gibt, um die nächsten zwei oder drei Sprints abzudecken.
Wie bereits erwähnt, sind die Hauptziele des Product Backlog Refinement zweifach: (1) sicherzustellen, dass genügend verfeinerte Elemente im Backlog vorhanden sind, damit die Teams die Sprint-Planung schnell durchlaufen können, indem sie die wichtigsten Aufgaben aus dem oberen Teil des Backlogs auswählen, ohne dass weitere Klärungen erforderlich sind, und (2) die Verteilung der wichtigsten Arbeiten auf alle Teams, die am Produkt arbeiten, zu gewährleisten. Indem Sie das Product Backlog Refinement als gemeinsames Ereignis für alle Teams organisieren, wie in Tipp 1 hervorgehoben, fördern Sie bereits den Wissensaustausch zwischen den Teams. Da der Product Owner für die Maximierung des Return on Investment des Produkts verantwortlich ist, ist sie die beste Person, um zu bestimmen, welche Elemente für den nächsten Sprint priorisiert werden sollten und ob es notwendig ist, dass alle Teams an einem Thema arbeiten oder parallel an verschiedenen Themen voranschreiten.
Im Allgemeinen empfehle ich, dass der Agile Coach oder Scrum Master mit dem PO zusammenarbeitet, um das Product Backlog Refinement im Voraus vorzubereiten, indem sie den aktuellen Stand des Backlogs überprüfen, die Ergebnisse des letzten Sprint Reviews berücksichtigen (mehr dazu in der nächsten Idee) und zusätzliche Geschäfts- oder Benutzerprobleme und -anforderungen identifizieren, die besprochen werden sollten. Es kann auch von Vorteil sein, einige Produktentwickler in die Vorbereitungsphase einzubeziehen, um technische Aspekte anzusprechen, die der PO möglicherweise übersieht. Die Vorbereitung sollte in einer klaren Agenda mit Themen und Zeitrahmen für die Sitzung resultieren. Ein Agendapunkt könnte das Sammeln und Hinzufügen neuer Themen (wie Probleme oder Anfragen) zur Liste der zu verfeinernden Elemente sein, aber die Verantwortung für die Leitung der Sitzung sollte beim PO bleiben, mit Unterstützung des Scrum Masters oder Agile Coaches.
Agile Produktentwicklung wird häufig mit iterativen und inkrementellen Arbeit gleichgesetzt. Wenn wir jedoch lediglich eine große Anforderung oder ein Projekt einmal in kleinere Teile zerlegen und diese Teile iterativ und inkrementell umsetzen, verpassen wir den wahren Nutzen der agilen Produktentwicklung. In einem solchen Szenario hätten wir genauso gut das traditionelle Wasserfallmodell verwenden können und möglicherweise eine noch größere Effizienz erreicht. Die wahre Stärke von Agilität liegt in der Fähigkeit, mit der Unsicherheit umzugehen, die der komplexen Produktentwicklung innewohnt, bei der sich unser Verständnis dessen, was geliefert werden muss, im Laufe der Zeit entwickeln kann.
Tim Harford verweist in seinem Buch Adapt auf den russischen Ingenieur Peter Palchinsky, der drei unvorhersehbare Dimensionen – lokale, zeitliche und menschliche Faktoren – betonte, die dazu führen können, dass wir missverstehen, was die Kunden wirklich wollen. Indem wir Prinzipien wie Variation (neue Ideen erforschen und testen), Überlebensfähigkeit (in einem Umfang arbeiten, in dem Misserfolge handhabbar sind) und Selektion (Feedback sammeln und daraus lernen) anwenden, können wir kleine Schritte unternehmen, um zu iterieren und festzustellen, ob wir in die richtige Richtung gehen.
Wie ich in einem früheren Artikel erwähnte, ist eine effektive Methode, um zu beurteilen, ob wir das richtige Produkt liefern, das Sprint Review im Scrum. Es ist jedoch entscheidend, einen erheblichen Teil des Sprint Reviews darauf zu verwenden, wichtiges Feedback zu sammeln, das unsere nächsten Schritte informiert. Sofern wir die für das Sprint Review vorgesehene Zeit nicht verlängern, um das gesamte Feedback detailliert zu sortieren, zu filtern und zu bewerten, müssen wir diese wichtige Aufgabe verschieben. Ich bin der Meinung, dass der ideale Zeitpunkt hierfür während des Product Backlog Refinement Events ist, wo wir gezielt über die Arbeit sprechen können, die für zukünftige Sprints geplant ist. Diese Veranstaltung bietet eine wertvolle Gelegenheit für das Team, Kundenfeedback zu bewerten, die Bedürfnisse der Kunden zu verstehen und den Zweck des Produkts zu klären.
Wer könnte besser die echten Probleme und Bedürfnisse erklären, die ein Produkt lösen sollte, als die tatsächlichen Nutzer? Wenn Sie ein internes Tool entwickeln, beispielsweise eine Marketing- oder Vertriebsplattform, sind die Personen, die das Produkt nutzen werden, am besten geeignet, um die funktionalen Anforderungen zu klären und, noch wichtiger, den zugrundeliegenden Zweck dieser Funktionen zu erörtern. Diese Personen in Ihre Product Backlog Refinement (PBR)-Sitzungen einzubeziehen, könnte einer der wirkungsvollsten Schritte sein, um das Verständnis der Entwickler für die tatsächlichen Anforderungen des Produkts zu verbessern.
Bei der Entwicklung eines Massenmarktprodukts ist der direkte Zugang zu Nutzern möglicherweise nicht so einfach. In einigen Fällen gehören Ihre Produktentwickler zur Zielgruppe, was es ermöglicht, ihre Perspektiven auf natürliche Weise einzubringen. Indem Sie während des PBR gemischte Gruppen von Entwicklern aus verschiedenen Teams bilden, können Sie unterschiedliche Endnutzerperspektiven in den Refinement-Prozess einfließen lassen. Wenn jedoch bei Massenmarktprodukten die Entwickler möglicherweise nicht vollständig die wichtigsten Zielgruppen repräsentieren, haben Sie mehrere Alternativen:
Obwohl das Einbeziehen realer Nutzer in PBR wertvolle Rückmeldungen und Feature-Vorschläge liefern kann, können dabei auch widersprüchliche Meinungen aufkommen. In diesen Fällen ist es wichtig, dass der Product Owner (PO) in den Entscheidungsprozess eingebunden bleibt, da sie letztendlich dafür verantwortlich ist, den Return on Investment (ROI) des Produkts zu maximieren.
Darüber hinaus ist es entscheidend, dass die gesamte Diskussion während der PBR-Events in der Sprache des Kunden geführt wird. Wenn Sie bemerken, dass das Gespräch zu technisch wird und Fachjargon verwendet wird, den der Kunde nicht verstehen würde, ist dies ein Warnsignal. Dies könnte darauf hindeuten, dass Sie mit Komponenten-Teams arbeiten, anstatt mit echten End-to-End- oder Feature-Teams, die eigenständig in der Lage sind, tatsächliche Kundenanforderungen zu liefern. In solchen Situationen kann der Wert eines echten Product Backlog Refinements, wie hier beschrieben, beeinträchtigt werden, und eine organisatorische Veränderung könnte notwendig sein, bevor Sie die volle Wirkung der hier vorgestellten Ansätze und Ideen ausschöpfen können.
Wie bereits erwähnt, besteht das Hauptziel des Product Backlog Refinements darin, eine Liste von Arbeitspaketen für das Team oder die Teams zusammenzustellen, die in der nächsten Iteration bearbeitet werden sollen, um maximalen Wert zu liefern oder herauszufinden, was geliefert werden muss, um diesen Wert zu schaffen. Diese Elemente müssen detailliert und klar genug sein, damit die Entwickler, die sie umsetzen, verstehen, was getan werden muss und wie lange es voraussichtlich dauert, die Arbeit im kommenden Sprint abzuschließen. Einige nennen dies "bereit für den nächsten Sprint”. Aus meiner Sicht ist das Erreichen dieser Bereitschaft eine echte Kunst! Es geht darum, das richtige Gleichgewicht zwischen zu viel und zu wenig Diskussion zu finden. Übermäßige Verfeinerung kann zu Verschwendung führen, wenn der Product Owner (PO) entscheidet, dass das Team nicht mehr an diesem Eintrag arbeiten soll (was immer möglich ist). Andererseits kann eine unzureichende Verfeinerung dazu führen, dass Zeit verschwendet wird, weil das Falsche gebaut wird oder die Umsetzung länger dauert als ursprünglich geplant und somit nicht genug Zeit für andere Aufgaben bleibt.
Um echtes Verständnis zu gewährleisten, reicht es nicht aus, nur zu lesen oder zuzuhören – der Schlüssel liegt in einer tiefgehenden Diskussion mit anderen. Eine sehr effektive Technik zum Refinement von Items ist „Specification by Example“ von Gojko Adzic. Hierbei werden klare Beispiele formuliert, wie man weiß, dass das, was man baut, genau das ist, was gebraucht wird. Diese Methode kann mit der Gherkin-Syntax durchgeführt werden, indem man das „Give-When-Then“-Format verwendet, oder durch Tabellen, die den Start- und Endzustand sowie die auszuführende Aktion dokumentieren. Durch die Bildung kleiner, funktionsübergreifender Gruppen von Entwicklern mit unterschiedlichen Fähigkeiten (z. B. Testing, Frontend-, Backend-Entwicklung, Business-Analyse und Design), die gemeinsam Beispiele diskutieren und dokumentieren, wird sichergestellt, dass eine Vielzahl von Perspektiven erfasst wird. Zusätzlich verstärkt dieser Ansatz das Verständnis aller Beteiligten dafür, warum das Item überhaupt implementiert wird.
Ich empfehle, mehrere kleinere Gruppen (jeweils 4–6 Personen) zu bilden, die am Refinement der Einträge arbeiten. Auf diese Weise (1) werden unterschiedliche Fähigkeiten, Standpunkte und Erkenntnisse in die Diskussionen eingebracht, und (2) wird vermieden, dass Gruppen zu groß werden, sodass jeder aktiv teilnehmen kann. Wenn mehrere Teams am selben Produkt arbeiten, ist es noch vorteilhafter, Teammitglieder aus verschiedenen Teams zu mischen (wie in Punkt 2 beschrieben). Dieser teamübergreifende Wissensaustausch ermöglicht es mehreren Teams, die Einträge während der Sprint-Planung selbstbewusst aufzugreifen, da in jedem Team Entwickler sind, die bereits mit ihnen vertraut sind.
In einigen Fällen kann es hilfreich sein, dass verschiedene Gruppen dasselbe Eintrag für einen zeitlich begrenzten Zeitraum von 30 bis 40 Minuten verfeinern, gefolgt von einer Sitzung, in der jede Gruppe ihre Ergebnisse teilt. Dieser Prozess kann unterschiedliche Herangehensweisen aufzeigen, das Lernen fördern und zu einem besseren Verständnis sowohl des zu lösenden Problems als auch der besten Lösungsmethode führen. Das Teilen von Erkenntnissen kann dadurch geschehen, dass ein Vertreter jeder Gruppe dem gesamten Team präsentiert, oder durch Gruppenrotationen, bei denen eine Person an jeder „Station“ bleibt, um die Ergebnisse der Gruppe den anderen zu erklären.
Durch die Schaffung kleiner, diverser Gruppen von Produktentwicklern, die Einträge in zeitlich begrenzten Abschnitten verfeinern und anschließend ihre Erkenntnisse teilen, stellen Sie sicher, dass die Entwickler während des gesamten Refinement-Prozesses voll engagiert bleiben. Dies fördert ein tieferes Verständnis dafür, was entwickelt werden muss und warum, und richtet das Team auf das übergeordnete Ziel aus, die Kundenbedürfnisse zu erfüllen – der wahre Zweck des Refinements.
Dies ist zweifellos ein großes und wichtiges Thema. Wenn Ihr Product Backlog Refinement nicht effektiv durchgeführt wird, verschwenden Sie möglicherweise wertvolle Zeit, anstatt diese zu nutzen, um den Erfolg Ihrer Produktentwicklungsaktivitäten voranzutreiben. Es ist unerlässlich, dass alle am Produktentwicklungsprozess Beteiligten in fortgeschrittenen Techniken geschult werden. Dies geht über das einfache Zerlegen großer Anforderungen in Kleinere hinaus und umfasst das Definieren klarer Akzeptanzkriterien, das richtige Schätzen und Priorisieren von Einträgen, sowie das Beherrschen von Techniken zur Product-Discovery – all dies ist entscheidend für den Erfolg.
Folgende Ressourcen kann ich hierfür sehr empfehlen: Untrapping Product Teams von David Pereira, Inspired von Marty Cagen, Impact Mapping von Gojko Adzic, die Product Backlog und Product Backlog Verfeinerung Leitfäden aus Large-Scale Scrum von Craig Larman & Bas Vodde, und natürlich das bereits erwähnte Specification by Example von Gojko Adzic.
Sie haben vielleicht bemerkt, dass die hier besprochenen Ansätze nicht unbedingt die Arbeitseffizienz während des Refinements priorisieren. Es gibt sicherlich effizientere Wege, wie Entwickler Anforderungen schneller erfassen – z. B. indem diese vom Product Owner (PO) oder einer anderen Person im Detail vorbereitet und erklärt werden. Wenn der PO Zeit damit verbringt, die Benutzerprobleme zu verstehen und klare Anforderungen zu schreiben, könnte es tatsächlich schneller für Entwickler sein, diese ohne längere Diskussionen umzusetzen. Ich glaube jedoch fest daran, dass dies zwar anfänglich Zeit sparen könnte, aber oft später zu einer größeren Zeitverschwendung führt, indem Funktionen implementiert werden, die vom Kunden nicht wirklich benötigt werden, oder die Gelegenheiten verpasst wird, eine bessere Lösung zu liefern.
Indem Sie Produktentwickler dazu ermutigen, mehr Zeit damit zu verbringen, die Probleme und Bedürfnisse der Kunden gründlich zu verstehen, bin ich überzeugt, dass Sie die Gesamteffektivität steigern werden, indem Sie die richtigen Dinge auf die richtige Weise liefern.
Ich freue mich darauf, Ihre Gedanken dazu zu hören und weitere Vorschläge zu erhalten, wie Sie die Product Backlog Verfeinerung verbessern können.
Robert is the CEO of Lean Sherpas and one of 25 certified LeSS Trainers globally and one of the few with hands-on experience in LeSS and LeSS Huge. As a change agent for 15+ years, consulting and coaching, he has worked with over 30 companies, including DAX-listed global brands such as Adidas, BMW, BP, Dr. Oetker, Henkel, Hilti, Hugo Boss, SAP, Volkswagen, and ZF.
From 2015 to 2016 he led a LeSS adoption at a Global Player in the Software Industry, scaling development from 3 to 7 teams and coaching the development and the management team on how to lead a scaled agile organization. In 2018 he contributed to significant improvements in product delivery at one of the biggest LeSS Huge adoptions in the world at BMW AG. Working with over 30 teams, including large groups of over 400 employees, he led them to deliver bi-weekly product increments consisting of hardware and software.
Robert ist der CEO von Lean Sherpas und einer von weltweit 25 zertifizierten LeSS-Trainern und hat praktische Erfahrung sowohl mit LeSS als auch mit LeSS Huge. Als agiler Berater und Coach hat er in den letzten 20 Jahren mit über 30 Unternehmen zusammengearbeitet, darunter DAX-notierte Weltmarken wie Adidas, BMW, BP, Dr. Oetker, Henkel, Hilti, Hugo Boss, SAP, Volkswagen und ZF.
Von 2015 bis 2016 leitete er eine LeSS-Einführung bei einem Global Player in der Softwarebranche, skalierte dabei die Entwicklung von 3 auf 7 Teams und coachte das Entwicklungs- und Managementteam bei der Führung einer skalierten agilen Organisation. Im Jahr 2018 trug er bei einer der weltweit größten LeSS-Huge-Implementierungen bei der BMW AG zu signifikanten Verbesserungen in der Produktentwicklung und -auslieferung bei. In Zusammenarbeit mit über 30 Teams und mehr als 400 Mitarbeitern führte er sie dazu, alle zwei Wochen Produktinkremente, bestehend aus Hardware und Software, zu liefern.
Watch Konstantin Ribel discuss organizational behavior and performance and how LeSS can help manage organizational complexity. The orginal Video is viewable on the TC LeSS YouTube Channel. The original video can be seen on the TC LeSS YouTube Channel.
Sehen Sie, wie Konstantin Ribel über organisatorisches Verhalten und Leistung spricht und wie LeSS helfen kann, die organisatorische Komplexität zu bewältigen. Das Originalvideo ist auf dem TC LeSS YouTube Channel zu sehen.
Konstantin Ribel and Craig Larman discuss how BMW's driverless driving team was built based on LeSS Huge, and the successes and problems encountered along the way.About the conferenceLeSS attempts to define what is just necessary for large-scale development. It avoids adding additional roles
Konstantin Ribel und Craig Larman erörtern, wie das BMW-Team für fahrerloses Fahren auf der Grundlage von LeSS Huge aufgebaut wurde und welche Erfolge und Probleme auf dem Weg dorthin aufgetreten sind.Über die KonferenzLeSS versucht, das für eine groß angelegte Entwicklung gerade noch Notwendige zu definieren. Es vermeidet das Hinzufügen von zusätzlichen Rollen, Artefakten oder Prozessen, da es die Nachteile dieser Zusätze erkennt.Sehen Sie das Original hier -> www.infoq.com