Welcome to the Home of Scrum! ™

Scrum Values make the use of Scrum successful. How can you and your Team live these values during the Daily Scrum? Check it out!

In Kürze: 27 Sprint Anti-Patterns Willkommen zum Sprint Anti-Patterns-Artikel aus unserer Serie über Scrum-Anti-Patterns. Ich adressiere in diesem Artikel sprintbezogene Fehlverhalten der drei Scrum-Rollen, der Stakeholder bzw. Interessenvertreter sowie des IT-Management. 🗞 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 34.000 Abonnenten anschließen. 🎓 Nehmen Sie an einer von Stefans kommenden Professional Scrum-Schulungen teil! 27 Sprint Anti-Patterns Diese Liste bekannter Sprint-Anti-Patterns gilt für alle Scrum-Rollen und darüber hinaus. Sie betreffen den Product Owner, die Entwickler, den Scrum-Master, das Scrum-Team selbst, sowie die Stakeholder und das IT-Management. Sprint Anti-Patterns des Product Owners Der abwesende Product Owner: Der Product Owner ist den größten Teil des Sprints abwesend und steht den Entwicklern nicht für Fragen zur Verfügung. (Da das Sprint-Backlog sich herausbildet und ggf. neue Arbeiten als notwendig für das Erreichen des Sprint-Ziels identifiziert werden, könnte diese Haltung die Entwickler unnötig im Dunkeln tappen lassen und die Erreichung des Sprint-Ziels gefährden). Der klammernde PO: Der Product Owner kann von Product Backlog-Einträgen nicht loslassen, sobald dieses Teil des Sprint Backlog werden. Der Product Owner erhöht beispielsweise den Umfang eines Eintrages oder ändert die Akzeptanzkriterien, nachdem das Team die Aufgabe in das Sprint Backlog aufgenommen hat. (Es gibt hier eine klare Linie: Bevor ein Product-Backlog-Eintrag zu einem Teil des Sprint Backlog wird, ist der Product Owner verantwortlich. Sobald der Product Backlog-Eintrag jedoch Teil des Sprint Backlogs wird, ist das Entwicklungsteam verantwortlich. Wenn Änderungen während des Sprints erforderlich werden, entscheidet das Team gemeinsam, wie es damit umgeht). Der unflexible Product Owner: Der PO ist nicht flexibel bei der Anpassung der Akzeptanzkriterien. (Wenn sich bei der Arbeit an einer Aufgabe herausstellt, dass die vereinbarten Akzeptanzkriterien nicht mehr erreichbar sind, muss sich das Scrum-Team an die neue Realität anpassen. Die blinde Befolgung des ursprünglichen Plans verstößt gegen Scrum-Prinzipien und das Agile Manifest.) Der verzögernde PO: Der Product Owner gibt kein Feedback zu Arbeiten aus dem Sprint-Backlog, sobald diese beendet sind. Stattdessen wartet er oder sie bis zum Ende des Sprints. (Der Product Owner sollte Aufgaben, die die Akzeptanzkriterien erfüllen, sofort mit dem jeweiligen Entwickler(n) überprüfen. Andernfalls schafft der Product Owner eine künstliche Warteschlange innerhalb des Sprints, welche die Cycle-Time von Product Backlog-Einträgen unnötig erhöht. Diese Gewohnheit gefährdet auch das Erreichen des Sprint-Ziels). Missbrauch des Sprint-Abbruchs: Der Product Owner bricht Sprints ab, um dem Team seinen Willen aufzuzwingen. (Es ist das Vorrecht des Product Owners, Sprints abzubrechen. Der Product Owner sollte dies jedoch nicht ohne einen ernsthaften Grund tun. Auch sollte dies niemals ohne vorherige Rücksprache mit den anderen Scrum-Team-Mitgliedern geschehen. Ggf. hat das Team eine Idee, wie der Sprint gerettet werden kann. Des Weiteren weist der Missbrauch des Abbruchprivilegs auch auf ein ernstes Problem der Zusammenarbeit des Teams hin). Kein Sprint-Abbruch: Der Product Owner bricht einen Sprint, dessen Sprint-Ziel nicht mehr sinnvoll ist, nicht ab. (Wenn der Product Owner eine lohnende Aufgabe für den Sprint identifiziert hat, z. B. die Integration einer neuen Zahlungsmethode, und das Management diese Zahlungsmethode dann mitten im Sprint aufgibt, wäre es eine Verschwendung, weiter an dem Sprint-Ziel zu arbeiten. In diesem Fall sollte der Product Owner in Erwägung ziehen, den Sprint abzubrechen). Sprint Anti-Patterns der Entwickler Kein Work-in-Progress-Limit: Es gibt kein Limit für Work-in-Progress. (Der Zweck des Sprints ist es, ein oder mehrere potenziell lieferbare Produkt-Inkremente zu erstellen, welche den Kunden und damit dem Unternehmen einen Mehrwert bietet. Dieses Ziel erfordert fokussierte Arbeit, um zu gewährleisten, dass die für das Erreichen des Sprint-Ziels als notwendig erachtete Arbeit geleistet wird. Die Flow-Theorie legt nahe, dass sich die Produktivität eines Teams mit einem Work-in-Progress (WiP)-Limit verbessert. Das WiP-Limit definiert die maximale Anzahl von Aufgaben, an denen ein Team gleichzeitig arbeiten kann. Das Überschreiten dieser WiP-Grenze führt zur Bildung zusätzlicher Warteschlangen, die folglich den Gesamtdurchsatz des Teams reduzieren. Die Zyklusdauer, d. h. der Zeitraum zwischen dem Start und dem Ende der Arbeit an einer Aufgabe, verlängert sich in Folge und die Produktivität sinkt.) Rosinenpicken: Die Entwickler suchen sich nur die Rosinen unter den Arbeitsaufgaben heraus. (Dieser Effekt überlagert sich oft mit dem fehlenden WiP-Limit-Problem. Menschen werden durch kurzfristige Befriedigung motiviert. Es fühlt sich einfach gut an, ein weiteres Puzzle vom Sprint-Board zu lösen. Im Vergleich zu diesem Dopamin-Fix ist es weniger befriedigend im Code Review zu prüfen, wie ein anderes Teammitglied ein anderes Problem gelöst hat. Daher bemerkt man oft, dass sich z. B. Tickets in der Code-Review-Spalte unbearbeitet ansammeln. Dies ist auch ein Zeichen dafür, dass sich die Entwickler noch nicht vollständig selbst organisiert. Achten Sie auch auf die Daily Scrums, ob sich dort dieses Problem manifestiert, und sprechen Sie das Thema während der Sprint-Retrospektive an). Sprint-Board nicht auf dem letzten Stand: Die Entwickler aktualisiert die Tickets auf dem Sprint-Board nicht rechtzeitig, um den aktuellen Stand der Arbeiten widerzuspiegeln. (Das Sprint-Board, unabhängig davon, ob es sich um ein physisches oder digitales Board handelt, ist nicht nur für die Koordinierung der Arbeit der Entwickler von entscheidender Bedeutung. Es ist auch ein integraler Bestandteil der Kommunikation des Scrum-Teams mit seinen Stakeholdern. Ein Board, das nicht auf dem neuesten Stand ist, beeinträchtigt das Vertrauen der Stakeholder in das Scrum-Team. Eine Verschlechterung des Vertrauens kann dann zu Gegenmaßnahmen aufseiten der Stakeholder führen. Das (Management-)Pendel könnte in der Folge zu traditionellen Methoden wie PRINCE2 zurückschwingen. Nebenjobs: Die Entwickler arbeitet an Themen, die auf dem Sprint-Board nicht sichtbar sind. (Während Vergeßlichkeit ggf. noch entschuldbar ist, ist das Umleiten von Entwicklungskapazitäten unter Umgehung des Produkt Owners, der für die Rentabilität der Investition in die Arbeit der Entwickler verantwortlich ist, nicht akzeptabel. Dieses Verhalten signalisiert auch einen erheblichen Konflikt innerhalb des „Teams“. Angesichts dieser Demonstration von Misstrauen — warum haben die Entwickler dieses scheinbar wichtige Thema nicht während der Sprintplanung oder davor angesprochen — ist das Entwicklungsteam wahrscheinlich ohnehin eher eine Gruppe als ein Team). Goldene Türklinken: Das Entwicklungsteam erhöht den Umfang des Sprints, indem es unnötige Arbeit zu den Product-Backlog-Einträgen des Sprint-Backlogs hinzufügt. (Dieser Effekt wird oft als Scope-Stretching oder Vergoldung bezeichnet. Das Entwicklungsteam ignoriert die ursprüngliche Vereinbarung mit dem Product Owner über den Umfang der Arbeiten. Aus welchem Grund auch immer erweitert das Team die Aufgabe ohne vorherige Rücksprache mit dem Product Owner. Diese Ignoranz kann zu einer fragwürdigen Allokation der verfügbaren Kapazitäten führen. Es gibt jedoch eine einfache Lösung: Die Entwickler und der Product Owner müssen öfter miteinander sprechen, um ein gemeinsames Verständnis von der Produktvision bis hinunter zum einzelnen Product Backlog-Eintrag zu schaffen und so das Vertrauensniveau zu verbessern. Wenn der Product Owner bisher noch nicht mit dem Entwicklungsteam zusammen sitzt, dann wäre jetzt der richtige Zeitpunkt, um es sich noch einmal zu überlegen.) Sprint Anti-Patterns des Scrum Masters Flow-Unterbrechung: Der Scrum Master ermöglicht es den Stakeholdern, den Flow des Scrum Teams während des Sprints zu unterbrechen. Es gibt mehrere Möglichkeiten, wie Stakeholder den Fluss des Teams während eines Sprints unterbrechen können. Jedes der Beispiele wird die Produktivität des Teams behindern und kann die Erreichung des Sprint-Ziel gefährden. Es ist die Aufgabe des Scrum Masters zu verhindern, dass diese Verhalten sich manifestieren: Der Scrum Master hat eine Laissez-faire-Politik, was den Zugang zum Entwicklungsteam betrifft. Insbesondere schult er oder sie die Stakeholder nicht über die negativen Auswirkungen von Störungen und wie diese die Erreichung des Sprint-Ziels gefährden können. Der Scrum Master widerspricht nicht, wenn Vorgesetzte Teammitglieder aus dem Scrum Team nehmen und ihnen andere Aufgaben zuweisen. Der Scrum Master hat nichts dagegen, dass das Management Teammitglieder als Experten zu anderen Meetings einlädt. Der Scrum Master drückt ein Auge zu, wenn der Product Owner die Prioritäten mitten im Sprint ändert. Schließlich erlaubt der Scrum Master den Stakeholdern oder Managern, das Daily Scrum in eine Reporting-Session zu verwandeln. Fehlende Unterstützung: Der Scrum Master unterstützt Teammitglieder nicht, die Hilfe bei einer Aufgabe benötigen. Oftmals erstellen Entwicklerteams Aufgaben, die ein Entwickler innerhalb eines Tages erledigen kann. Wenn jedoch jemand länger als zwei Tage mit einem solchen Job kämpft, ohne zu kommunizieren, dass er oder sie Unterstützung benötigt, so sollte der Scrum Master das Problem ansprechen und Unterstützung anbieten. Übrigens ist dies auch der Grund dafür, dass man jeden Tag auf Sprint-Boards diejenigen Tasks mit roten Punkten markiert, die sich nicht bewegt haben. (Mit anderen Worten: Wir verfolgen das Work-Item-Alter.) Mikromanagement: Der Scrum Master hindert den Product Owner — oder auch andere Personen — nicht daran, den Entwicklern Aufgaben direkt zuzuweisen. (Das Entwicklungsteam organisiert sich selbst, ohne dass ein Eingreifen von außen erforderlich ist. Und der Scrum Master ist in dieser Hinsicht das Schutzschild des Teams). #NixRetro: Es gibt keine Retrospektive, da das Team glaubt, dass es nichts zu verbessern gibt. Meines Erachtens gibt es kein agiles Nirwana, wo alles einfach perfekt ist. Wie so schön gesagt wird: Agilität ist eine Reise und kein Ziel. Es gibt immer etwas zu verbessern. Anmerkung: Ich glaube nicht, dass es die Aufgabe des Scrum-Masters ist, Tickets auf einem Sprint-Board zu verschieben. Die Mitglieder des Entwicklungsteams sollten dies z. B. während des Daily Scrum tun, wenn sie dies als hilfreich erachten. Es liegt auch nicht in der Verantwortung des Scrum-Masters, ein Online-Board zu aktualisieren, sodass es den Status eines entsprechenden physischen Boards widerspiegelt. Wenn die Entwickler ein Burn-Down-Diagramm für hilfreich halten, sollten die Teammitglieder das Diagramm auch selbst aktualisieren. Sprint Anti-Patterns des Scrum Teams Der einsame Streiter und das Sprint Backlog: Jemand fügt dem Sprint-Backlog einen Eintrag hinzu, ohne vorher das Entwicklungsteam zu konsultieren. (Die Kontrolle des Sprint Backlogs durch das Entwicklungsteam ist das Herzstück, um dem Team eine Prognose zu ermöglichen. Der Umfang ist daher während des Sprints per se erst einmal unantastbar. Änderungen in der Zusammensetzung des Sprint Backlog sind beispielsweise möglich, wenn nach dem Start eines Sprints ein kritischer Fehler auftritt oder notwendige Aufgaben hinzugefügt werden müssen. Die Aufnahme eines solchen Problems in das Sprint Backlog erfordert jedoch die Zustimmung des Entwicklungsteams und wahrscheinlich einen Ausgleich. Eine andere Aufgabe von ähnlicher Größe muss möglicherweise in das Product Backlog zurückgehen. All diesen Ausnahmen ist gemeinsam, dass das Entwicklungsteam insgesamt das letzte Wort hat. Kein einziger Teamkollege des Scrum-Teams kann alleine eine Aufgabe zum Sprint Backlog hinzufügen oder entfernen). Härtungssprint: Das Scrum-Team entscheidet sich für einen Härtungs- oder Aufräumsprint. (Das ist ein einfacher Fall: Es gibt in Scrum keinen Härtungssprint. Das Ziel des Sprints ist die Lieferung eines wertvollen, potenziell lieferbaren Produktinkrements. Zu diesem Zweck unterhält das Entwicklungsteam eine Definition von „Done“, um sicherzustellen, dass jeder das erforderliche Qualitätsniveau versteht, welches erreicht werden muss, damit ein Produktinkrement den Kunden zur Verfügung gestellt werden kann. Das Deklarieren von fehlerhaft oder unvollkommen bearbeiteten Aufgaben als „done“ verstößt somit gegen mehrere zentrale Scrum-Werte. Härtungssprints sind häufig ein Zeichen dafür, dass das Team und/oder die Organisation die agilen Prinzipien nur in geringem Maße anwenden. Dies mag daran liegen, dass das Team noch nicht crossfunktional arbeitet. Oder die Qualitätssicherung wird immer noch von einem funktionalen, nicht agilen Silo innerhalb der Entwicklungsorganisation durchgeführt. Oder das Entwicklungsteam fühlte sich möglicherweise unter Druck gesetzt, eine (willkürliche) Frist einzuhalten, und beschloss deswegen, die Qualität zu reduzieren. Aus welchem Grund auch immer ein Härtungs-Sprint in Betracht gezogen wird, in einer solchen Situation gibt es für den Scrum Master viel Arbeit zu erledigen.) Aneinander vorbei reden: Der Produkt Owner glaubt daran, X zu bekommen. Das Entwicklungsteam arbeitet an Y. (Dies ist nicht nur das Ergebnis einer mangelhaften Verfeinerung des Product Backlog. Dieses Anti-Pattern zeigt auch, dass das Scrum-Team es nicht geschafft hat, ein gemeinsames Verständnis über seine Aufgaben untereinander zu schaffen. Dafür gibt es viele Gründe, um nur einige aufzuzählen: Der Product Owner und die Mitglieder des Entwicklungsteams sprechen während des Sprints nicht genug miteinander. (Der Product Owner ist zu beschäftigt, um Fragen aus dem Team zu beantworten oder am Daily Scrum teilzunehmen. Oder das Team ist nicht an einem gemeinsamen Standort untergebracht.) Kein Mitglied des Entwicklungsteams hat jemals an Benutzertests oder Kundenbefragungen teilgenommen. Es gibt ein mangelndes Verständnis für die Probleme der Benutzer unter den Entwicklern. (Dies ist der Grund, warum die Programmierer auch regelmäßig Benutzer in Anwendertests befragen und beobachten sollten). Der Product Owner präsentierte eine zu detaillierte User Story, und niemand aus dem Entwicklungsteam hielt es für wichtig genug, sich genauer mit der Sache auseinanderzusetzen. Die User Story schien fertig zu sein. Wahrscheinlich fehlten in der User Story die Akzeptanzkriterien ganz oder die vorhandenen Akzeptanzkriterien haben das Problem nicht erfasst. Kein Gespür für Dringlichkeit: Am Ende des Sprints gibt es kein potenziell lieferbares Produkt-Inkrement. Es gab aber auch keinen Grund, den Sprint abzusagen. Es war nur ein ganz normaler Sprint. (Dies ist ein Zeichen dafür, dass dem Scrum-Team das Gefühl der Dringlichkeit fehlt, am Ende des Sprints Werte für die Kunden zu liefern. Wenn es akzeptabel ist, am Ende des Sprints kein Produkt-Inkrement zu liefern, dann wird die Grundidee von Scrum infrage gestellt. Denken Sie daran, dass ein Scrum-Team eine Prognose für seine kommende Wertschöpfung für die Einbeziehung in die Entscheidungsfindung, seine Autonomie und Selbstorganisation eintauscht. Die Schaffung einer minderwertigen Form von Kanban mit Time-Boxen unter der Bezeichnung „Scrum“ wird diese Vereinbarung nicht erfüllen. Daher ist es im ureigenen Interesse des Scrum-Teams, jedes Produkt-Inkrement auslieferbar zu machen, auch wenn diese letztlich nicht erfolgt). Neuer Kollege (m/w/d): Das Scrum-Team begrüßt während des Sprints ein neues Teammitglied. Sie vergaßen aber auch, dieses während der Sprintplanung zu berücksichtigen, was zu einer Überforderung des Teams führt. (Es ist natürlich akzeptabel, neue Teamkollegen während eines Sprints aufzunehmen, aber das Team muss während der Sprintplanung den daraus resultierenden Aufwand berücksichtigen und seine Kapazitäten entsprechend anpassen. Das neue Teammitglied sollte keine Überraschung sein. Wenn sich der Zugang jedoch als Überraschung herausstellt, handelt es sich um ein organisatorisches Anti-Pattern; Scrum Master übernehme Sie.) Variable Sprintlänge: Das Scrum-Team dehnt die Sprintlänge um einige Tage aus, um das Sprint-Ziel zu erreichen. (Dies ist nur eine weitere Möglichkeit, die agilen Bücher zu frisieren, um ein Ziel oder eine Metrik zu erfüllen. Man höre auf, sich selbst zu belügen, und spreche die zugrunde liegenden Probleme an, warum das Scrum-Team das Sprint-Ziel nicht erreicht hat. Anmerkung: Ich würde eine abweichende Sprintdauer während der Ferienzeit am Jahresende nicht als Anti-Pattern betrachten. Sprint Anti-Patterns des IT Managements Alle Mann an Deck — aber ohne Scrum: Das Management gibt Scrum in einer kritischen Situation vorübergehend auf. (Dies ist eine klassische Manifestation des Zweifels an agilen Praktiken, die sich aus dem Command & Control-Denken speist. Mit hoher Wahrscheinlichkeit würde auch die Absage eines Sprint und die Refokussierung der Scrum-Teams das vorliegende Problem lösen.) Neuzuweisung von Teammitgliedern: Das Management weist regelmäßig Mitglieder eines Scrum-Teams einem anderen Team zu. (Scrum kann nur dann sein Potenzial voll ausschöpfen, wenn die Teammitglieder untereinander Vertrauen aufbauen können. Die Langlebigkeit der Teams ist daher von entscheidender Bedeutung. Das Versetzen von Mitarbeitern zwischen Teams spiegelt im Gegensatz hierzu eine projektorientierte Managementphilosophie wider, die in der Nutzungsoptimierung des industriellen Paradigmas verwurzelt ist. Sie ignoriert auch die bevorzugte Teambildungspraxis: Scrum-Teams sollten sich selbst auswählen, alle Mitglieder müssen freiwillig in einem Scrum Team sein. Scrum funktioniert nicht, wenn es Teammitglieder aufgezwungen wird. Anmerkung: Es ist jedoch kein Anti-Pattern, wenn die Scrum-Teams beschließen, ihre Teamkollegen vorübergehend untereinander auszutauschen. Es ist eine etablierte Praxis, dass Spezialisten auf diese Weise Wissen verbreiten oder anderen Kollegen helfen. Eine weitere Spielart dieser autonomen Teambildung ist das Dynamic Reteaming.) Spezialkräfte: Ein Manager weist bestimmte Aufgaben direkt den Entwicklern zu und umgeht so den Product Owner und ignoriert das Vorrecht der Entwickler, sich selbst zu organisieren. Alternativ nimmt der Manager einen Entwickler aus einem Team heraus, damit dieser an einer anderen Aufgabe für ihn arbeiten kann. (Dieses Verhalten verstößt nicht nur gegen zentrale Scrum-Prinzipien. Es weist auch darauf hin, dass der Manager die alten Command- und Control-Praktiken nicht aufgeben mag. Er oder sie fährt fort, Untergebene zu bevormunden, obwohl ein Scrum-Team die Aufgabe auf selbstorganisierte Weise erledigen könnte. Dieses Verhalten zeigt ein Maß an Unwissenheit, das möglicherweise die Unterstützung des Scrum-Masters durch eine höhere Führungsebene erfordert.) Sprint Anti-Patterns der Interessenvertreter oder Stakeholder Entwickler direkt ansprechen: Die Interessenvertreter versuchen, kleine Aufgaben in den Sprint zu schleusen, indem sie diese direkt den Entwicklern vorschlagen. Jedes Feature ist ein Bug: Die Interessenvertreter versuchen, die Lieferung ihrer Anliegen zu beschleunigen, indem sie ihre Aufgaben als „ernsthafte Fehler“ bezeichnen. (Ein Sonderfall ist eine „Express-Spur“ für Fehlerbehebungen und andere dringende Probleme. Meiner Erfahrung nach wird jeder Beteiligte irgendwann versuchen Anforderungen in diese „Express-Spur“ zu bekommen). Schlussfolgerung Obwohl der Sprint selbst nur ein Container für alle anderen Scrum-Events ist, gibt es eine Menge Sprint-Anti-Patterns zu beobachten. Viele von ihnen sind vom Scrum-Team oder dem Scrum-Master leicht zu beheben. Einige Sprint-Anti-Patterns weisen jedoch auf organisatorische Probleme hin, deren Änderung wahrscheinlich mehr als eine Sprint-Retrospektive erfordern wird. Welche Sprint-Anti-Patterns fehlen? Bitte teilen Sie uns diese in den Kommentaren mit. ✋ Nicht versäumen: Werden Sie Mitglied im 11.000-köpfigen „Hands-on Agile“ Slack Team 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. Die Wiederholung des Sprint-Anti-Patterns Webinars Es gibt zu dem Thema ein englischsprachiges Webinars an: {"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/BfUxdqW0GOs.jpg?itok=8JhUVk02","video_url":"https://youtu.be/BfUxdqW0GOs","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} Anmerkung: Falls der Browser das Video nicht automatisch startet, klicken Sie hier, um die Wiederholung des Webinars direkt auf Youtube anzusehen. Weitere Artikel 28 Product Backlog Anti-Patterns 21 Sprint Retrospektive Anti-Patterns 20 Sprint Planning Anti-Patterns All Posts on Scrum Anti-Patterns Download the Scrum Anti-Patterns Guide for free

Spesso in formazione si discutono le differenze fra metodologia e framework. In questo articolo troverete la risposta alla domanda: "Perché Scrum non è una metodologia?"

TL; DR: The Scrum Master Salary Report 2022 — How Do You Compare? The Scrum Master Salary Report 2022 is the third edition of the industry survey after 2017 and 2019. This free report is based on the answers of 1,113 participants globally. If you are considering a career decision this year, maybe, whether you should join the industry as a junior Scrum Master or move to a new organization or go independent, you will find the report’s information beneficial. By the way, the average salary of the participants in the survey is $83,687, with a standard deviation of about $48,700. In the complete report, you will find more detailed information; download your copy below. Moreover, we are considering creating a statistical model to suggest further career steps: The “Scrum Master Salary Toolkit.” 🗳 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 34,000-plus subscribers. 🎓 Join Stefan in one of his upcoming Professional Scrum training classes! Download the Scrum Master Salary Report 2022 Download your free copy of the Scrum Master Salary Report 2022 here and compare where you stand: Download the 2019 edition here: Scrum Master Trends Report 2019 Download the 2017 edition here: Scrum Master Salary Report 2017 A Brief Summary of the Findings of the Scrum Master Salary Report 2022 How We Collected the Data, Demographics, Experience We collected the data for the 2022 edition from September 2021 to December 2021. Overall, 1,113 Scrum Masters and agile coaches participated in the survey. To gather the contributors’ answers, we employed an online questionnaire administered via Google Forms. The main acquisition channel was the Food for Agile Thought newsletter. Additionally, we distributed the survey link via blog posts and various social media postings. The participants are 64.3 % male and 34.5 % female. Most of the participants are between 30 and 39 years old (40.9 %) or between 40 and 49 years old (30.7 %.) Another 16.9 % belong to the age group between 50 and 59 years. Most of the participants of the Scrum Master Salary Report 2022 either have practical experience of more than four years (50.5 %) or at least two to four years (31.2 %). In addition, they indicated significant transition experience (67.2 %), and at least 52.0 % of them experienced or initiated a transition kickoff. Among our participants were 70 % Scrum Masters and 30 % Agile Coaches, 92.2% of them employed directly at the respective organization. The participants` tenure level was more or less evenly distributed among the four categories “less than one year” (32.5 %), “one to two years” (19.9 %), “two to four years” (22.4 %), and “more than four years” (25.2 %.) Certifications and Experience Have Significant Impact on the Remuneration Your salary increases with the number and sophistication of the certificates you obtain. The median difference between having no certification and having at least an entry-level certification, for example, the PSM I, is as much as $15,000 annually. Advanced certificates, for example, the PSM II, and additional qualifications such as SCM, ICP-ACC, PMI-ACP add up to another $19,000 annually to your paycheck. Unsurprisingly, the salary also increases as Scrum Masters and agile coaches gain experience and reach intermediate and senior levels. From our point of view, what is surprising is the median difference between junior-level income and senior-level income. A difference of roughly $40,000 is a valid argument to cope with the troubles that may stress you in your day-to-day business. We also want to highlight that the more senior you become, the higher the salary distribution spreads. Toward a Scrum Master Salary Toolkit Taking a step back and looking at our analyses, we wondered how we could improve the value for our readers. One size doesn’t fit all, and what you can and cannot achieve—financially speaking—heavily depends on your current situation and your specific profile. Therefore, we want to go beyond group comparisons. In preparation for future reports, we experimented with our dataset and investigated if it could point to a salary pathway or a Scrum Master salary toolkit. The toolkit should allow you to calculate your salary considering your specific characteristics and identify relevant “next steps” to increase your salary significantly. Learn more about the Scrum Master salary toolkit in the report. The Conclusion What are the most interesting findings of the Scrum Master Salary Report 2022? My pick is as follows: For Scrum Masters and agile coaches, hands-on experience trumps a Ph.D. concerning your career. Continuing your education in the form of earning industry-acknowledged certificates pays well. Your previous work experience impacts your remuneration as Scrum Master or agile coach. The average salary of the participants in the survey is $83,687, with a standard deviation of about $48,700. We might be able to create a statistical model to suggest further career steps: The “Scrum Master Salary Toolkit.” If you found the Scrum Master Salary Report 2022 useful, please consider forwarding it to a friend or colleague. ✋ Do Not Miss Out and Learn more about the Scrum Master Salary Report 2022 — 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. 📖 Related Articles Hiring: 60 Scrum Master Interview Questions To Avoid Agile Imposters Peer Recruiting: How to Hire a Scrum Master in Agile Times Scrum Master Trends Report 2019 Scrum Master Salary Report 2017 Download the ’Scrum Anti-Patterns Guide’ for Free 🎓 Do You Want more like this? Well, then: 📰 Join 34,017 peers and sign-up for my weekly newsletter 📅 Join 4,000-plus peers of the Hands-on Agile Meetup group 🐦 Follow me on Twitter and subscribe to my blog Age of Product 💬 Alternatively, join 11,000-plus peers of the “Hands-on Agile” Slack Community for free.