Sie befinden sich hier: GOagile! :: Scrum :: Prozess :: 
 

Man muss 70 % der Arbeit erledigt haben, um eine 90 % ige Aussage treffen zu können...

Scrum besteht aus wenigen, klaren Regeln.

Diese beinhalten die Anwendung der Rollen Product Owner, Team und Scrum Master, die Verwendung eines priorisierten Product Backlog sowie das Erstellen von Produktinkrementen innerhalb kurzer Arbeitszyklen, den sogenannten Sprints.

William Edward Deming, amerikanischer Physiker und Statistiker, entwickelte schon in den 50er Jahren die prozessorientierte Sicht auf die Tätigkeiten eines Unternehmens.

Er beschreibt die Phasen im kontinuierlichen Verbesserungsprozess (KVP)

Mehr Details?: http://de.wikipedia.org/wiki/Demingkreis

In Scrum sieht das dann so aus:
 

Scrum GOagile - Scrum Coaching Grafik Scrum Prozess

Achten Sie darauf, dass iterative Prozesse NICHT bedeuten:

  • Keine Ziele
  • Keine Langfristplanung
  • Kein Risikomanagement
  • Kein Projektcontrolling
  • Kein Reporting
  • Keine Spezifikation
  • Keine Dokumentation
  • Keine Qualitätssicherung

Leider passiert es viel zu häufig, dass Agilität als Ausrede für Chaos herhalten muss. Deshalb ist es so wichtig, dass jeder im Team seine Rolle und deren Verantwortung wirklich verstanden hat.

Eine Iteration (Sprint) hat immer dieselbe Länge (2, 3 oder 4 Wochen, je nach Sinnhaftigkeit).

Die Anforderungen bleiben für die Dauer eines Sprints stabil! Das Team tut alles dafür, zu liefern, worauf sich alle zu Beginn geeinigt haben!

Am Ende des Sprints werden potenziell einsetzbare Produktinkremente geliefert!

Die Produktinkremente werden "Stories" genannt, mehr dazu finden Sie im Planungsprozess.

Die Erkenntnisse der Retrospektive sind Bestandteil des nächsten Sprints, ansonsten findet kein Lernen statt und damit keine Verbesserung.

Während des Sprints wird nicht umpriorisiert und keine neue Anforderung gestellt! Alle getroffenen Vereinbarungen bleiben für die Dauer einer Iteration absolut stabil.

Die anfängliche Abnahme der gelieferten Story Points in der Betrachtung der Velocity muss nicht bedeuten, das Team wird schwächer. Manchmal liegt der Grund darin, dass Komplexitäten beseitigt werden, und das ist gut!
© 2011 go-agile - Impressum