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

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)

Ja klar, wenn Dein interdisziplinäres Team aus einem Physiker, einem Linguisten und einem Politologen besteht, dann können die sich echt super im Urlaub vertreten ...

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)

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)

Ä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:

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)

Change-Manager

Hallo, ich kenne mich mit dem Thema nicht aus, aber was mir aufgefallen ist: Der Begriff "Change-Manager" (zu der der SCRUM-Master "werden kann"), wird nur einmal erwähnt und dabei nicht erklärt. Der Informationsgehalt ist damit null. Der Satz "Der SCRUM-Master wird zum "DINGDONG-Manager" würde damit im isolierten Artikel gleich viel Sinn ergeben. Ich bin mir nicht sicher, ob es in diesem Zusammenhang einem "Veränderungs-Manager" entspricht und eine Weiterleitung zu "Veränderungsmanagement" sinnvoll ist. Auf jeden Fall muss der Begriff erklärt oder verlinkt werden. Kann eine Person, die sich damit auskennt bitte machen? Danke :)--94.221.111.175 19:05, 11. Jan. 2018 (CET)

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.

Zertifizierung unzureichend

Die SCRUM Zertifizierung des IUE ist die einzige, welche nicht kommerzieller Natur ist und welche wissenschaftlich durch das IUE fundiert wird. Hingegen sind dort fast rein privatwirtschaftliche Unternehmen aufgeführt, dessen Relevanz nicht wirklich überzeugend ist. Bitte also auf meine Ergänzung im Artikel "Scrum" unter dem Punkt Zertifizierung, welche wieder rückgängig gemacht wurde. (nicht signierter Beitrag von BusinessExpertZh (Diskussion | Beiträge) 17:13, 4. Jan. 2020 (CET))

Auf mich macht das Agilitätskonform Bildungszentrum den Eindruck einer kommerziellen Unternehmung, und der Abschnitt macht den Eindruck von Werbung für dieses Unternehmen. --Mussklprozz (Diskussion) 17:41, 4. Jan. 2020 (CET)

Das Agilitätskonform Bildungszentrum ist der zertifizierte Bildungspartner des IUE (aber ja, auch ein wirtschaftliches Unternehmen, wie jeder private Bildungsanbieter). Im Sinne glaubwürdiger Konsequenz, müsste man somit alle privatwirtschaftlichen Bildungsanbieter in diesem Artikel löschen. Auch Scrum.org, welcher der grosste Anbieter ist. (nicht signierter Beitrag von BusinessExpertZh (Diskussion | Beiträge) 17:52, 4. Jan. 2020 (CET))

"Borisgloger Consulting" (ebenso aufgelistet) ist demnach ebenso Werbung. Von der Relevanz allerdings absolut nichtig. (nicht signierter Beitrag von BusinessExpertZh (Diskussion | Beiträge) 17:56, 4. Jan. 2020 (CET))

Nur als Hinweis: Derartige Vergleiche sind (aktuell) wenig zielführend. Derzeit geht's um das Agilitätskonform Bildungszentrum bzw. das IUE in Zürich. Deren Relevanz kann nach den hier geltenden Regeln nicht durch Vergleiche/Analogien nachgewiesen werden... Grüße, --rolf_acker (Diskussion • Beiträge) 18:25, 4. Jan. 2020 (CET)

Es macht zwar den Eindruck einer Sockenpuppen-Racheaktion, trotzdem scheint mir die Löschung von "Borisgloger Consulting" gerechtfertigt. Ein Argument ist richtig oder falsch unabhängig von seinem Urheber, hin und wieder ist Aufräumen in solchen Aufzählungen sinnvoll. Ich habe die Löschung daher gesichtet. --Mussklprozz (Diskussion) 21:14, 7. Jan. 2020 (CET)

Ist die Aufführung einzelner Anbieter hier überhaupt enzyklopädisch relevant? Im Zweifel werden so einfach immer nur noch mehr versuchen, ihre speziellen Angebote hier darzustellen. Von mir aus genügt eine algemeiner Absatz ohne Aufzählung einzelner Anbieter. --Grindinger (Diskussion) 17:07, 18. Feb. 2020 (CET)

So wie derzeit mit einem eigenen Abschnitt je Anbieter völlig übertrieben. Warum einige relevant und andere nicht relevant wären erschließt sich mir nicht. Keiner der Anbieter ist vermutlich relevant im Sinne der WP:Relevanzkriterien. Ich wäre für einen allgemeinen Absatz aber inkl. Aufzählung der Anbieter (und inkl. Boris Gloger, der zumindest in Ö deutlich relevanter ist als viele der anderen). --Sebastian.Dietrich ✉ 20:47, 18. Feb. 2020 (CET)

Habs jetzt entsprechend geändert. Wenn ich es aber recht bedenke, dann bringt die Aufzählung der Anbieter keinen Mehrwert gegenüber einer simplen Google Suche, wo man deutlich mehr Treffer findet. Plädiere also dafür auch die Liste zu streichen. --Sebastian.Dietrich ✉ 21:05, 18. Feb. 2020 (CET)

+1, mach das, kein enzyklopädischer Mehrwert, immer subjektiv und bleibt immer ein Streitpunkt (s. o.), auch gemäss WP:WWNI Nr. 7.2 --Alpöhi (Diskussion) 08:38, 19. Feb. 2020 (CET)

Oh neein!

Der Artikel beginnt mit: "Scrum (aus englisch scrum für „Gedränge“) ist ein Vorgehensmodell des Projekt- und Produktmanagements, insbesondere zur agilen Softwareentwicklung. Es wurde ursprünglich in der Softwaretechnik entwickelt, ist aber davon unabhängig. Scrum wird inzwischen in vielen anderen Bereichen eingesetzt.[1] Es ist eine Umsetzung von Lean Development für das Projektmanagement.[2][3]" Genausogut könnte man schreiben: "Scrum ist Scrum". Nichtsagender geht es wohl kaum noch! Kauderwelsch von "Experten" für "Experten" - aber eben KEINE saubere Enzyklopädik! Was ist denn das (kurzgfefaßte!) Wesen(!) von Scrum gegenüber anderen Vorgehensweisen?! Der Artikel ist ja recht umfangreich, aber völlig nichtssagend! Reiner Blähstil! Wenn man ihn gelesen hat, ist man hinterher genauso "schlau" wir vorher. DAS kann nicht die Aufgabe von Enzyklopädik sein. Im Anfang des Artikels sollte also nur das Wesentliche(!) stehen: "Vorgehensmodell des Projekt- und Produktmanagements, insbesondere zur agilen Softwareentwicklung." OK. Da sollte aber "agilen Softwareentwicklung" schon als erklöärender Link gestaltet sein, denn auch dieser Begriff ist enzyklopädisch erklärungsbedürftig! Und dann sollten zunächst und sofort erstmal die wichtigsten Wesensmerkmale von Scrum genannt werden. Wer nicht weiß, worum es sich überhaupt dreht, wird sich auch nicht für weiterführende Details, wie die historische Entwicklung von scrum interessieren (die eigentlich erst ganz am Schluß des Artikels interessant sein könnte, wenn der Leser dann schon sachlich erstmal Bescheid weiß, worum es überhaupt geht! Aus dem Zusammenhang gerissene Historie ist immer uninteresseant - und genau das KANN nicht Anliegen einer Enzyklopädie sein, oder?) Didaktische Neuordnung des Artikels empfohlen: Harte Fakten und Wesentliches zuerst, das "Drumherum" später!