Stefan Wolpers

Erfahren Sie mehr über 15 gängige Sprint Review Anti-Muster, die sich negativ auf die Effektivität eines Scrum Teams auswirken - von PST Stefan Wolpers.

Are we still on track to accomplish the Product Goal? Moreover, how did the previous Sprint contribute to our Scrum team’s mission? Given the Sprint Review’s importance, it is worthwhile to tackle the most common Sprint Review anti-patterns.

Erfahren Sie mehr über 21 gängige Sprint Retrospektive Anti-Patterns aus der Scrum Anti-Patterns-Serie — von PST Stefan Wolpers.

TL; DR: Sprint Retrospective Anti-Patterns What event could better embody Scrum’s principle of empiricism than the Sprint Retrospective? I assume all peers agree that even the simplest form of a Retrospective—if only held regularly—is far more helpful than having a fancy one once in a while, not to mention having none. Moreover, I am convinced there is always room for improvement; just avoid dogmatism. Hence, learn more about 21 common Sprint Retrospective anti-patterns that will hold back your Scrum team. 🇩🇪 Zur deutschsprachigen Version des Artikels: 21 Sprint Retrospektive Anti-Patterns. 🗳 Update: Join the poll and its lively discussion on LinkedIn. 🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 35,000-plus subscribers. 🎓 Join Stefan in one of his upcoming Professional Scrum training classes! The Scrum Guide on the Sprint Retrospective According to the Scrum Guide, the Sprint Retrospective serves the following purpose: The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved. The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint. The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. Source: Scrum Guide 2020. By any standard, this is a compelling pitch of the benefits of Retrospectives, addressing the why, the what, and the how. Suppose a Scrum team takes inventing on behalf of customers and creating valuable, viable, feasible, and usable products seriously. In that case, it should be highly motivated to diligently close this feedback loop at the team level every Sprint. Furthermore, everyone should be looking forward to identifying how to make the next Sprint better and more enjoyable: Are we still progressing towards the team goal? (Regarding the “goal” aspect, the Retrospective resembles the Daily Scrum — inspecting the progress towards the Sprint Goal — and the Sprint Review: inspecting the progress towards the Product Goal.) But unfortunately, many Scrum teams experience something different. Fortunately, though, many of the Retrospective anti-patterns listed below can be addressed by the Scrum team members themselves. Sprint Retrospective Anti-Patterns No matter the frequency of your Retrospectives, you should always watch out for the following Sprint Retrospective anti-patterns from the Scrum team, the Developers, the Scrum Master, as well as the organization: Sprint Retrospective Anti-Patterns of the Scrum Team #NoRetro: There is no Retrospective as the team believes there is nothing to improve, and the Scrum Master accepts this notion. (There is no such thing as an agile Nirwana where everything is perfect. As people say: becoming agile is a journey, not a destination, and there is always something to improve.) Dispensable buffer: The Scrum team cancels Retrospectives if more time is needed to accomplish the Sprint Goal. (The Retrospective as a Sprint emergency reserve is a common sign of cargo cult Scrum. I believe it is even a worse anti-pattern than not having a retrospective because there is presumably nothing to improve. That is just an all-too-human fallacy bordering on hubris. However, randomly canceling a Retrospective to achieve a Sprint Goal clearly shows that the team does not understand basic principles, such as empiricism and continuous improvement. If the Scrum team repeatedly does not meet the Sprint Goal, it should inspect what is happening here. Guess which Scrum event is designed for that purpose?) Rushed Retrospective: The team is in a hurry and allocates much less than the necessary 60 to 180 minutes for a Retrospective. (That is a slippery slope and will probably end up with a ritualized ceremony of little value. Most team members will likely regard it as a waste sooner or later. Do it right by allocating sufficient time or consider not running Retrospectives. And while you are at it, why don’t you abandon Scrum altogether?) Let’s have the retro next Sprint: The Scrum team postpones the Retrospective to the next Sprint. (Beyond the ‘inspect & adapt’ task, the Retrospective shall also serve as a moment of closure that resets everybody’s mind so that the team can focus on the new Sprint. Additionally, the Scrum team shall inspect their way of working and identify opportunities to make the next Sprint more effective and fun. This is why we have the Retrospective before the Sprint Planning of the upcoming Sprint. Moreover, postponing the Retrospective into the next Sprint may interrupt the team’s flow and leave one or more critical team issues unattended for the length of a Sprint. Also, it is a slippery slope. If postponing Retrospectives becomes an acceptable approach, why have them in the first place?) Excluding stakeholders all the time: The Scrum team categorically rejects the idea of having Retrospectives with their stakeholders. (The presence of stakeholders or line managers at team Retrospectives is generally not a good idea. However, excluding these two groups from all kinds of Retrospectives is a short-sighted practice. As a result, the Scrum team will never manage to evolve to its true potential as they deliberately reduce available feedback and thus flatten their learning curve. Several opportunities in Scrum address stakeholders’ communication and information needs: the Sprint Review, listening in at the Daily Scrum, probably even the Product Backlog refinement, not to mention opportunities of having a conversation in Zoom, at water coolers, over coffee, or during lunchtime. If that spectrum of possibilities is not sufficient, consider having additional meetings if your team deems them necessary. For example, there is the opportunity to have a meta-level Retrospective, explicitly including the Scrum team’s stakeholders. However, the Retrospective as a Scrum team-internal event is off-limits to stakeholders.) Someone sings: Someone from the participants provides information on the Retrospective to an outsider. (For Retrospectives, the Vegas rule applies: what is said in the room stays in the room. There is no exception to this rule.) Extensive whining: The Scrum team uses the Retrospective primarily to complain about the situation and assumes the victim’s role. (Change requires reflection, and occasionally it is a suitable exercise to let off steam. However, not moving on once you have identified critical issues and trying to change them defies the purpose of the Retrospective.) UNSMART: The team chooses to tackle UNSMART actions. (Bill Wake created the SMART acronym for reasonable action items: S – Specific, M – Measurable, A – Achievable, R – Relevant, T – Time-boxed. If the team picks UNSMART action items, it sets itself up for failure and may thus contribute to a bias that “agile” is not working. Read More: INVEST in Good Stories, and SMART Tasks.) #NoAccountability: At the last Retrospective, the team members accepted action items. However, no one took responsibility for the delivery. (If the “team” is supposed to fix X, probably everyone will rely on their teammates to handle it. So make someone responsible instead.) What improvement? The team does not check the status of the action items from previous Retrospectives. (The sibling of autonomy is accountability. If you are not following up on what you wanted to improve before, why care about picking action items in the first place?) Sprint Retrospective Anti-Patterns of the Scrum Master Waste of time: The Scrum team does not collectively value the Retrospective. (If some team members consider the Retrospective to be of little or no value, it is most often the Retrospective itself that sucks. Is it the same procedure every time, ritualized and boring? Have a meta-retrospective on the Retrospective itself. Change the venue. Have a beer- or wine-driven Retrospective. There are so many things a Scrum Master can do to make Retrospectives great again and reduce the absence rate. And yes, to my experience, introverts like to take part in Retrospectives, too, if appropriately facilitated.) Prisoners: Some team members only participate because they are forced to join. (Don’t pressure anyone to take part in a Retrospective. Instead, make it worth their time. The drive to continuously improve as a team needs to be fueled by intrinsic motivation, neither by fear nor force. My tip: Retromat’s “Why are you here?” exercise is a good opener for a Retrospective from time to time.) Groundhog day: The Sprint Retrospective never changes in composition, venue, or length. There is a tendency in this case that the Scrum team might revisit the same issues repeatedly–it’s Groundhog Day without the happy ending, though. #NoDocumentation: No one is taking minutes for later use. (A Retrospective is a substantial investment and should be taken seriously. Taking notes and photos supports this process.) No psychological safety: The Retrospective is an endless cycle of blame and finger-pointing. (The team wins together; the team fails together. The blame game documents both the failure of the Scrum Master as the facilitator of the Retrospective and the Scrum team’s lack of maturity and communication skills.) Bullying is accepted: One or two team members dominate the Retrospective. (This communication behavior is often a sign of either a weak or uninterested Scrum Master. The Retrospective needs to be a safe place where everyone–introverts included–can address issues and provide their feedback free from third-party influence. If some of the team members dominate the conversation and probably even bully or intimidate other teammates, the Retrospective will fail to provide such a safe place. This failure will result in participants dropping out of the Retrospective and render the results less valuable. It is the primary responsibility of the Scrum Master as a facilitator to ensure that everyone will be heard and has an opportunity to voice their thoughts. By the way, equally distributed speaking time is according to Google also a sign of a high-performing team. Read More: What Google Learned From Its Quest to Build the Perfect Team. Passivity: The Scrum team members are present but are not participating. (There are plenty of reasons for such a behavior: they regard the Retrospective as a waste of time, it is an unsafe place, or the participants are bored to death by its predictiveness or likely lack of progress. Probably, the team members are afraid of negative repercussions in the case of their absence and hence decided to show up. Unfortunately, in this case, there is no quick fix, and the Scrum Master needs to figure out what kind of Retrospective works in their team’s context. Take it to the team.) Sprint Retrospective Anti-Patterns of the Organization No suitable venue: There is no good place available to run the Retrospective. (Let’s assume that we won’t spend the rest of our professional lives in virtual team settings for a moment. Then the least appropriate place to have a Retrospective is a meeting room with a rectangular table surrounded by chairs. And yet it is the most common venue to have a Retrospective. Becoming agile requires space. If this space is not available, you should become creative and go somewhere else. If the weather is fine, grab your stickies and go outside. Or rent a suitable space somewhere else. If that is not working, for example, due to budget issues, remove at least the table so you can sit/stand in a circle. Just be creative. Read More: Agile Workspace: The Undervalued Success Factor.) Line managers present: Line managers regularly participate in Retrospectives. (This is among the worst Sprint Retrospective anti-patterns I can imagine. It turns the Retrospective into an unsafe place. And who would expect that an unsafe place would trigger an open discussion among the team members? Any line manager who insists on such a proceeding signals their lack of understanding of basic Scrum practices. Reporting structures within Scrum teams: There are hierarchies among Scrum team members. For example, a junior Developer reports to a senior Developer on the same Scream team. (This situation requires the immediate attention of the Scrum Master as it — at least in my experience — instantly turns the Retrospective into an awkward and significantly less helpful event.) Let us see your minutes: Someone from the organization — outside the Scrum team — requires access to the Retrospective minutes. (This is almost as bad as line managers who want to participate in a Retrospective. But, of course, this information is solely available to team members. Conclusion There are many ways in which a Sprint Retrospective can be a failure, even if it looks suitable at first glance. From my perspective, the top three Sprint Retrospective anti-patterns are: not making the Retrospective a safe place, forcing team members to participate in an exercise they consider a waste of their time, and not taking the Retrospective seriously in the first place. Are any Sprint Retrospective anti-patterns missing? Please share it with us in the comments. 📖 Related Posts Liberating Structures for Scrum (1): The Sprint Retrospective Scrum Master Anti-Patterns — 20 Signs Your Scrum Master Needs Help 27 Product Backlog and Refinement Anti-Patterns Scrum: 20 Sprint Planning Anti-Patterns 27 Sprint Anti-Patterns Holding Back Scrum Teams Daily Scrum Anti-Patterns: 24+2 Ways to Improve as a Scrum Team Download the Scrum Anti-Patterns Guide for free. 📺 The Replay of the Webinar Sprint Retrospective Anti-Patterns The video of the webinar is available on Age-of-Product’s Youtube channel: {"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/HJdOIUd7xN8.jpg?itok=Yq_h-ezC","video_url":"https://youtu.be/HJdOIUd7xN8","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} Note: If the browser will not start the video automatically, click here to watch the replay of the webinar Sprint Retrospective anti-patterns directly on Youtube. ✋ Do Not Miss Out and Learn more about Sprint Retrospective Anti-Patterns — Join the 11,000-plus Strong ‘Hands-on Agile’ Slack Community I invite you to join the “Hands-on Agile” Slack Community and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world. If you like to join all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free. 21 Sprint Retrospective Anti-Patterns Impeding Scrum Teams was first published on Age-of-Product.com.

In Kürze: Die Product Owner Zertifizierungen PSPO I, PSPO II und PSPO III bestehen Im ersten Artikel dieser Miniserie wurde festgestellt, dass man kein Zertifikat braucht, um gut in dem zu werden, was man tut, zum Beispiel als Product Owner zu arbeiten. Wenn Sie von der Signalwirkung profitieren wollen, die Scrum-Zertifikate zu haben scheinen, stellt sich die Frage, wie Sie eine Product Owner Zertifizierung von Scrum.org bestehen können. Lesen Sie weiter und erfahren Sie über die beste Vorbereitung für die PSPO I, PSPO II und PSPO III Product Owner Zertifizierungen von Scrum.org. 🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter "Food for Agile Thought" anmelden und sich über 35.000 Abonnenten anschließen. 🎓 Nehmen Sie an einer von Stefans kommenden Professional Scrum-Schulungen teil! Wie man Scrum.orgs PSPO I, PSPO II und PSPO III Product Owner Zertifikate besteht Aufgrund meines beruflichen Hintergrunds als PST bei Scrum.org verbringe ich viel Zeit damit, meine Kursteilnehmer darauf vorzubereiten, wie sie die Product Owner Zertifizierungen bestehen können, die Scrum.org anbietet. Generell gibt es drei verschiedene Product-Owner-Zertifikate von Scrum.org, unabhängig davon, ob der Kandidat einen Professional Product Owner-Kurs besucht hat oder nicht: PSPO I, PSPO II und PSPO III. Während das PSPO I-Zertifikat ein Scrum-Einstiegszertifikat ist, das sich stark auf die Theorie des Scrum Guide konzentriert, richtet sich das PSPO II-Zertifikat an fortgeschrittene Praktiker, die wissen wollen, wie sie mit verschiedenen Szenarien umgehen. Beide Product-Owner-Zertifikate basieren vollständig auf Multiple-Choice-Tests. Das gilt für das PSPO III-Zertifikat nur teilweise. Viele Fragen des PSPO III erfordern eine eigenhändige schriftliche Antwort auf Englisch. Zudem wird die PSM III-Prüfung hauptsächlich von einem Experten manuell benotet. Die PSPO I Product Owner Zertifizierung von Scrum.org bestehen Das PSPO I Product Owner-Zertifikat erfordert solide Kenntnisse der Theorie der agilen Produktentwicklung im Allgemeinen und des Scrum-Frameworks im Besonderen. Ich würde das zwar nicht empfehlen, aber Sie können dieses Product-Owner-Zertifikat auch mit geringen praktischen Scrum-Kenntnisse bestehen, wenn Sie bereit sind, die Zeit zu investieren, um sich mit den Grundlagen vertraut zu machen: Ich empfehle dringend, den Scrum Guide im Voraus mehrmals zu lesen. Die Antworten auf viele Fragen werden dort zu finden sein. Üben Sie fleißig mit den Open Assessments von Scrum.org; Sie müssen das mentale Modell verstehen, das hinter der Erstellung der Frage steht und welche Art von Antworten die Kandidaten geben sollten. Bitte denken Sie daran: Beim Bestehen der Product-Owner-Zertifikate von Scrum.org geht es um die Anwendung von Scrum, so wie es sein soll. (Es geht definitiv nicht um einen der verkorksten Abkömmlinge von Scrum, denen Sie vielleicht schon irgendwo begegnet sind.) Wenn ich die Open Assessments von Scrum.org erwähne, meine ich damit nicht nur das Product-Owner-Open-Assessment. Sie sollten sich auch mit dem Scrum Open und dem Nexus Open Assessment vertraut machen. Ich würde Ihnen sogar empfehlen, sich das Agile Leadership Open und das Evidence-Based Management Open Assessment anzusehen. Um die Product Owner Zertifizierungen zu bestehen, ist es wichtig, dass Sie die Open Assessments routinemäßig mit 100 % in deutlich weniger Zeit als angegeben bestehen. Streben Sie zum Beispiel fünf Minuten Bearbeitungszeit für das Scrum-Open-Assessment an. Bitte beachten Sie auch, dass die eigentlichen PSPO I bis PSPO III Zertifizierungen schwierigere Fragen enthalten werden. Lesen Sie auch die Erklärungen, die Sie in den Open Assessment Tests erhalten, wenn Sie eine Frage falsch beantworten. Aber auch hier geht es in erster Linie darum, das mentale Modell hinter den Fragen zu verstehen. (Manche Studenten beantworten absichtlich alle Fragen falsch, um die richtigen Antworten auf eine Frage zu erfahren.) Sie werden 80 Fragen in 60 Minuten beantworten müssen. Auch wenn es sich bei der PSPO I-Prüfung um eine offene Prüfung handelt, werden Sie wenig bis gar keine Zeit haben, um eine Aufgabe zu googeln. Verwenden Sie nicht zu viel Zeit auf die Beantwortung einer einzigen Frage. Versuchen Sie zunächst, alle 80 Fragen in etwa 45 Minuten zu beantworten und markieren Sie die Fragen, die Sie noch einmal durchgehen möchten. Testen Sie die Lesezeichenfunktion der Open Assessments. Deren Software ist identisch mit derjenigen, die in den PSPO I, PSPO II und PSPO III Zertifizierungstests verwendet wird. (Sie sollten sich in der "echten" PSPO-Zertifizierung nicht unnötig stressen lassen.) Lesen Sie die Fragen sorgfältig durch. Es gibt keine Trickfragen; allerdings ändert sich die Natur einer Frage komplett, wenn Sie z. B. das "Product Backlog" gegen das "Sprint Backlog" austauschen. (Fallen Sie nicht der Neigung zum Mustervergleich zum Opfer, weil Sie glauben, Frage und Antwort bereits aus den Open Assessments zu kennen.) Machen Sie sich außerdem mit dem "Standard of Conduct for Assessments" vertraut. Fühlen Sie sich gut vorbereitet, um eine Product-Owner-Zertifizierung zu bestehen? Ausgezeichnet! Wählen Sie jetzt eine ruhige Stunde, in der Sie nicht gestört werden. Legen Sie vielleicht ein Blatt Papier und einen Stift bereit und überprüfen Sie Ihr Handy, um bei Bedarf eine Alternative zu Ihrem normalen Internetanbieter zu finden. (Ich hatte einmal während einer PSM II-Prüfung einen WLAN-Router, der abgestürzte, und der Wechsel zum mobilen Hotspot hat problemlos funktioniert. Ich mag Backup-Lösungen.) 📈 Die PSPO-I-Zertifizierungsresultate meiner Studenten aus dem Jahr 2021 sehen wie folgt aus: 95% der Kursteilnehmer nahmen an der enthaltenen PSPO-I-Zertifizierung teil. 77% der Prüfungsteilnehmer bestanden die PSPO-I-Zertifizierung mit durchschnittlich 91% der Punktzahl. (Erforderlich: 85%.) Die PSPO II Product Owner Zertifizierung von Scrum.org bestehen Im Vergleich zum PSPO I Product-Owner-Zertifikat bietet die PSPO II-Prüfung relativ mehr Zeit für die Beantwortung: 60 Minuten für 40 Fragen. Das Schwierige ist, dass sich alle Fragen auf reale Szenarien beziehen und viele der vorgeschlagenen Antworten Ihnen bekannt vorkommen werden. Aber leider ist das, was Ihnen bekannt vorkommt, aus der Sicht von Scrum nicht unbedingt akzeptabel: Um sich auf das Bestehen dieser Product-Owner-Zertifizierung vorzubereiten, gehen Sie zurück zu den Vorschlägen für das Bestehen des PSPO I-Assessment; diese gelten auch hier. Fahren Sie dann mit Ihrer Vorbereitung fort, indem Sie den Scrum Guide 2020 Reordered studieren. Ich habe den Scrum Guide 2020 Reordered auf etwa 95 Prozent des Textes des Scrum Guide 2020 aufgebaut und dessen ursprüngliche Struktur um zusätzliche Kategorien erweitert, z. B. zu den Themen Selbstmanagement, Verpflichtungen oder Verantwortlichkeit. Der Guide ermöglicht Ihnen, schnell ein erstes Verständnis für Scrum-bezogene Fragen zu bekommen. Er ist zum Beispiel gut geeignet, um bestimmte Themen—z. B. "Stakeholder"—mit den ersten Prinzipien von Scrum, wie den Scrum-Werten oder der Empirie, in Verbindung zu bringen. Diese Art der Scrum-Mustererkennung hilft dabei, Szenarien aus den Antworten herauszufiltern, die nicht mit den Grundideen von Scrum übereinstimmen. Eine weitere empfehlenswerte Lektüre ist der Scrum Anti-Patterns Guide, siehe oben. Dabei handelt es sich um eine Sammlung von Artikeln, die ich über Jahre hinweg geschrieben und verbessert habe. Darin werden die notwendigen Schritte zur Identifizierung und Überwindung von Scrum-Anti-Mustern beschrieben, von Scrum-Events über Scrum-Artefakte bis hin zu Scrum-Rollen. Planen Sie außerdem genügend Vorbereitungszeit ein, um sich mit Themen vertraut zu machen, die der Product Owner beherrschen muss und die gleichzeitig jedoch nicht angemessen im Scrum Guide dokumentiert sind. Diese Themen umfassen zum Beispiel: Wie kommen die Product Owner von der Produktvision zur Produktstrategie und zum Produktziel? Wie erstellen Product Owner ein System, mit dessen Hilfe sie herausfinden können, was aus Sicht des Kunden entwicklungswürdig ist? Und wie beziehen Product Owner die Stakeholder und die Mitglieder des Scrum-Teams in diesen Prozess ein? Wie erreichen Product Owner eine Abstimmung zwischen den Teammitgliedern bei der Verwaltung und Verfeinerung des Produktbacklogs? Wie gehen Product Owner mit der Reihenfolge im Product Backlog um? Welche Frameworks unterstützen Product Owner dabei, sicherzustellen, dass das Scrum-Team immer an den wertvollsten Aufgaben arbeitet? Wie gehen Product Owner mit Schätzungen, Prognosen und der Release-Planung um? Wie gehen Produktverantwortliche mit den Erwartungen der Stakeholder um? Schließlich sollten Sie den Product Owner Learning Path von Scrum.org in Betracht ziehen. Der Product Owner Learning Path ist zwar keine Voraussetzung für das Bestehen der PSPO II Product-Owner-Zertifizierung, bietet aber einen strukturierten Lernansatz für Product Owner im Allgemeinen. 📈 Die PSM-II-Zertifizierungsresultate meiner Studenten aus dem Jahr 2022 sehen wie folgt aus: 100% der Kursteilnehmer nahmen an der enthaltenen PSPO-II-Zertifizierung teil 71% der Prüfungsteilnehmer bestanden die PSM-II-Zertifizierung mit durchschnittlich 90% der Punktzahl. (Erforderlich: 85%.) Die PSPO III Product Owner Zertifizierung von Scrum.org bestehen Das Bestehen der PSPO III Product-Owner-Zertifizierung ist knifflig und erfordert voraussichtlich eine monatelange Vorbereitung. (Ich selbst habe mehr als zwei Monate mit der Vorbereitung verbracht.) Viele Kandidaten stehen vor zwei großen Herausforderungen: Erstens müssen Sie in der Lage sein, schnell zu tippen, und zweitens müssen Sie dies auf Englisch tun. Und gleichzeitig müssen Sie präzise und knappe Antworten geben. Während Sie für die PSPO I- und PSPO II-Tests die Verwendung eines Übersetzungs-Plug-ins in Erwägung ziehen können, ist dies für den PSM III nur bedingt hilfreich. Es ist auch nicht möglich, die Antworten in Ihrer Muttersprache zu verfassen und sie dann zu übersetzen, da es unmöglich ist, den Text in die Antwortfelder einzufügen. Sie müssen den Text also manuell eingeben: Um sich auf das Bestehen dieser Product-Owner-Zertifizierung vorzubereiten, gehen Sie zunächst zurück zu den Vorschlägen für die PSPO I und PSPO II Tests; diese gelten auch hier. Üben Sie schnelles Tippen. Bei meiner PSPO III-Prüfung hatte knapp zehn Fragen, die schriftlich beantwortet werden mussten, und etwa 25 Multiple-Choice-Fragen. Ich musste alle diese Fragen innerhalb von 120 Minuten beantworten. Also habe ich mir einen Countdown von drei Minuten pro Frage gesetzt und mich gezwungen, am Ende dieser Zeitspanne zur nächsten Frage überzugehen. (Sie verlieren mehr Punkte, wenn Sie eine Frage am Ende der Prüfung nicht beantworten, weil Ihnen die Zeit ausgeht, als wenn Sie eine 90 %-ige Antwort in eine 95 %-ige Antwort verbessern, indem Sie zwei Minuten zu dem Intervall hinzufügen.) Erstellen Sie selbst Fragen, z. B. auf der Grundlage des Scrum Guide, und versuchen Sie, diese innerhalb der 3-4 Minuten Timebox zu beantworten. (Der Scrum Anti-Patterns Guide und der Scrum Guide Reordered unterstützen Sie dabei. Ich habe den ersten Scrum Guide Reordered extra als Hilfsmittel für meinen Versuch, die PSM III-Prüfung zu bestehen, erstellt.) Studieren Sie den "Standard of Conduct for Assessments" erneut, insbesondere den Absatz "Additional expectations for essay-based assessments—PSM III and PSPO III". Beginnen Sie mit der Lektüre vieler Bücher über Scrum, das Meistern der Product-Ownerschaft und Produktmanagement im Allgemeinen. (Marty Cagans "Inspired", Melissa Perris "Escaping the Build Trap" und Teresa Torres "Continuous Product Discovery" kommen mir u. a. in den Sinn.) Verfolgen Sie Ihre Vorbereitungsfortschritte, indem Sie den Product Owner Learning Path nutzen, siehe oben. Treten Sie dem Forum von Scrum.org oder der Hands-on Agile Slack-Community bei—siehe das Formular unten—und beteiligen Sie sich an Diskussionen mit anderen Product Ownern über Themen, die für Sie unklar sind. (Es gibt einige Leute in der Hands-on Agile Slack Community, die die PSPO III-Prüfung in Betracht ziehen bzw. sich auf diese vorbereiten.) Es gibt einen Grund, warum es heute weltweit nur 408 Zertifikatsinhaber gibt: Die PSPO III Prüfung ist eine schwierige und kostspielige Product-Owner-Zertifizierung. Sie müssen sich gut vorbereiten. Einfach nur hinzugehen und auf das Beste zu hoffen, ist ein aussichtsloser Ansatz. (Übrigens: Wenn Sie einen Fortgeschrittenen-Product-Owner-Kurs besuchen, reduziert sich der Preis von $500 für das PSPO III Zertifikat um $200.) Schlussfolgerung: Die Scrum.org PSPO I, PSPO II und PSPO III Zertifizierungen Wenn das Bestehen eines Product Owner Zertifikats eine gute Karriereentscheidung und Signal für potenzielle Arbeitgeber, Kunden oder Kollegen ist, welches PSPO-Zertifikat sollten Sie dann in Betracht ziehen? Ich persönlich würde in den meisten Fällen ein PSPO I Zertifikat als das Minimum und ein PSPO II Zertifikat als den Standard betrachten. Auf der anderen Seite hat jemand, der einen PSPO III besitzt, meine volle Aufmerksamkeit, denn sie haben eine beachtliche Leistung vollbracht. Natürlich gibt es Ausnahmen von der Regel, die diese bestätigen. Einige hervorragende agile Praktiker glauben zum Beispiel nicht an irgendeine Form von Scrum-Zertifikaten, und es funktioniert für sie gut. Allerdings leisten sie auch eine Menge Arbeit für die agile Gemeinschaft und haben eine entsprechende Sichtbarkeit. Fragen Sie sich einfach selbst: Gehören Sie zu dieser Gruppe? 📖 Lesenswert zu den Product Owner Zertifizierungen PSPO I, PSPO II und PSPO III von Scrum.org Die folgenden Informationsquellen können Sie bei Ihren Bemühungen unterstützen, Product Owner Zertifizierungen zu bestehen: Scrum Zertifizierung — eine sinnvolle Investition für Ihre Karriere? Product Owner Fehlverhalten — 33 Möglichkeiten, sich als PO zu verbessern Hiring: 82 Scrum Product Owner Interview Questions to Avoid Agile Imposters Scrum Master Zertifizierungen bestehen: PSM I, PSM II und PSM III von Scrum.org Hiring: 60 Scrum Master Interview Questions To Avoid Agile Imposters Download the ’Scrum Anti-Patterns Guide’ for Free The Scrum Guide Reordered — understand the Scrum Guide’s patterns and concepts quickly ✋ Nicht versäumen: Lernen Sie mehr über Scrum Master Zertifizierungen in der 11.000-köpfigen "Hands-on Agile" Slack-Community Ich lade Sie ein, sich dem "Hands-on Agile" Slack-Team anzuschließen und die Vorteile einer schnell wachsenden, lebendigen Gemeinschaft von agilen Praktikern aus der ganzen Welt zu genießen. Wenn Sie jetzt beitreten möchten, müssen Sie nur noch Ihre Anmeldeinformationen über dieses Google-Formular angeben, und ich werde Sie anmelden. Die Mitgliedschaft ist kostenlos. Der Artikel Wie man Scrum.orgs PSPO I, PSPO II und PSPO III Product Owner Zertifikate besteht erschient zuerst auf Berlin-Product-People.com.

TL; DR: How to Pass the Product Owner Certification — Scrum.org’s PSPO I to III The first article of this mini-series established that you do not need a certificate to become good at what you do, for example, working as a Scrum Master or Product Owner. However, getting certified may be a piece of sound investment advice. If you want to take advantage of the signaling power that Scrum certificates seem to have, the question is how to pass the Product Owner certification? 🇩🇪 Zur deutschsprachigen Version des Artikels: Product Owner Zertifizierungen bestehen: PSPO I, PSPO II und PSPO III von Scrum.org. 🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 35,000-plus subscribers. 🎓 Join Stefan in one of his upcoming Professional Scrum training classes! How to Pass Scrum.org’s PSPO I Product Owner Certification The PSPO I Product Owner certificate requires a solid knowledge of the theory of agile product development in general and the Scrum framework in particular. While I would not suggest it, you can pass this Product Owner certificate little practical knowledge of Scrum if you are willing the put in the time to get familiar with the fundamentals. To pass the PSPO I Product Owner assessment, I recommend the following preparation: Read the Scrum Guide in advance several times. The answers to many questions will be in there. Diligently practice with Scrum.org’s Open Assessments; you will need to understand the mental model behind creating the assessment question and what kind of answers candidates shall provide. Please keep in mind: Passing Product Owner certificates by Scrum.org is about the pure application of Scrum as it is supposed to be. (Not one of the botched derivates of Scrum you may have encountered somewhere.) When I mention Scrum.org’s Open Assessments, I am not only referring to the Product Owner Open. You also need to get familiar with the Scrum Open and the Nexus Open. I would even suggest looking at the Agile Leadership Open and the Evidence-Based Management Open. To pass the Product Owner certification, it is essential that you pass the Open Assessments routinely with 100 % in significantly less time than advertised. For example, aim for 5 minutes for the Product Owner Open and the Scrum Open. Also, please note that the actual PSPO I to PSPO III assessments will likely comprise more difficult questions. Also, read the explanation the Open Assessment tests provide to you when you answer a question incorrectly. But, again, it is about understanding the mental model behind the questions in the first place. (Some students deliberately answer all questions wrong to learn the correct answers.) You will have to answer 80 questions in 60 minutes. While the PSPO I assessment is an open book assessment, there will be little to no time to start googling anything. Do not spend too much time on answering a single question. First, aim to answer all 80 questions in about 45 minutes while booking marking those you want to revisit. Test the bookmarking function of the Open Assessments. Its software is identical to the one used in the PSPO I, PSPO II, and PSPO III certification tests. (You do not want to be stressed during the “real” PSPO certification.) Read the questions carefully. There are no trick questions; however, swapping ‘Product Backlog’ for ‘Sprint Backlog’ changes the game. (Don’t fall victim to pattern matching instead of reading.) Make yourself familiar with the Standard of Conduct for Assessments. Do you feel well prepared to pass a Product Owner certification? Excellent! Now, pick a quiet hour where you will not be disturbed. Maybe, ready a sheet of paper and a pencil and check your mobile to provide an alternative to your normal ISP if needed. (I once encountered a crashing WiFi router during an PSM II assessment, and switching to the mobile hotspot worked well. I like backup solutions.) 📈 The PSPO I Certification Results from my Professional Product Owner classes in 2021 are as follows: 95% of course participants took the included PSPO I certification. 77% of exam takers passed PSPO I certification with an average score of 91%. (Required: 85%.) How to Pass Scrum.org’s PSPO II Product Owner Certification Compared to the PSPO I Product Owner certificate, the PSPO II assessment provides 60 minutes to answer 40 questions. The challenge is that all questions address real-life scenarios, and many suggested choices will sound familiar to you. But, unfortunately, sounding familiar to you won’t necessarily make them acceptable from Scrum’s perspective: To prepare yourself for passing this Product Owner certification, go back to the suggestions for the PSPO I assessment; those apply here, too. Then continue your preparation by studying the Scrum Guide 2020 Reordered. I based the Scrum Guide 2020 Reordered on about 95 percent of the text of the Scrum Guide 2020, extending its original structure by adding additional categories, for example, on self-management, commitments, or accountability. It allows you to get a first understanding of Scrum-related questions quickly. For example, it is good at relating specific topics—say “stakeholders”—with Scrum’s first principles, such as Scrum Values or empiricism. This kind of Scrum pattern recognition helps to sort out scenarios that are not compliant with Scrum’s basic ideas. Another recommended reading is the Scrum Anti-Patterns Guide. It is a collection of articles I have been writing and refining for years. They detail the necessary steps to identify and overcome Scrum anti-patterns, from Scrum events to Scrum artifacts to Scrum roles. Additionally, allocate sufficient preparation to become familiar with topics that the Product Owner needs to master that, at the same time, are not appropriately documented in the Scrum Guide. For example, these topics comprise: How do Product Owners get from the product vision to product strategy and to the Product Goal? How do Product Owners create a system to identify what is worth building from a customer perspective? Moreover, how do Product Owners include stakeholders and Scrum team members in this process? How do Product Owners create alignment among team members regarding Product Backlog management and refinement? How do Product Owners deal with ordering the Product Backlog? What frameworks support Product Owners in ensuring that the Scrum Team is working on the most valuable work items? How do Product Owners deal with estimation, forecasting, and release planning? How do Product Owners manage stakeholder expectations? Finally, you may want to consider Scrum.org’s Product Owner Learning Path. While it is not a pre-requisite for passing the PSPO II certification, the Product Owner Learning Path offers a structured approach to learning for Product Owners. 📈 The PSPO II Certification Results from my Advanced Professional Product Owner classes in 2022 are as follows: 100% of course participants took the included PSPO II certification. 71% of exam takers passed PSPO II certification with an average score of 90%. (Required: 85%.) How to Pass Scrum.org’s PSPO III Product Owner Certification Passing the PSPO III Product Owner certification is tricky and requires probably a months-long preparation. (I spent more than two months preparing myself.) Many candidates face two significant challenges: Firstly, you need to be able to type fast, and secondly, you need to do this in English. And at the same time, you need to provide precise and concise answers. While you may consider using a translation plug-in for the PSPO I and PSPO II, this won’t help much with the PSPO III. Also, writing answers in your native language and then translating them won’t work, as pasting any text into the answer boxes is impossible. So instead, you will have to type manually: To prepare yourself for passing this Product Owner certification, go back to the suggestions for the PSPO I and PSPO II assessments; those apply here, too. Practice typing fast. During my PSPO III assessment, I had less than ten questions that required a written answer and about 25 multiple-choice questions. I had to answer all of those questions within 120 minutes. So, I set a count-down of three minutes per question, and I forced myself to move on to the next question at the end of that period. (You will lose more points by not answering a question at the end of the assessment because you run out of time than moving a 90 % answer to a 95 % answer by adding two minutes to the original interval.) Create questions yourself, for example, based on the Scrum Guide, and try answering them with the time-box. (The Scrum Anti-Patterns Guide and the Scrum Guide Reordered support this effort; I created the first Scrum Guide Reordered as a tool to support my attempt to pass the PSM III assessment.) Revisit the Standard of Conduct for Assessments, particularly the “Additional expectations for essay-based assessments - PSM III and PSPO III” paragraph. Start reading many books on Scrum, Product Owner mastery, and product management in general. (Marty Cagan’s “Inspired,” Melissa Perri’s “Escaping the Build Trap,” and Teresa Torres’ “Continuous Product Discovery” come to mind.) Track your preparation progress by engaging with the Product Owner Learning Path, see above. Join Scrum.org’s forum or the Hands-on Agile Slack community—see the sign-up form below—and engage in discussions with fellow Product Owners on topics unclear to you. (I know some people in the Hands-on Agile Slack community who are considering taking the PSPO III or preparing for it.) There is a reason why there are only 408 certificate holders worldwide as of today: The PSPO III assessment is a difficult and expensive Product Owner certification. You need to prepare yourself properly. Just showing up and hoping for the best is a futile approach. (By the way, attending an Advanced Product Owner class will reduce the $500 price tag of the PSPO III by $200.) Conclusion: How to Pass the Product Owner Certification by Scrum.org If passing a Product Owner certificate is a good career choice and sound signaling for prospective employers, customers, or peers, which PSPO certificate shall you consider? Personally, in most cases, I would consider a PSPO I to be the minimum and a PSPO II to be the standard. However, on the other side, someone holding a PSPO III certainly has my full attention as they accomplished quite a feat. Of course, there are exceptions to the rule that proves it. For example, some excellent agile practitioners do not believe in any form of Scrum certificates, and it works fine for them. However, they also put in a lot of work for the agile community and have corresponding visibility. Just ask yourself: Do you belong to this group? 📖 Scrum Certification Resources Scrum Certification: Is It a Sound Investment for Your Career? Product Owner Anti-Patterns — 33 Ways to Improve as a PO Hiring: 82 Scrum Product Owner Interview Questions to Avoid Agile Imposters How to Pass the Scrum Master Certification — PSM I, PSM II, and PSM III Hiring: 60 Scrum Master Interview Questions To Avoid Agile Imposters Download the ’Scrum Anti-Patterns Guide’ for Free The Scrum Guide Reordered — understand the Scrum Guide’s patterns and concepts quickly ✋ Do Not Miss Out and Learn more about how to Pass the Product Owner Certification — Join the 11,000-plus Strong ‘Hands-on Agile’ Slack Community I invite you to join the “Hands-on Agile” Slack Community and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world. If you like to join all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free. The article How to Pass the Product Owner Certification — PSPO I, PSPO II, and PSPO III was first published on Age-of-Product.com.

Keine andere Rolle in Scrum kann so sehr zu mittelmäßigen Ergebnissen beitragen wie der Product Owner — Garbage in, Garbage out. Die folgende Liste mit den häufigsten Product Owner Fehlverhalten könnte daher ein Ausgangspunkt sein, über die Tätigkeit als Product Owner nachzudenken; vielleicht gibt es Verbesserungspotential?

TL; DR: Scrum Master Anti-Patterns No other role in Scrum can contribute to mediocre outcomes like the Product Owner—garbage in, garbage out. Therefore, the following list of some of the most common Product Owner anti-patterns might be a starting point to reflect on the role; maybe, there is room for improvement? If you recognize some anti-patterns in your daily work, why don’t you ask the rest of the Scrum Team for support? For example, run a Retrospective with teammates and stakeholders on how the team is doing regarding figuring out what is worth building. 🇩🇪 Zur deutschsprachigen Version des Artikels: Product Owner Fehlverhalten — 33 Möglichkeiten, sich als PO zu verbessern. 🗳 Update: Join the poll and its lively discussion on LinkedIn. 🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 35,000-plus subscribers. 🎓 Join Stefan in one of his upcoming Professional Scrum training classes! 📅 Join 230-plus peers on May 30, 2022: HoA #42: The Skinny on Lean Roadmapping and OKRs w/ Janna Bastow. The Role of the Product Owner According to the Scrum Guide The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. The primary way to achieve this goal as a PO is to manage the Product Backlog effectively. According to the Scrum Guide, this activity comprises: Developing and explicitly communicating the Product Goal; Creating and clearly communicating Product Backlog items; Ordering Product Backlog items; and, Ensuring that the Product Backlog is transparent, visible and understood. The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable. For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review. Source: Scrum Guide 2020. In my experience, most Product Owner anti-patterns result from a misunderstanding of this Product Backlog management task. Notably, less successful Product Owners tend to fail at the communication part with teammates and stakeholders. Maximizing the value of the Scrum team's work from a customer perspective while contributing to the bottom-line of the organization is less a question of project management skills, juggling with product requirement documents, and keeping the Jira up-to-date. Therefore, successful Product Owners spend less time on actually handling the Product Backlog than they allocate to product discovery in general and creating alignment among all players in particular. To them, the Product Backlog is a means to an end, not the purpose of their existence. Consequently, successful Product Owners spend time creating a transparent system that allows identifying potentially valuable ideas from all sources, relentlessly communicating the “Why,” and collaborating with the Developers on the “What.” Product Backlog and Refinement Anti-Patterns You can spot many of the Product Owner anti-patterns in the PO’s backyard — the Product Backlog and its refinement: Storage for ideas: The Product Owner uses the Product Backlog as a repository of ideas and requirements. (A large Product Backlog is probably considered a sign of a “good” Scrum team: You are fully transparent, and this is proof of your usefulness to the organization. However, being “busy” does not equal value to customers and the organization. The additional noise created by the sheer number of issues may also cloud the detection of valuable items. Lastly, the Product Backlog size may have a crowding-out effect on stakeholders as they feel overwhelmed. The idea-inflated Product Backlog may impede critical communication with them as a consequence.) Part-time PO: The Product Owner is not working daily on the product backlog. (The Product Backlog needs to represent the best use of the Developers’ time at any given time. Suppose an update to the Product Backlog happens only occasionally, for example, shortly before the next Sprint Planning. Due to a lack of refinement, it is likely to leave a lot of value on the table. The value of the Product Backlog results in a significant part from the open discussion between the Product Owner and the Developers. In a good Scrum team, the Developers constantly challenge the Product Owner regarding the value of suggested Product Backlog items. This checks & balances approach reduces the probability of the Product Owner falling victim to confirmation bias, thus mitigating the risk that the Scrum team makes a wrong investment decision in the next Sprint Planning. As the saying goes: Love the customers’ problem, not your solution.) Copy & paste PO: The Product Owner creates Product Backlog items by breaking down requirement documents received from stakeholders into smaller chunks. (That scenario helped to coin the nickname “ticket monkey” for the Product Owner. Remember: Refining Product Backlog items is a team exercise. Moreover, using practices like user stories templates helps everyone understand the Why, the What, and the How. Remember Karl Popper: “Always remember that it is impossible to speak in such a way that you cannot be misunderstood.”) Dominant PO: The Product Owner creates Product Backlog items by providing not just the ‘Why’ but also the ‘How’ and the ‘What.’ (Just stick with the Scrum Guide and its built-in checks & balances: The Developers answer the ‘How’ question–the technical implementation–, and both the team and the Product Owner collaborate on the ‘What’ question: What scope is necessary to achieve the desired purpose?) Prioritization by proxy: A single stakeholder or a committee of stakeholders prioritizes the Product Backlog. (The strength of Scrum is building on the solid position of the Product Owner. The Product Owner is the only person to decide what tasks become Product Backlog items. Hence, the Product Owner also decides on ordering the Product Backlog. Take away that empowerment, and Scrum turns into a pretty powerful waterfall 2.0 process.) 100% in advance: The Scrum team creates a Product Backlog covering the complete project or product upfront because the release scope is believed to be limited. (Let me ask a question: How can you be sure to know today what to deliver six months from now when you work on a complex, adaptive problem? Isn’t not being able to predict the future the reason that you employ Scrum in the first place?) Over-sized: The Product Backlog contains more items than the Scrum team can deliver within three to six sprints. (This practice very likely will result in wasted efforts: You will refine work items that the Developers will never turn into Increments. Moreover, by investing all the efforts upfront, you may fall victim to the sunk cost fallacy, delivering less value than possible.) Outdated issues: The Product Backlog contains items that haven’t been touched for several weeks or more. (That is typically the length of three to four Sprints. If the Product Owner is hoarding backlog items, the risk emerges that older items become outdated, thus rendering previously invested work of the Scrum team obsolete.) Everything is detailed and estimated: All Product Backlog items are entirely detailed and estimated. (That is too much upfront work and bears the risk of misallocating the Scrum team’s time. The refinement of Product Backlog items is a continuous effort only to the point where the Scrum team feels comfortable turning these items into Increments.) Component-based items: The Product Backlog items are sliced horizontally based on components instead of vertically based on end-to-end functionality. (This may be either caused by your organizational structure, an effect called Conway’s law. In this case, overcome this organizational debt by moving to cross-functional teams to improve the Scrum team’s delivery ability. Otherwise, the Scrum team should invest in a workshop on writing better Product Backlog items.) Missing acceptance criteria: There are Product Backlog items that need additional acceptance criteria without listing them. (It is unnecessary to have all acceptance criteria ready at the beginning of the refinement cycle, although they would make the task much more accessible. However, all Product Backlog items need to meet the Definition of Done and—probably—specific requirements at the work item level. If the Definition of Done does not provide the latter ones, the now necessary acceptance criteria shall result from the refinement process.) No more than a title: The Product Backlog contains items that comprise little more than a title. (Creating noise by adding numerous “reminders” to the Backlog, thus obfuscating the signal it shall provide, will diminish the Scrum team’s capability to create valuable Increments for the customers. Ideas do not belong in the Product Backlog; they are part of the product discovery system.) User story author: The Product Owner invests too much time upfront in creating Product Backlog items, making them too detailed. (If a work item looks complete, the Developers might not see the necessity to get involved in further refinement. This way, a “fat” Product Backlog item reduces the team’s engagement level, compromising the creation of a shared understanding. By the way, this didn’t happen back in the days when we used index cards, given their physical limitation.) No research: The Product Backlog contains few to no spikes or time-boxed research tasks. (This effect often correlates with a Scrum team spending too much time discussing future problems instead of researching them with a spike as part of a continuous Product Backlog refinement process.) Involving the Scrum team—why? The Product Owner is not involving the entire Scrum team in the Product Backlog refinement process and instead relies on just the “lead engineer” and a designer. Moreover, the Developers are okay with this approach as it allows them to write more code which they prefer over figuring out what is worth building. (When trying to solve a complex problem, there are no experts but many competing ideas. Therefore, limiting the active participants in refinement activities to a few team members instead of the whole Scrum team increases the risk of falling victim to confirmation bias as the diversity of opinion is artificially limited.) Sprint Planning Anti-Patterns The number two area on my list of Product Owner anti-patterns is the Sprint Planning itself: What are we fighting for? The Product Owner cannot align the business objective of the upcoming Sprint with the Product Goal and overall product vision. (A serious objective answers the “What are we fighting for?” question. It is also a negotiation between the Product Owner and the Developers to a certain extent. The objective is focused and measurable, as the Sprint Goal and the Developers’ forecast go hand in hand.) No business objective, no Sprint Goal, just random stuff: The Product Owner proposes a direction that resembles a random assortment of tasks, providing no cohesion. Consequently, the Scrum Team does not create a Sprint Goal. (If this is the natural way of finishing your Sprint Planning, you probably have outlived the usefulness of Scrum as a product development framework. Depending on the maturity of your product, Kanban may prove to be a better solution. Otherwise, the randomness may signal a weak Product Owner who listens too much to stakeholders instead of composing and ordering the Product Backlog appropriately.) Unfinished business: Unfinished user stories and other tasks from the last Sprint spill over into the new Sprint without any discussion. (There might be good reasons for that, for example, a task’s value has not changed. It should not be an automatism, though; remember the sunk cost fallacy.) Last minute changes: The Product Owner tries to squeeze in some last-minute Product Backlog items that have not been refined. (Principally, it is the prerogative of the Product Owner to make such kinds of changes to ensure that the Developers work only on the most valuable tasks at any given time. However, if the Scrum Team is otherwise practicing Product Backlog refinement sessions regularly, these occurrences should be a rare exception. If those happen frequently, it indicates that the Product Owner needs help ordering the Product Backlog and improving team communication. Or the Product Owner needs support to deal with pushy stakeholders.) Output focus: The Product Owner pushes the Developers to take on more tasks than they could realistically handle. Probably, the Product Owner is referring to former team metrics such as velocity to support their desire. (This is also a road to becoming a feature factory and deserves attention from the team’s Scrum Master. It violates the Developers’ prerogative to pick Product Backlog items for the Sprint Backlog and Scrum Values.) No preparation: The Product Owner does not invest adequately in continuously refining an actionable Product Backlog in collaboration with the Developers. (The Product Backlog needs to represent the best possible use of the Developers’ time from a customer value perspective at any given moment. In other words, your Scrum Team’s Product Backlog has to be actionable 24/7. By my standards, you need to be capable of running a meaningful Sprint Planning instantly. Preparing a few basic Product Backlog items an hour before the beginning of the Sprint Planning is not enough.) Sprint Anti-Patterns Another area prone to Product Owner anti-patterns is the Sprint: Absent PO: The Product Owner is absent most of the Sprint and is not available to answer questions of the Developers. (As the Sprint Backlog is emergent and the Developers may identify necessary new work or the scope of previously identified work may need to be adjusted, the Product Owner’s absence can leave the Developers in the dark, risking the accomplishment of the Sprint Goal.) PO clinging to tasks: The Product Owner cannot let go of Product Backlog items once they become part of the Sprint Backlog. For example, the Product Owner increases the scope of a work item or changes acceptance criteria once the Developers select this Product Backlog item for the Sprint Backlog. (There is a clear line: before a Product Backlog item becomes part of the Sprint Backlog, the Product Owner is responsible. However, once it moves from one backlog to the other, the Developers become responsible. If changes become acute during the Sprint, the team will collaboratively decide how to handle them.) Inflexible PO: The Product Owner is not flexible to adjust acceptance criteria. (If the work on a task reveals that the agreed-upon acceptance criteria are no longer achievable or waste, the Scrum Team needs to adapt to the new reality. Blindly following the original plan violates core Scrum principles.) Delaying PO: The Product Owner does not provide feedback on work items from the Sprint Backlog once those are done. Instead, they wait until the end of the Sprint. (The Product Owner should immediately inspect Product Backlog items that meet the acceptance criteria. Otherwise, the Product Owner will create an artificial queue within the Sprint, unnecessarily increasing the cycle time. This habit also puts reaching the Sprint Goal at risk. Note: Inspecting Product Backlog items does not equal some sort of work acceptance or quality gate. There is no such thing in Scrum. Once a Product Backlog item meets the Definition of Done, it can be released into the hands of users.) Sprint stuffing: The Developers accomplished the Sprint Goal early, and the Product Owner is pushing them hard to accept new work from the Product Backlog to fill the “void.” (The Scrum Team decided collaboratively on the Sprint Goal, and the Developers committed to delivering. Consequently, it is the prerogative of the Developers to decide on the composition of the Sprint Backlog. Should they manage to accomplish the Sprint Goal before the Sprint’s end, it is their sole decision to fill the remaining time. Accepting new work from the Product Backlog may be one way of filling the remaining Sprint time-box. This also applies to refactoring parts of the tech stack, exploring new technology that might be useful, fixing some bugs, or sharing knowledge with fellow teammates. Scrum is not in the business of maximizing the utilization rates of team members. Achieving the Sprint Goal is sufficient.) Sprint cancellations without consultation: The Product Owner cancels Sprints without consulting the Scrum Team. (It is the prerogative of the Product Owner to cancel Sprints. However, the Product Owner should not do this without a serious cause. The Product Owner should also never abort a Sprint without consulting the rest of the team. Maybe, someone has an idea on how to save the Sprint Goal, provided it is still useful? Misusing the cancellation privilege indicates a serious team collaboration issue and a lack of commitment to live Scrum Values.) No Sprint cancellation: The Product Owner does not cancel a Sprint whose Sprint Goal can no longer be achieved or has become obsolete. (If the Scrum Team identified a unifying Sprint Goal, for example, integrating a new payment method, and the management then abandons that functionality mid-sprint, continuing working on the Sprint Goal would be wasteful. In such a case of obsolescence, the Product Owner has to consider canceling the Sprint.) PO Anti-Patterns during the Daily Scrum By comparison to other Scrum events, the Daily Scrum is remarkably resilient to Product Owner anti-patterns: Assignments: The Product Owner assigns tasks directly to team members. (The Developers self-organize their work: “No one else tells them how to turn Product Backlog items into Increments of value.” Source: Scrum Guide 2020.) Additional work: The Product Owner or even other stakeholders attempt to introduce new work to the current Sprint during the Daily Scrum. (This behavior may be acceptable for high priority bugs, although the Developers should be aware of those before the Daily Scrum. Otherwise, the composition of the Sprint Backlog is the sole responsibility of the Developers: they may accept new work during the Sprint; however, that is their sole decision.) Sprint Review Anti-Patterns Finally, there is the Sprint Review. Despite that it is an outstanding opportunity for the Product Owner to improve the collaboration with both stakeholders and Developers and figure out collectively in what direction to take the product next, some Product Owners do not get the message: Selfish PO: Product Owners present “their” accomplishments to the stakeholders. (Scrum is a remarkably egalitarian affair: No one has any authority to tell teammates what, when, or how to do something. There are no sub-roles on Scrum teams, and there is no hierarchy. Instead, Scrum builds everything on self-management and collective responsibility—the Scrum team wins together, and the Scrum team loses together. Remember the old saying: There is no “I” in “team?”) “Acceptance” by the PO: The Product Owner uses the Sprint Review to “accept” Product Backlog items that Developers consider “done.” (A formal "acceptance" of work packages by the Product Owner is not foreseen in Scrum, for there is the Definition of Done. However, a feedback loop—did the Developers deliver the agreed-upon functionality?—is valuable. However, Product Owners should also decouple this feedback loop from the Sprint Review. Instead, Product Owners should communicate with the Developers whenever needed or when work items meet the Definition of Done.) Unapproachable PO: The Product Owner is not accepting feedback from stakeholders or the Developers. (I get it: Loving your solution over the customers’ problems feels good. Moreover, a bit of confirmation bias may prevent our Product Owners from getting distracted from pursuing their beloved solution. But unfortunately, they do not get paid to roll out their solution. This “living in their PO bubbles” approach hence violates the prime purpose of the Sprint Review event: Figure out collaboratively whether the Scrum team is still on track to meeting the Product Goal—which requires openness on the side of the Product Owners in the first place.) Conclusion Admittedly, the Product Owner role is the most challenging Scrum role, and the higher the expectations are, the easier it is to fail them. We do not get paid as a Scrum team to practice Scrum. No stakeholder cares for that aspect. However, we do get paid to improve the lives of our customers while contributing to the sustainable business of our organization. In that model, the Product Owner is the linchpin of value creation as they decide where to take the Scrum team next. No other role in Scrum can contribute to mediocre outcomes like the Product Owner—garbage in, garbage out. Fortunately, there is hope as continuous improvement also applies to the Product Owner role. This list of Product Owner anti-patterns may be a starting point. What Product Owner anti-patterns have you observed that are missing in the list? Please share with us in the comments. 📖 Related Posts Scrum: 20 Sprint Planning Anti-Patterns 27 Sprint Anti-Patterns Holding Back Scrum Teams Daily Scrum Anti-Patterns: 24+2 Ways to Improve as a Scrum Team 27 Product Backlog and Refinement Anti-Patterns Download the Scrum Anti-Patterns Guide for free. 📺 Watch the Video on Product Owner Anti-Patterns The videos of the webinar are available now: {"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/VnopIzbRJ8k.jpg?itok=hrys7Y7j","video_url":"https://youtu.be/VnopIzbRJ8k","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} Note: If the browser will not play the playlist automatically, click here to watch the Product Owner Anti-Patterns video directly on Youtube. ✋ Do Not Miss Out and Learn more about Product Owner Anti-Patterns — Join the 11,000-plus Strong ‘Hands-on Agile’ Slack Community I invite you to join the “Hands-on Agile” Slack Community and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world. If you like to join all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free. The article Product Owner Anti-Patterns — 33 Ways to Improve as a PO was first published on Age-of-Product.com.

Das Sprint Planning ist ein zentrales Scrum-Ereignis, welches entscheidet, wie sich das Leben Ihrer Kunden mit dem nächsten Inkrement verbessern wird. Erfahren Sie mehr darüber, wie Sie Ihren Kunden durch die Vermeidung von 20 gängigen Sprint Planning Anti-Patterns helfen können.

TL; DR: Scrum Master Anti-Patterns The Sprint Planning is a core event that defines how your customers’ lives will improve with the following Product Increment. Learn more on how to improve its effectiveness by avoiding 20 common Sprint Planning anti-patterns. 🇩🇪 Zur deutschsprachigen Version des Artikels: 20 Sprint Planning Anti-Patterns. 🗳 Update: Join the poll and its lively discussion on LinkedIn. 🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 35,000-plus subscribers. 🎓 Join Stefan in one of his upcoming Professional Scrum training classes! The Purpose of the Sprint Planning Scrum’s Sprint Planning aims to align the Developers and the Product Owner on what to build next, delivering the highest possible value to customers. First, the Product Owner points to the team’s Product Goal and introduces the business objective of the upcoming Sprint. The Scrum Team then collaboratively creates a Sprint Goal, considering who is available and the target the team shall accomplish. Next, the Developers forecast the work required to achieve the Sprint Goal by picking the right items from the Product Backlog and transferring them to the Sprint Backlog. Also, the Developers need to create a plan on how to accomplish their forecast. No longer mandatory since the 2020 edition of the Scrum Guide is that the Scrum team agrees to tackle at least one high-priority improvement issue from the previous Sprint Retrospective. The Scrum Guide characterizes the Sprint Planning as follows: Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team. The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Scrum Team may also invite other people to attend Sprint Planning to provide advice. Basically, the Sprint Planning answers three questions: Why is this Sprint valuable? (The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.) What can be Done this Sprint? (Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence. Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts. How will the chosen work get done? (For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value. The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.) Source: Scrum Guide 2020. Suppose the Scrum Team has been successfully utilizing the Product Backlog refinements to create and maintain an actionable Product Backlog. In that case, the Sprint Planning consumes much less time than the eight hours the Scrum Guides lists for a month-long Sprint. Basically, the Developers and the Product Owner adjust the previously discussed scope of the upcoming Sprint to the available capacity. Alternatively, a valuable new task may have appeared overnight, and the Product Owner wants this task to become a part of the next Sprint, too. Consequently, some previously considered Product Backlog items won’t make it into the Sprint Backlog. A good Scrum team can handle that in ten to 30 minutes before moving on to the decomposition tasks and the initial planning of how the Developers intend to accomplish the work of the Sprint. Sprint Planning Anti-Patterns There are mainly three categories of Sprint Planning anti-patterns. They concern the Developers, the Product Owner, and the Scrum team: Sprint Planning Anti-Patterns of the Developers Capacity? The Developers overestimate their capacity and take on too many tasks. (The Developers should instead consider everything that might affect its ability to deliver. The list of those issues is long: public holidays, new team members and those on vacation leave, team members quitting, team members on sick leave, corporate overhead, Scrum events as practices such as Product Backlog refinement, and other meetings, to name a few.) What technical debt? The Developers do not demand adequate time to tackle technical debt and bugs and preserve the quality standard of the product. Instead, they fully embrace the feature factory, shipping one new feature after the other. (My rule of thumb is that the Developers shall consider allocating up to 20 % of their time to fixing bugs and refactoring the codebase. A high-quality tech stack is at the core of being able as a Scrum team to adapt the following steps to lessons learned and recent market trends. Technical excellence is a prerequisite of any form of business agility; preserving this state is a continuous process that requires a steady and substantial investment. Read more: Technical debt and Scrum.) No slack time: The Developers do not demand 20% slack time—or unplanned capacity—from the Product Owner. (This overlaps with the Sprint Planning, creating Sprint Goals, and the team’s ability to forecast. However, it cannot be addressed early enough. If a team’s capacity is always utilized at 100 %, its performance will decrease. Everyone will focus on getting their tasks done. There will be less time to support teammates or to pair. Minor issues will no longer be addressed immediately. And ultimately, the ‘I am busy’ attitude will reduce the creation of a shared understanding among all team members why they do what they are doing.) Planning too detailed: During the Sprint Planning, the Developers plan every single task of the upcoming Sprint in advance. (Don’t become too granular. One-quarter of the tasks are more than sufficient to not just start with the Sprint, but also start learning. The Sprint Backlog is emergent, and doing too much planning upfront might result in waste. Scrum is not a time-boxed form of the waterfall planning practice.) Too much estimating: The Developers even estimate sub-tasks. (That looks like accounting for the sake of accounting to me. So don’t waste your time on that. Remember: the purpose of estimating is to identify misalignment among the Developers regarding the What and How of items from the Product or Sprint Backlog. Read more: Estimates Are Useful, Just Ditch the Numbers.) Too little planning: The Developers skip planning altogether. (Skipping planning is unfortunate, as it is also an excellent opportunity to talk about how to spread knowledge among the Developers, where the architecture is heading, or whether the tools are adequate. For example, the team might also consider who will be pairing with whom on what task. The Developers’ planning part is also well-suited to consider how to reduce technical debt, see above.) Team leads? The Developers do not devise a plan to deliver their forecast collaboratively. Instead, a ‘team lead’ does all the heavy lifting and probably even assigns tasks to individual Developers. (I know that senior developers do not like the idea, but there is no ‘team lead’ on a Scrum Team. Read More: Why Engineers Despise Agile.) 📅 Join 200-plus peers on May 30, 2022: HoA #42: The Skinny on Lean Roadmapping and OKRs w/ Janna Bastow. Sprint Planning Anti-Patterns of the Product Owner What are we fighting for? The Product Owner cannot align the business objective of the upcoming Sprint with the Product Goal and overall product vision. (A serious objective answers the “What are we fighting for?” question. It is also a negotiation between the Product Owner and the Developers to a certain extent. The objective is focused and measurable, as the Sprint Goal and the Developers’ forecast go hand in hand.) No business objective, no Sprint Goal, just random stuff: The Product Owner proposes a direction that resembles a random assortment of tasks, providing no cohesion. Consequently, the Scrum Team does not create a Sprint Goal. (If this is the natural way of finishing your Sprint Planning, you probably have outlived the usefulness of Scrum as a product development framework. Depending on the maturity of your product, Kanban may prove to be a better solution. Otherwise, the randomness may signal a weak Product Owner who listens too much to stakeholders instead of composing and ordering the Product Backlog appropriately.) Unfinished business: Unfinished user stories and other tasks from the last Sprint spill over into the new Sprint without any discussion. (There might be good reasons for that, for example, a task’s value has not changed. It should not be an automatism, though; remember the sunk cost fallacy.) Last minute changes: The Product Owner tries to squeeze in some last-minute Product Backlog items that have not been refined. (Principally, it is the prerogative of the Product Owner to make such kinds of changes to ensure that the Developers work only on the most valuable tasks at any given time. However, if the Scrum Team is otherwise practicing Product Backlog refinement sessions regularly, these occurrences should be a rare exception. If those happen frequently, it indicates that the Product Owner needs help ordering the Product Backlog and improving team communication. Or the Product Owner needs support to deal with pushy stakeholders.) Output focus: The Product Owner pushes the Developers to take on more tasks than they could realistically handle. Probably, the Product Owner is referring to former team metrics such as velocity to support their desire. (This is also a road to becoming a feature factory and deserves attention from the team’s Scrum Master. It violates the Developers’ prerogative to pick Product Backlog items for the Sprint Backlog and Scrum Values.) No preparation: The Product Owner does not invest adequately in continuously refining an actionable Product Backlog in collaboration with the Developers. (The Product Backlog needs to represent the best possible use of the Developers’ time from a customer value perspective at any given moment. In other words, your Scrum Team’s Product Backlog has to be actionable 24/7. By my standards, you need to be capable of running a meaningful Sprint Planning instantly. Preparing a few basic Product Backlog items an hour before the beginning of the Sprint Planning is not enough.) Sprint Planning Anti-Patterns of the Scrum Team Irregular Sprint lengths: The Scrum team has variable Sprint cadences. For example, tasks are not sized to fit into the regular Sprint length. Instead, the Sprint length is adapted to the size of the tasks or the Sprint Goal at hand. (The Sprint length is not static but adjustable to offer the Scrum team the best balance between being up-to-date with customer needs while having sufficient, uninterrupted time to focus on meaningful work. When the learning curve is steep, Sprints are short. Once the Scrum team becomes more educated, Sprint lengths might expand. Also, it is pretty common, for example, to extend the Sprint length at the end of the year when most of the team members are on holiday. However, changing the Sprint length flexibly as “needed” is a dark pattern. Instead of changing the Sprint length to accommodate the Sprint Goal, the Scrum Team should invest more effort into the appropriate sizing of tasks.) Over-commitment: The Scrum team regularly takes on too many tasks and moves unfinished work directly to the next Sprint. (If two or three items spill over to the next Sprint while the Developers meet the Sprint Goal, so be it. On the other hand, if regularly 30 to 40 percent of the original forecast is not delivered during the Sprint, the Scrum team may have created a kind of ‘time-boxed Kanban.’ Maybe, this is the right moment to ask the Scrum team whether moving to Kanban might be an alternative. If the team considered Scrum still to be its choice, I would recommend to put more energy into Product Backlog refinement and creating meaningful Sprint Goals.) Stage-Gate® by DoR: The Scrum Team decides that a “definition of ready” is advantageous but handles it dogmatically, thus creating a stage-gate-like approval process. (That is an exciting topic for discussion among the team members. For example, should a valuable user story be postponed to another Sprint just because the front-end designs will not be available for another two working days? My suggestion: take it to the team. If they agree with the circumstances and accept the corresponding Product Backlog item into the Sprint — that is fine. However, suppose the “definition of ready” is used as a checklist, rejecting everything that is not 100 percent covered. In that case, you are reintroducing waterfall through the backdoor, only this time it is the Developers doing that. Read More: The Dangers of a Definition of Ready.) No standard for considering Product Backlog items ‘ready:’ The Scrum team does not have a shared understanding of what a “Sprint-ready” Product Backlog item requires. (This is the opposite side of being dogmatic about applying a “definition of ready.” So now, the Developers select unsuited work items that may cause unnecessary disruptions during the Sprint, possibly even endangering achieving the Sprint Goal, into the Sprint. Laissez-faire does not help either.) Forecast imposed: The Sprint forecast is not a team-based decision. Or it is not free from outside influence. (There are several anti-patterns here. For example, an assertive Product Owner dominates the Developers by defining their scope of the forecast. Or a stakeholder points at the team’s previous velocity demanding to take on more user stories. (“We need to fill the free capacity.”) Or the ‘tech lead’ of the Developers makes a forecast on behalf of everyone else.) Planning ignored: The Developers are not participating collectively in the Sprint Planning. Instead, two team members, for example, the “tech lead” and “UX lead,” represent the team. (As far as the idea of one or two “leading” teammates in a Scrum team are concerned, there are none, see above. And unless you are using Nexus or LeSS—no pun intended—where teams are represented in the overall Sprint Planning, the whole Scrum Team needs to participate. It is a team effort, and everyone's voice hence needs to be heard. Otherwise, transparency will suffer and flawed decisions might be made, reducing value creation and increasing risk.) Sprint Planning Anti-Patterns of the Scrum Master The Product Owner is responsible for the business objective of the upcoming Sprint. They hence need to guide the Scrum team’s effort during Product Backlog refinement to provide an appropriately prepared, actionable Product Backlog before the actual Sprint Planning. At the same time, the Developers are in charge of selecting the necessary Product Backlog items to meet the collaboratively created Sprint Goal. So, what are Sprint Planning anti-patterns of the Scrum Master, you may ask yourself? Besides being complicit in the Sprint Planning anti-patterns sketched above by not addressing them, I can think of one Sprint Planning anti-pattern that directly falls into the responsibility of the Scrum Master. Despite the changes to the Scrum Guide in 2020, addressing an important improvement issue from the previous Sprint Retrospective every Sprint is still an important step to help the Scrum Team improve continuously. Therefore, failing to support the Scrum team in that matter constitutes a Sprint Planning anti-pattern in my eyes. Conclusion The Sprint Planning is a core event, defining how your customers’ lives will improve with the next Product Increment and not be taken lightly. Fortunately, most of the before-mentioned Sprint Planning anti-patterns are simple to fix. Just take it to the team, respect Scrum Values, self-management, and Scrum’s built-in checks & balances. What Sprint Planning anti-patterns have you observed? Please share it with us in the comments. 📖 Related Posts Sprint Planning Checklist Liberating Structures for Scrum (2): The Sprint Planning 27 Sprint Anti-Patterns Holding Back Scrum Teams Daily Scrum Anti-Patterns: 24+2 Ways to Improve as a Scrum Team 27 Product Backlog and Refinement Anti-Patterns Download the Scrum Anti-Patterns Guide for free. 📺 Watch the Video on Sprint Planning Anti-Patterns The video of the Sprint Planning Anti-Patterns webinar is available on Youtube: {"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/oJliMvqU2TU.jpg?itok=XMBhyGza","video_url":"https://youtu.be/oJliMvqU2TU","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} Note: If the browser will not play the playlist automatically, click here to watch the Webinar Sprint Planning Anti-Patterns playlist directly on Youtube. ✋ Do Not Miss Out and Learn more about Sprint Planning Anti-Patterns — Join the 11,000-plus Strong ‘Hands-on Agile’ Slack Community I invite you to join the “Hands-on Agile” Slack Community and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world. If you like to join all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free. The article Scrum: 20 Sprint Planning Anti-Patterns was first published on Age-of-Product.com.