Diskussion:Scrum

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Scrum“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Zum Archiv

Automatische Archivierung

Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 365 Tage zurückliegt und die mindestens 3 signierte Beiträge enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleibt mindestens ein Abschnitt.

Grundsätzliche Überarbeitung

Dieser Artikel enthielt viele zweifelhafte Stellen. Ich habe daher den Artikel heute grundsätzlich überarbeitet, um die Darstellung mit dem aktuellen Stand der Scrum-Technik (Scrum Guide/Agile Atlas) abzugleichen. Dabei habe ich die hier in der Diskussion aufgelisteten Punkte bearbeitet:

• #Bezug zum agilen Mainfest - ist korrekt, steht auch im Agile Atlas
• #Erfahrung dass die meisten modernen Entwicklungsprojekte zu komplex sind - Begründung formuliert, warum Scrum die Komplexität besonders wirtschaftlich adressiert
• #Daily Scrums - korrekt lt. Agile Atlas & Scrum Guide: ist für das Entwicklungsteam
• #Rollen - Diese Kritik war berechtigt, Scrum kennt nur drei Rollen. Daher habe ich die Rollen auf die drei Scrum Rollen reduziert. Die anderen Rollen habe ich zur Erklärung des Begriffs Stakeholder verwendet.
• #Artefakte - Diese Kritik war berechtigt. Jetzt stehen die korrekten Artefakte im Artikel.
• #Userstory fehlt - Abschnitt "Techniken" aufgenommen und User Story hierher verschoben, zusammen mit anderen Techniken die verstreut im Artikel standen
• #Sprint Textdoppelung - Textdoppelung beseitigt, Sprint neu formuliert.
• #Sekundärliteratur in den Verweisen und #Scrum Guide vs. Gloger - Bei der Überarbeitung habe den Agile Atlas und den Scrum Guide als Referenz genommen, da sie den "Stand von Scrum" definieren. Dieser Artikel reflektiert jetzt, was in der Scrum Community als "Scrum" definiert wird.
• #Letzter Absatz über das Entwicklerteam: Interdisziplinäre Urlaubsvertretung - habe ich so gelassen, inhaltlich stimmt das, kann man bestimmt besser formulieren, war aber jetzt nicht das #1 backlog item bei mir
• Ansonsten habe ich viele weitere Stellen korrigiert (z.B. Product Owner gehört zur Retrospektive dazu, Scrum ist kein Vorgehensmodell, Scrum ist nicht nur für die Softwaretechnik, ...etc.)

--Malte Foegen (Diskussion) 15:00, 29. Jun. 2014 (CEST) (seines Zeichens CST)

Bezug zum agilen Mainfest

Im Artikel steht: "Scrum verkörpert die Werte des Agilen Manifests, das Menschen und deren Interaktionen vor Prozesse und Werkzeuge stellt." Wie soll das denn bitte funktionieren? Scrum definiert Prozesse und Werkzeuge. Das agile Manifest sagt in diesem Zusammenhang: Scrum ist wichtig, aber die Menschen und Interaktionen sind wichtiger. Meines Erachtens ein sehr wichtiger Punkt, der beim "blinden Anwenden" von Scrum in der Praxis gerne vergessen wird. Weiter unten im Artikel werden alle 4 Punkte des A.M. aufgeführt. Auch Punkt 2 hat nicht das geringste mit Scrum zu tun. Schließlich könnte man auch die Erstellung von Dokumentation mit Scrum durchführen. Wenn keine Einwände bestehen, würde ich also diese Abschnitte entfernen, zumal keine Quellenangaben vorhanden sind. --217.24.207.26 10:52, 27. Dez. 2011 (CET)

Dass Scrum die Werte des Agile Manifests verkörpert, dafür lassen sich jede Menge Belege finden. Einen davon habe ich jetzt als Referenz beigebracht. Das gilt auch für Dokumentation - viele der agilen Techniken, die auch in Scrum empfohle werden reduziere die Dokumentation - vergleiche nur mal eine Storymap mit einem Pflichtenheft. Und natürlich hast du recht - in der Praxis wird Scrum oft wie Cargo-Kult betrieben - da bleibe die Werte von Scrum meist auf der Strecke. --Sebastian.Dietrich ✉ 20:49, 31. Okt. 2013 (CET)

Rollen

Scrum definiert nicht(!) sechs, sondern lediglich drei Rollen:

- Product Owner
- Scrum Master
- Team

Die in diesem Artikel weiter aufgeführten Rollen (Customer, User, Manager) sind für die Softwareentwicklung natürlich relevant, haben mit Scrum direkt aber erst mal nichts zu tun.
Auch im offiziellen Scrum Guide (http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20-%20DE.pdf) werden diese Rollen nicht behandelt. (nicht signierter Beitrag von Spezial:Beiträge/Dutze (Diskussion) 13:05, 16. Aug. 2012 (CEST))

Artefakte

Die Auflistung der Artefakte ist nicht korrekt. Laut Scrum Guide existieren folgende drei Artefakte:

- Product Backlog
- Sprint Backlog
- Inkrement

Im Artikel fehlt das Artefakt "Inkrement", dafür sind folgende aufgelisteten Artefakte keine Artefakte nach Scrum-Definition:

- Definition of Done
- Impediment Backlog
- Burn Down Charts

Siehe auch Scrum Guide (http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20-%20DE.pdf). (nicht signierter Beitrag von Spezial:Beiträge/Dutze (Diskussion) 13:05, 16. Aug. 2012 (CEST))

Userstory fehlt

Im Text wird an nicht erwähnt was "User-Stories" sind. Wenn man mit Scrum vertraut ist, weiß man das zwar, aber für jemandem, der es nichts ist, wird es auch nicht aus dem Text ersichtlich, was genau eine Userstory ist. --2A00:1398:2:8022:221:9BFF:FE58:8417 16:05, 5. Nov. 2012 (CET)

Zur User Story gibt es ein eigenes Lemma, auf das auch verlinkt wird. Der folgende Abschnitt steht in der Einleitung und sollte m.M.n. auch ausreichend sein: Die Umsetzung der Vision in das fertige Produkt erfolgt nicht durch die Aufstellung möglichst detaillierter Anforderungslisten (vgl. Lastenheft/Pflichtenheft), die dann phasenweise umgesetzt werden, sondern durch das Ausformulieren von klaren Funktionalitäten aus der Anwendersicht, die dann in zwei bis vier Wochen langen, sich wiederholenden Intervallen, sogenannten Sprints iterativ und inkrementell umgesetzt werden. Diese Anforderungen aus Anwender-Sicht werden meist als User Stories bezeichnet um Lasten-/Pflichtenhefte zu ersetzen. Das ließe sich vielleicht noch knackiger und treffender formulieren, aber viel mehr Details brauchen da eigentlich nicht rein, denk ich. --Hamburger (Disk) 16:23, 5. Nov. 2012 (CET)

Anti-Innovative Vorgehensweise

Mal ehrlich: Wer von Euch hat nicht schon eine Idee gehabt und innert ein paar Tage oder Wochen einen Prototypen gebaut, nur um danach 3/4 des Codes zu streichen und ein super Endresultat zustandebringen? Aber wie soll so was mit Scrum noch möglich sein, wenn mir alle in den Code quatschen?? Programmieren ist kein Jekami, es ist was zwischen Mensch und Maschine, und man benötigt viel Unabhängigkeit um gute Ideen in Code umzusetzen. Scrum kann man auch in der Kaffeepause tun, sofern man ausnahmsweise mal dazu kommt. Oder meint Ihr echt, Microsoft Office 1.0 oder Google oder Facebook wären durch Scrum zustandegekommen? Also...ECHT jetzt! PS: Scrum ist weder ein Framework noch Prozess, und auch keine Datenstruktur, sondern eine Methodik ;D...meiner Meinung nach eine quälend schlechte Methodik - um nicht zu sagen "Vergewaltigung". Einwand: Für Programmieranfänger oder schlechte Programmierer ist es aber sicherlich was Gutes! --178.197.234.15 23:44, 12. Nov. 2012 (CET)

Bitte zuerst den Artikel lesen & dann erst Senf dazu geben. Scrum != Collective Code Ownership. Deine Ansichten bezüglich Softwareentwicklung sind übrigens ziemlich veraltet. Keine größere Software wird heute noch so entwickelt wie du es dir vorstellst ("Programmieren = was zwischen Mensch und Maschine mit viel Unabhängigkeit einzelner Programmierer"). --Sebastian.Dietrich ✉ 08:45, 13. Nov. 2012 (CET)

Sprint Textdoppelung

Der Text bei Sprint beschäftigt sich einen großteil mit dem ScrumMaster und daher doppeln sich die Infos bzw sogar die ganzen Abschnitte und gehören nicht in den Sprint. --Terraloader --93.214.239.157 10:54, 20. Mär. 2013 (CET)

Das ist an mehreren Stellen so, z.B. ein ausführlicher Vorgriff auf das Planning 1 beim Team. Ich habe mal angefangen, die Dopplungen zu entfernen.--Philipp Sªsse (Diskussion) 06:50, 18. Jan. 2014 (CET)

Sekundärliteratur in den Verweisen

In den Einzelnachweisen findet sich oft Referenzen auf ein einzelnes Buch (Boris Gloger 2011: Scrum. Produkte zuverlässig und schnell entwickeln), leider sehr wenig Verweise auf die wichtigere Primärliteratur zu dem Thema (siehe "Scrum (Development)" auf englisch). Dadurch kommt es zu einer bestimmten, einseitigen Gewichtung der Themen. Der Artikel sollte deshalb grundsätzlich überarbeitet werden und sich im Detail auf andere Quellen beziehen. --Holger.Bohlmann (Diskussion) 00:04, 30. Apr. 2013 (CEST)

Übersetzung von "Burndown"

Gibt es zu "Burndown" eine übliche / mögliche / sinnvolle Übersetzung? --Peter2 (Diskussion) 19:50, 19. Aug. 2013 (CEST)

abbrennen/niederbrennen --217.231.22.172 16:28, 4. Jan. 2016 (CET)

Zertifizierung

Auf das Thema wird in dem Artikel gar nicht eingegangen. Eine entsprechende Erweiterung für Interessierte (wie mich) ist aber wichtig. --Morphelianus (13:49, 10. Sep. 2013 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Letzter Absatz über das Entwicklerteam: Interdisziplinäre Urlaubsvertretung (erl.)

Im Abschnitt über das Entwicklerteam gibt es so einen philosophierenden Absatz ohne Quellen, der für mich auch nicht überall schlüssig ist. Z. B. »Und fällt jemand aus privaten Gründen für einige Zeit aus, ist ein interdisziplinär aufgestelltes Entwicklungsteam besser in der Lage, die fehlende Expertise zu kompensieren.« ist doch Quatsch. Gerade eine Vertretung ist in einem Team mit engem Fokus viel einfacher. Je mehr verschiedene Aufgaben das Team erfüllen muss (Architektur, Implementierung, Infrastruktur, Testen, Dokumentieren), desto schwieriger wird es, für jede Aufgabe auch noch einen geeigneten Vertreter zu finden. Aber da der ganze Absatz nicht nur lausig ist, sondern auch für jedes Team unabhängig von Scrum gilt, würde ich ihn einfach komplett streichen. Okay?--Philipp Sªsse (Diskussion) (07:22, 18. Jan. 2014 (CET), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Hallo, Philipp Sªsse, "aus privaten Gründen" ist auf jeden Fall überflüssig. Ansonsten finde ich das OK: Je interdisziplinärer ein Team ist, desto eher kann einer den anderen im Team ersetzen. Natürlich hast du Recht, dass es nicht leicht ist, diese Interdisziplinarität zu erreichen. Grüße, --Schotterebene (Diskussion) 09:47, 18. Jan. 2014 (CET)

Prozess-Grafik

Die Prozess-Grafik im Abschnitt "Aktivitäten" finde ich keine besonders geglückte Darstellung. Zwei Kritikpunkte: Was zeigt sie bei einer unvoreingenommenen (nicht schon scrum-vorgebildeten) Betrachtung: 1) Erst am Schluss - ganz rechts am Prozessende dargestellt - kommt ein dickes Packet Software heraus. 2) Nach ca. Zweidritteln der 30-Tage-Wiederholungsschleife (also nach ca. 20 Tagen) findet eine 24 h Wiederholungsschleife statt (ja, ich weiß, dass dies nicht gemeint ist; die Frage ist, was ist hier dargestellt; wenn ich im Bild wiederfinden muss, was ich eh schon weiß, brauche ich keine grafische Darstellung). --Bri B. 17:23, 25. Sep. 2014 (CEST)

Artikel überarbeitet

Insgesamt ein interessanter, umfassender Artikel, der m. E. gut die Leitgedanken und wesentlichen Elemente erklärt. Allerdings fand ich ihn etwas weitschweifig. Deshalb bin ich im Begriff, ihn zu überarbeiten:

• Streichen von Paraphrasen und Selbstverständlichkeiten. Scrum setzt auf die Intelligenz und Organisationsfähigkeit der Beteiligten, dasselbe dürfen wir auch beim Leser voraussetzen. ;-)
• Zurückstutzen von Füllwörtern und Adjektiven.
• Der Artikel schwelgt im Jargon. Das führt zu Konflikten mit den Rechtschreibregeln; besonders wimmelt es von Leerzeichen in Komposita. Ich setze die englischen Begriffe kursiv und bei den deutschen Komposita Bindestriche.
• An einingen Stellen korrigiere ich die grammatische Bezüge, Genitive und andere Kleinigkeiten.

Gruß aus Freiberg am Neckar, --Mussklprozz (Diskussion) 11:20, 20. Dez. 2014 (CET)

Hallo Mussklprozz, ja, deine Vorschläge sind gut. Grüße, --Schotterebene (Diskussion) 11:35, 20. Dez. 2014 (CET)

Ziel nicht erreichbar

Laut Artikel ist das Ziel von Scrum "die schnelle und kostengünstige Entwicklung hochwertiger Produkte". Laut https://en.wikipedia.org/wiki/Project_management_triangle#.22Pick_any_two.22 geht das aber gar nicht.

Das Dreieck dort (fast, quality, cheap) und auch das mMn bekanntere scope, time, quality Dreieck bezieht sich immer auf die _Vorgabe_ dieser Variablen - d.h. man kann nicht Produkte erzeugen, bei denen man alle 3 Variablen vorgibt.

Scrum und die anderen agilen Methodiken geben nur "Quality" vor ("potentially shippable"), die anderen Dinge ergeben sich im Laufe des Projektes. Scrum unterstützt dabei, dass die Geschwindigkeit hoch & in der IT somit die Kosten gering sind und dass der Scope dem entspricht was tatsächlich benötigt wird. Insoferne ist das Ziel von Scrum "die schnelle und kostengünstige Entwicklung hochwertiger Produkte" tatsächlich erreichbar & wird auch oft insofern erreicht, als Scrum Projekte oft schneller, kostengünstiger, hochwertigere Produkte entwickeln als andere Projekte. --Sebastian.Dietrich ✉

Verstehe. Wenn ich also ein Auto haben will, das in 50 Jahren noch fährt ("Qualität"), gibt mir Scrum 300 km/h Spitze und 3 l/100 km frei Haus dazu ("ergeben sich im Laufe des Projekts"). Wenn ich aber Geschwindigkeit und Sparsamkeit von vornherein auch fordere, bekomme ich nicht alles (wegen des Dreiecks). Also ist Scrum mehr ein psychologischer Trick.

Jein - es ergeben sich natürlich nur Dinge, die auch mit den gegebenen Mitteln machbar sind. Die gegebenen Mittel sind vor Projektstart größtenteils nicht bekannt. Und es ergeben sich im Idealfall genau die Dinge (scope), die du benötigst, weil du während des Projektes erst erkennen kannst, was du wirklich brauchst.

Wenn du von vornherein 50/300/3l forderst bekommst vermutlich am Ende nur eine Spezifikation. Wennst mit Scrum 50 forderst, bekommst vermutlich 50/180/22kWh (weil du im Laufe des Projektes draufkommst, dass man eh nirgendwo 300km fährt und du mit Strom billiger fährst). --Sebastian.Dietrich ✉ 12:24, 29. Jan. 2015 (CET)

Zitat: "Insoferne ist das Ziel von Scrum "die schnelle und kostengünstige Entwicklung hochwertiger Produkte" tatsächlich erreichbar & wird auch oft insofern erreicht, als Scrum Projekte oft schneller, kostengünstiger, hochwertigere Produkte entwickeln als andere Projekte." Nein. Das "Scrum Projekte oft schneller, kostengünstiger, hochwertigere Produkte entwickeln als andere Projekte" ist nichts weiter als eine unbelegte Behauptung.

Mehrdeutigkeit des Begriffs

Schaut mal hier:

http://de.wikipedia.org/wiki/Gedr%C3%A4nge_%28Rugby%29

Dieses Scrum gibt's schon länger. Was ist zu tun? (nicht signierter Beitrag von 193.158.100.19 (Diskussion) 13:24, 29. Apr. 2015 (CEST))

Nichts - da es den anderen Scrum in der deutschen Sprache nicht gibt. Aber dass der Name vom Scrum aus dem englischen Wort für Gedränge (Rugby) kommt, und nicht "englisch für Gedränge" ist - hab ich mal korrigiert. --Sebastian.Dietrich ✉ 23:24, 29. Apr. 2015 (CEST)

Ich halte das für sachlich falsch. Gemeint ist nicht das Gedränge, das 2 Mannschaften gegeneinander durchführen, sondern das, was wir im Deutschen mit Spielerkreis bezeichnen, wo eine einzelne Gruppe sich gemeinsam einschwört. --77.1.75.73 21:47, 30. Jun. 2024 (CEST)

Änderung der Einleitung

Die IP 94.222.224.237 hat die Einleitung grundlegend geändert. Ich habs wieder zurückgesetzt ([1]). Grundsätzlich würde die Einleitung natürlich eine Verbesserung vertragen - aber vielleicht sollte man das vorher zur Diskussion stellen. Hier der Vorschlag der IP:

Scrum ist eine softwarebasierte Arbeitsumgebung für das Projekt- und Produktmanagement. Mit bestimmten Regeln für das Lean Development (Beleg: Mary Poppendieck, Tom Poppendieck: Lean Software Development: An Agile Toolkit, Addison-Wesley, Upper Saddle River, 2003.)(Beleg: Malte Foegen: Der Ultimative Scrum Guide 2.0, wibas, Darmstadt 2014, S. 50–51.) bildet die Software einen Vorgehensrahmen bzw. -gerüst (Framework) ab und wird daher bewusst nicht als Vorgehensmodell bezeichnet. Der Ansatz von Scrum ist empirisch, inkrementell und iterativ. Er beruht auf der Erfahrung, dass viele Entwicklungsprojekte zu komplex sind, um in einen vollumfänglichen Plan gefasst werden zu können. Ein wesentlicher Teil der Anforderungen und der Lösungsansätze ist zu Beginn unklar. Diese Unklarheit lässt sich beseitigen, indem Zwischenergebnisse geschaffen werden. Anhand dieser Zwischenergebnisse lassen sich die fehlenden Anforderungen und Lösungstechniken effizienter finden als durch eine abstrakte Klärungsphase. In Scrum wird neben dem Produkt auch die Planung iterativ und inkrementell entwickelt. Der langfristige Plan (das Product Backlog) wird kontinuierlich verfeinert und verbessert. Der Detailplan (das Sprint Backlog) wird nur für den jeweils nächsten Zyklus (den Sprint) erstellt. Damit wird die Projektplanung auf das Wesentliche fokussiert. (Beleg: Malte Foegen: Der Ultimative Scrum Guide. wibas, Darmstadt 2014, S. 112–113.). Obwohl Scrum ursprünglich mit dem Focus auf die Entwicklung von Softwaretechnik entwickelt wurde, kann es auch davon unabhängig verwendet werden und wird inzwischen in vielen anderen Bereichen eingesetzt.(Beleg: Scrum Alliance: The State of Scrum, S. 10 (abgerufen am 28. Juni 2014).)

Den Vorschlag der IP halte ich aus folgenden Gründen für ungeeignet/verbessrungswürdig:

• softwarebasierte Arbeitsumgebung ist eindeutig falsch. Scrum geht auch ohne Software
• die erste Ref (Lean Software Development) ohne Seitenangabe belegt nix
• in der Einleitung bereits auf den Begriff "Framework" vs. "Vorgehensmodell" einzugehen halte ich für verfrüht
• Empirisch, inkrementell und iterativ zu nennen ist mMn gut, dann sollten die einzelnen Punkte aber auch als solche erkennbar erklärt werden (z.B. mit Bulltepoints) - so wie vorgeschlagen halte ich es für zu eine lange Wurst...

--Sebastian.Dietrich ✉ 17:48, 15. Jun. 2015 (CEST)

Story points

Im Artikel wird der Begriff "Story Points" zweimal benutzt, ohne erklärt worden zu sein. Könnte das mal jemand vom Fach übernehmen und einfügen? Grüße, --Joschi71 (Diskussion) 13:21, 13. Okt. 2015 (CEST)

SCRUM = Software Capability Rational Unified Model

Es gibt sehr wenige Internetquellen, die SCRUM als Abkürzung von "Software Capability Rational Unified Model" nennen. Kennt jemand eine gute Quelle, damit diese Abkürzung den Weg in den Artikel finden kann?--188.96.190.21 22:27, 21. Nov. 2016 (CET)

Das scheinen wohl einige Begriffe durcheinander gekommen zu sein. Es gibt den gut dokumentierten RUP (Rational Unified Process), das Capability Maturity Model und Scrum (aus der agilen Softwareentwicklung). Es macht keinen Sinn diese zu vermengen und dann unter einem dem ursprünglichen Begriff gleichen Abkürzung zu verwenden. --Oliver Emmler (Diskussion) 20:43, 23. Nov. 2016 (CET)

User Story: Das Beispiel mit dem Fahrrad

„Als 30-jährige Geschäftsfrau möchte ich auf dem Weg zur Arbeit nur wenig in die Pedale treten müssen, damit ich nicht verschwitzt in der Firma ankomme.“ Das ist keine Anforderung an ein Produkt, sondern eine Unzufriedenheit mit sich selbst. Die korrekte Antwort darauf lautet: „Fahren Sie mehr Fahrrad, dann schwitzen Sie auch weniger.“ Wenn das Entwicklungsteam dann noch die Zeit, die es am Schreibtisch sitzend mit dem Entwurf von Elektrofahrrädern verplempert, dazu nutzen würde, selber Fahrrad zu fahren und Fahrradtouren anzubieten, hätten alle etwas sinnvolles getan. (nicht signierter Beitrag von 92.211.58.217 (Diskussion) 10:15, 3. Mär. 2017 (CET))

Grundlage

Wer oder was definiert eigentlich was Scrum ist? Das kommt für mich auf der Seite nicht rüber. Bis heute war ich der Meinung dass der Scrum-Guide hierzu die Referenz ist. Der steht jedoch als nur als einer von vielen Nachweisen da. Freimatz (Diskussion) 13:27, 10. Mai 2017 (CEST)

Einzelnachweise

Einzelnachweis 10. und 26. sind identisch. Evtl. war die Absicht des Autors, die entsprechenden Seitenzahlen aus der Quelle zu ergänzen, was untergegangen ist. Vorschlag: Konsolidieren und Nr. 26 entfernen. --Dr.Xos (Diskussion) 12:40, 9. Sep. 2017 (CEST)

Rechtschreibung

Obwohl der Begriff "Aktivitäten" sich bei Vielen im Kopf so als gebräuchlich festgesetzt hat und vielerorts verwendet wird, ist der Begriff ein Singularetantum wie Milch, Zucker und Glück. Es gibt ihn in der deutschen Sprache nicht im Plural. Hintergrund ist, dass der Begriff "Aktivität" bereits die Definition vieler Aktionen enthält, also selbst schon einen Plural ausdrückt. Die Häufigkeit mit der der Begriff vielerorts falsch im Plural verwendet wird, macht den falschen Plural nicht richtig. Nur eine freundliche Anregung, ohne viel Hoffnung auf Umsetzung. Herzliche Grüße, Christel Thiel

Sept18 https://www.duden.de/rechtschreibung/Aktivitaet Der Duden kennt die Aktivität auch das auch im Plural

Sprintabbruch

Laut dem Absatz über den Sprint ist ein Abbruch gerechtfertigt, wenn das Sprintziel nicht mehr erreicht werden kann. Das ist falsch. Richtig ist, dass der Sprint abgebrochen werden kann, wenn das Sprintziel obsolet geworden ist.

Entwickele ich zum Beispiel ein Feature, welches die Verwaltung von rosa Einhörnern ermöglicht, und während des Sprints wird nachgewiesen, dass es keine Einhörner gibt, ist das Sprintziel (Verwaltung von Einhörnern) obsolet und die Fortführung des Sprints macht keinen Sinn mehr.

Werde ich allerdings in dem Sprint mit dem Feature nicht fertig, führe ich die Arbeit bis zuletzt fort und versuche mit allen zur Verfügung stehenden Mitteln, das Sprintziel dennoch zu erreichen.

"Übrig" gebliebene Arbeit wird im Sprintplanning neu priorisiert und geplant.

Ich würde den letzten Absatz des Abschnittes "Sprint" also gerne wie folgt formulieren:

Ein Sprint kann vom Product Owner abgebrochen werden, falls das Sprintziel nicht mehr verfolgenswert ist. Dies ist in den allermeisten Fällen nur sinnvoll, wenn sich die Domäne grundlegend verändert hat. In diesem Fall wird der aktuelle Sprint mit einer Sprint-Retrospektive beendet und der neue Sprint ganz normal und ohne Verzögerung mit dem Sprint Planning begonnen. Ein Beispiel für einen Sprintabbruch wäre es, wenn das Sprintziel lautete "Anpassung an Gesetzesvorlage XY" und eben diese Gesetzesvorlage dann nicht umgesetzt würde.

Verhältnis Product Owner -> Entwicklungsteam

Der Artikel sollte deutlicher darauf hinweisen, dass die Produktentwicklung nach Scrum rein auf Kulanz basiert. Der Product Owner hat kein Direktionsrecht gegenüber dem Entwicklungsteam, kann also lediglich Wünsche äussern. Ob das Enwicklungsteam diese tatsächlich umsetzt, hängt wesentlich davon ab, wie gut er sich mit ihm stellt. Manch ein Product Owner vergisst das gerne einmal. Edit: Hier wird eine Literaturliste angezeigt. Die kommt nicht von mir. Kann sie aber auch nicht wegeditieren.

Verwendung von User-Story

Im Text wird teilweise noch der Begriff User-Story verwendet. Das ist aus zwei Gründen problematisch. Zum einen wird der Begriff erst hinterher erklärt. Zum anderen wird bei der Erklärung darauf hingewiesen, dass User-Stories nur ein Weg zur Beschreibung von Anforderungen sind und selbst auch gar nicht zum Scrum Framework gehören. Im Text wird der Begriff aber äquivalent zu Anforderungen verwendet, was ja eben nicht so ist. Vielleicht kann das jemand mit mehr Wissen auf dem Gebiet korrigieren. Zusätzlich könnte es bei anderen Wörtern ähnliche Probleme geben, das weiß ich aber nicht mehr. --Claell (Diskussion) 15:11, 14. Sep. 2018 (CEST)

Aktivitäten nicht korrekt

Bei den Aktivitäten fehlt der Sprint als Aktivität an sich. Das statt dessen genannte Product Backlog Refinement ist eigentlich nur ein Teil des Sprints und sollte daher wenn dann als Teil-Aktivität des Sprint genannt werden. Als Quelle hierfür kann scrum.org und der dort zur Verfügung gestellte Scrum Guide(TM) genutzt werden.

Soll ein neuer Artikel für den neuen Scrum Guide November 2020 erstellt werden?

Denn ansonsten müsste viel überarbeitet werden. Einige der wichtigsten Änderungen:

• Development team -> Developers (da auch andere Industrien als die IT so besser abgeholt werden können)
• Vision -> Product Goal ist neu
• Release gibt es nicht mehr
• Canceling a sprint war umfangreich, jetzt sind es weniger als 1,5 Zeilen
• Artefakte -> commitments: Product Goal, Sprint Goal, Definition of Done
• Beginne mit “warum”: Warum ist dieser Sprint wertvoll? --Bernburgerin (Diskussion) 19:19, 18. Nov. 2020 (CET)

Nein sicher kein neuer Artikel. Darüber hinaus ist der Scrum Guide nicht DIE Srum "Wahrheit", sondern nur ein Player von vielen. D.h. man könnte versuchen die Ansichten des Scrum Guides in den Artikel einfließen zu lassen, aber ohne die anderen (bestehenden) Sichten rauszulöschen. --Sebastian.Dietrich ✉ 10:48, 19. Nov. 2020 (CET)

"*Development team -> Developers (da auch andere Industrien als die IT so besser abgeholt werden können)" Hier soll niemand "abgeholt" werden. Es geht darum präzise Begriffe zu finden die beschreiben was Scrum ist. "Developer" ist kein guter, denn es ist ein unnötiger Anglizismus der nur verwirrt. "Software-Entwickler" oder "Team-Mitglieder" könnte z.B. Sinn machen. Man braucht etwas das allgemeine Verständlichkeit besitzt und nicht bloß in der Scrum-Welt einen Sinn ergibt. Zirkuläre Definitionen die Begriffe einer Selbstdefinition aneinanderreihen bringen nichts. "Der Scrum-Master ist eine dienende Führungskraft der Developer im Sprint und verantwortlich für die Einhaltung der Scrum-Regeln". Sowas ist eine Null-Aussage. Bereits was eine "dienende Führungskraft" sein soll, ist alles andere als klar, und der Begriff ist einer der wenigen Nicht-Fremdwörter.

WELT-Artikel (Sept.2021)

https://www.welt.de/wirtschaft/karriere/article234032602/Scrum-Master-Karriereoption-auch-fuer-aeltere-Fuehrungskraefte.html (nicht signierter Beitrag von 2001:16B8:AD1F:F900:2423:6AB2:6CD2:E543 (Diskussion) 22:50, 30. Sep. 2021 (CEST))

Sperren?

In dieser Woche hat eine IP drei Mal versucht, Werbung für eine Consulting-Firma einzuschleusen. Ich schlage vor, für die Seite vorübergehend eine Teilsperre (Nur angemeldete, nicht neue Benutzer) einzurichten. --Philipp Sªsse (Diskussion) 14:56, 27. Apr. 2022 (CEST)

Das werden wir dann über die Benutzersperre lösen - Benutzer wurde darauf angesprochen: Benutzer Diskussion:91.8.246.112 --Sebastian.Dietrich  ✉  17:45, 27. Apr. 2022 (CEST)

Selbständigkeit eines Scrum-Entwicklers durch Gericht bestätigt

Ich habe das Gefühl, dass dieser Heise-Artikel relevant für dieses Lemma ist: Urteil-Einordnung: Echte Scrum-Entwickler wohl ohne Sozialversicherungspflicht. Zitat: "Das Urteil dürfte über den Einzelfall hinaus Bedeutung erlangen." --212.8.145.44 21:54, 12. Aug. 2022 (CEST)

Kritik schon von 2019

Bei Forbes: https://www.forbes.com/sites/cognitiveworld/2019/08/23/the-end-of-agile/?sh=601004882071 Scrum basiert auf soziologischen Thesen, die in der realen Arbeitswirklichkeit nicht funktionieren. Scrum hat was von einer Sekte. --2003:C0:DF12:1700:4C05:884A:15D3:D8ED 17:18, 8. Jun. 2023 (CEST)

Heise: "Scrum, XP & Co. – warum keiner mehr agil arbeiten will"

Die Kritik in Scrum, XP & Co. – warum keiner mehr agil arbeiten will hat offenbar einen Nerv getroffen, sodass der Verlag zwei Wochen später diesen Artikel veroffentlichte: Nur Mut! – Endlich raus aus der Scrum-Hölle --213.196.222.82 13:44, 13. Sep. 2024 (CEST)