Da ich bereits „Scrum Master“ bin, dachte ich, ich wäre bereits ein guter Facilitator.

Was ist Product Backlog Refinement? Scrum Teams machen es ständig. Es passiert im Sprint Review, nach dem Daily Scrum, im Sprint Planning und als Teil der Entwicklung. Sie diskutieren über die bevorstehende Arbeit, um sie zu präzisieren.

Eine lineare, schrittweise Abfolge von Änderungen — in der Regel durchgeführt von funktional getrennten Abteilungen — ist völlig unvereinbar mit der Änderungsgeschwindigkeit und Komplexität moderner Softwareprodukte.

In jedem Professional Scrum Product Owner Training werden die gleichen 10 Fragen gestellt. Und das zu Recht! Das sind die Dinge, mit denen die Teilnehmer am meisten zu kämpfen haben.

Wie können Scrum Teams in ihrer Entwicklungsarbeit den Nutzer niemals aus dem Auge verlieren? Hier 3 einfache Praktiken, die sie von YouTube, LinkedIn, Microsoft lernen können.

Über 100 Jahre Industriezeitalter haben uns gelehrt, dass die Lieferung von Produkten den Erfolg eines Unternehmens bestimmt.

Wann ist das Feature fertig? Diese legitime Frage, die Stakeholder im Sprint Review stellen und welche regelmäßig Mitglieder des Scrum Teams zusammenzucken lässt, sollte jeder erfahrene Product Owner beantworten können.

Hier mein bewährtes Rezept, wie Product Owner das Sprint Review zu einem gemeinschaftlichen Arbeitstermin machen können und nicht zu einer Demonstration, Präsentation oder Feature-Abnahme verkommen lassen.

Eine bewährte Anleitung, wie Du als angehender Product Owner ein Sprint Planning in Jira durchführst

German blog on 5 lessons that I learned in the first year as a product owner that can save you a lot of time and frustration

Hochperformante Teams, die vorhersagbar liefern, tragen maßgeblich zum Erfolg von Unternehmen bei.

Das Problem mit Features ist, dass sie fertiggestellt und ausgeliefert werden sowie perfekt funktionieren, aber dennoch keinen Wert liefern können.

Häufiges Feedback ist der Motor, meine Schulungen ständig zu verbessern.

Scrum Teams entwickeln eben nicht nur Produkte und Services, sondern betreiben diese auch. Ohne den Betrieb einer Anwendung ist es unmöglich, Feedback zu erhalten. Allerdings ist Feedback essenzielle für erfolgreiche Scrum Teams, da es die Triebfeder ist, um Nutzer- und Kundenwünsche zu erfüllen. Beim Betrieb von Produkten und Services kommt es zwangsläufig zu ungeplanter Arbeit. Fehler treten auf, Nutzer geben Feedback, Kunden brauchen Support und Notfälle treten ein.

Scrum of Scrums describes one of the first approaches to scale Scrum and is often confused with Nexus Daily Scrum.  

In this blog post, we discuss how team size and organization can be considered when scaling Scrum.

How effectively a Nexus works depends on its ability to eliminate dependencies. Eliminating dependencies simplifies integration. Scrum Masters who efficiently perform cross-team refinements save time. Saving time saves money. 

When scaling Scrum, we balance cost and effort with benefits and advantages. Costs and effort come from adding teams. Benefits and advantages come from delivering more value in the same amount of time. 

Organizations need to move fast and receive ongoing feedback from customers to drive sustainable innovation through continuous discovery and value delivery. But there is a problem — dependencies.

Scrum Teams do it all the time. It happens in Sprint Review, after Daily Scrum, in Sprint Planning, and as part of development. They discuss the upcoming work to gain a shared understanding...

Sind mehrere Product Owner nötig, um Scrum effektiv zu skalieren? Nein.  Dass in skalierter Produktentwicklung mehrere Product Owner von Nöten sind, ist ein weit verbreiteter Irrglaube. Dieser Beitrag räumt mit diesem Irrglauben auf. Wird die Product Owner Rolle durch mehrere Personen skaliert, führt es zu Wertminimierung, steigendem Risiko und unnötiger Verlängerung der Time to Market. Es ist somit eine ineffektive Art, Product Ownership zu skalieren.

Der Nexus Guide -- der Leitfaden zur Skalierung von Scrum -- wurde aktualisiert! Der Nexus Guide 2021 enthält weniger Vorschriften, Erklärung von spezifischer Terminologie und einen Ergänzender Theorieabschnitt.

Ja. Dieser Artikel erklärt dir warum und was du dagegen unternehmen kannst. 

Heute, am 18. November 2020, pünktlich zum 25. Geburtstag von Scrum, haben Ken Schwaber und Jeff Sutherland den Scrum Guide aktualisiert.  Um eines gleich vorwegzunehmen: Scrum bleibt Scrum. Ein einfaches Rahmenwerk, welches es Teams ermöglicht, mit der Arbeit an komplexen Problemen zu beginnen. Und der Scrum Guide 2020 ändert daran nichts.  Einige Dinge sind jedoch neu und denen widmen wir uns jetzt. 

In meinen Professional Scrum Master Trainings beantwortet ein Großteil der Teilnehmer diese Frage mit: “Hoffentlich so früh wie möglich, denn als Scrum Master ist es unsere Aufgabe uns selbst überflüssig zu machen.” Haben Sie damit Recht? 

Im skalierten Scrum finden die Daily Scrums der Scrum Teams nach dem teamübergreifenden Nexus Daily Scrum statt! Handelt es sich hierbei um einen Scrum Mythos oder Fakt?

Scrum Master aufgepasst! Der Sprint beginnt nach dem Sprint Planning. Handelt es sich hierbei um einen Scrum Mythos oder Fakt?

Was denkst Du, handelt es sich hierbei um einen Mythos oder um einen Fakt? Die Antwort erfährst Du in meinem Scrum Mythen und Fakten Check.

Der Scrum Master muss beim Daily Scrum anwesend sein!