Rolf F. Katzenbergers ausführlichem Beitrag zur 2013er Revision 2013 des Scrum Guide von Jeff Sutherland and Ken Schwaber (scrum.org) ist kaum noch etwas hinzuzufügen…
Die offizielle PDF Liste der Änderungen von 2011 zu 2013: Changes als PDF
Liste der Änderungen gemäß Revisionsliste unter scrum.org
1. Es wurde ein Absatz zur ‚Artefakt Transparenz‘ hinzugefügt. Scrum basiert auf Transparenz. Entscheidungen zur Optimierung des Geschäftswerts und Nachhalten des Risikos werden auf der Basis des festgestellten Artefakten Status getroffen. Ist der Status dieser Artifakte nicht vollständig transparent, werden diese Entscheidungen fehlerhaft, Wert kann sich schmälern, das Risiko kann steigen.
2. Die Sprint Planung findet nun in einem Treffen statt. Hier werden nun zwei Themen adressiert: was kann in diesem Sprint bearbeitet werden und wie kann die auswählte Arbeit geschafft werden. Nachdem das Entwicklungsteam die zu erledigenden Aufgaben geschätzt haben, vereinbart das gesamte Scrum Team das Sprintziel. Das Sprintziel sorgt für Geschlossenheit der Arbeit des Entwicklungsteams, die verloren gehen könnte, gäbe es kein gemeinsames Ziel. Beachte die formale Einbeziehung des Sprintziels!
3. Das Product Backlog [Aufgabenspeicher] wird eher verfeinert, denn gepflegt. Die verfeinerten ‚Backlog Items‘ [anstehende Aufgaben] sind transparent, ausreichend gut verstanden und granular genug, um Input für die Sprintplanung und zur Auswahl für den Sprint zu sein. Backlog Items dieses Transparenzgrades werden ‚ready‚ [bereit] genannt. Bereit und erledigt [hier: ‚Done‘] sind zwei Status, die Transparenz untermauern.
4. Scrum verordnet Ereignisse, um Regelmäßigkeit zu unterstützen und zusätzliche Sitzungen, die im Scrum nicht vorgesehen sind, zu vermeiden. Alle Ereignisse werden zeitbegrenzt angesetzt. Ein Sprint, als Rahmenereignis, hat eine festgelegte Dauer, die nicht verkürzt oder verlängert werden kann. Die übrigen Ereignisse können enden, wannimmer ihr ursprüngliches Ziel erreicht ist; es sollte sichergestellt werden, dass immer nur soviel Zeit aufgewendet wird, dass keine ‚Verschwendung‘ produziert wird.
5. Die Wichtigkeit des Daily Scrum [tägliches Zusammenkommen] als ein Planungstreffen wird unterstrichen. Zu häufig wird es als Statustreffen genutzt. Das Entwicklungsteam sollte täglich aufs Neue miteinander klären, wie es als selbstorganisiertes Team miteinander arbeiten wird, um das Sprintziel zu erreichen und das geplante Teilstück bis zum Sprintende zu schaffen. Im Vordergrund dieses Treffens sollte immer die Frage stehen, wie gut das Team dem Sprintziel näher kommt [Input]; heraus kommen sollte ein neuer oder angepaßter Plan, der die Antrengungen des Teams, dem Sprintziel zu erreichen, optimiert.
Um die Teamanstrengung gegenüber Einzelleitungen zu verdeutlichen, wurden die drei Fragen des Daily Scrum umformuliert:
- Was habe ich gestern geschafft, um das Team beim Erreichen seines Sprintziels zu unterstützen?
- Was werde ich heute tun, um das Team beim Erreichen seines Sprintziels voran zu bringen?
- Sehe ich irgendwelche Hindernisse, die mich oder das Entwicklungsteam davon abhalten könnten, das Sprintziel zu erreichen?
6. Es wird unterstrichen, wie wichtig das Konzept des Geschäftswertes im Sprint Review [Ergebnisüberprüfung] ist. Im Sprint Review klären Scrum Team und Stakeholder [Auftraggeber, Kunden] miteinander, was im Sprint erreicht wurde. Auf dieser Basis und unter Berücksichtigung jeglicher Product Backlog Änderungen, wird miteinander geklärt, was sinnvollerweise als nächstes getan wird, um den Geschäftswert weiter zu optimieren.
Link
https://www.pragmatic-teams.de/scrum-guide-2013-was-gibt-es-neues