1. Was ist Scrum?

​

Scrum ist ein Framework, das Teams bei der Zusammenarbeit unterstützt. Ähnlich wie ein Rugby-Team (wo es seinen Namen hat) für das große Spiel, ermutigt Scrum Teams, durch Erfahrungen zu lernen, sich bei der Arbeit an einem Problem selbst zu organisieren und über ihre Siege und Verluste nachzudenken, um sich kontinuierlich zu verbessern.

Obwohl Scrum am häufigsten von Softwareentwicklungsteams verwendet wird, können seine Prinzipien und Lektionen auf alle Arten von Teamarbeit angewendet werden. Dies ist einer der Gründe, warum Scrum so beliebt ist. Scrum wird oft als agiles Projektmanagement-Framework angesehen und beschreibt eine Reihe von Meetings, Tools und Rollen, die zusammenarbeiten, um Teams bei der Strukturierung und Verwaltung ihrer Arbeit zu unterstützen.

2. Was ist der Unterschied zwischen Agile und Scrum?

​

Das Agile Manifest wurde als Antwort auf Probleme mit dem Wasserfallmodell und seinem Ansatz im Jahr 2001 eingeführt. Seit der Einführung sind viele Arten von agilen Methoden aufgetaucht, die auf den agilen Prinzipien basieren. Derzeit ist Scrum aufgrund seiner Einfachheit das beliebteste von ihnen. Andere Typen sind: Kanban, Extreme Programming, RUP, DSDM und Lean Development.

3. Warum sollte ich Scrum verwenden?

​

Sie sollten Scrum nicht verwenden, weil Sie denken, dass Sie müssen, oder weil alle anderen es tun. Tun Sie es nur, wenn es ein echtes Problem gibt, das Sie lösen möchten. Um einige Beispiele zu nennen:

• Wenn Sie Probleme haben, Software zum richtigen Zeitpunkt bereitzustellen.

• Wenn Ihre Projekte zu viel Geld für zu wenig Wert ausgegeben haben.

• Wenn Sie denken, dass Sie mit den Markttrends nicht Schritt halten können.

Denken Sie daran, dass Scrum nicht alle Ihre Probleme lösen wird und wenn es schlecht implementiert wird, kann es die Dinge sehr gut verschlimmern.

4. Kann Scrum in einer großen Organisation funktionieren?

​

Natürlich! Große Organisationen neigen dazu zu denken, dass sie etwas Besonderes sind und dass allgemeine Regeln für sie nicht gelten. Andere Argumente, die Sie möglicherweise von diesen Organisationen hören, sind:

• Qualitätskontrolle ist für uns zu wichtig für Scrum,

• Unsere Projekte sind zu komplex, um kleine Schritte in Scrum durchzuführen.

• Das Senior Management unterstützt Scrum nicht.

Der beste Weg, diesen Widerstand zu überwinden, besteht oft darin, klein anzufangen und zu beweisen, dass es funktioniert. Es ist also nicht einfach, Scrum in einer großen Organisation zu implementieren, aber auch nicht unmöglich.

5. Was ist eine User Story?

​

Als Voraussetzung kann eine User Story gesehen werden. Es beschreibt klar, was für wen und warum benötigt wird. Es wird oft in der Form geschrieben: Als Rolle möchte ich etwas, damit ich einen Nutzen daraus ziehen kann. User Stories können in ihrer Granularität variieren. Wenn es allgemein definiert wird, wird es normalerweise als Epic bezeichnet. Wenn User Stories priorisiert werden, sollte das Team sie verfeinern, damit Sie User Stories erhalten, die in einem Sprint umgesetzt werden können. Bei Auswahl für einen Sprint definiert das Team Aufgaben zur Implementierung der User Story.

6. Wie hoch ist die Geschwindigkeit eines Teams?

​

Die Velocity eines Teams ist die Anzahl der Story Points, die das Team in einem Sprint umsetzen kann. Im Gegensatz zu Function Points sind Story Points nicht zwischen Teams vergleichbar. Jedes Team baut sein eigenes Messsystem für Story Points auf. Jedes Team ist gefordert, seine Velocity zu verbessern. Die Retrospektive ist eines der Instrumente, um dies zu erreichen.

7. Kann ich weiterhin Funktionspunkte zum Messen verwenden?

​

Sicher können Sie! Aber es ist nicht Teil von Scrum. Function Point Analysis ist eine Methode zur Messung von Software. Dazu zerlegt es das System in kleinere Komponenten. FPA misst Systeme aus funktionaler Sicht, unabhängig von der Art und Weise, wie sie implementiert sind. Die einzige Variable ist der Aufwand, der benötigt wird, um die Funktionspunkte zu implementieren. So kann es beispielsweise als Werkzeug verwendet werden, um die Wirkung verschiedener Entwicklungstools zu vergleichen. Es wird auch verwendet, um das Projektbudget und die Durchlaufzeit eines Projekts zu berechnen. Function Points können verwendet werden, um zwischen Teams zu vergleichen, was mit Story Points nicht möglich ist. Beachten Sie, dass FPA nur von Experten durchgeführt werden kann. FPA bietet Funktionen, die Scrum nicht hat, daher kann es von Vorteil sein, es zu verwenden.

8. Warum verwendet Scrum Story Points anstelle von Stunden?

​

Ausgezeichnete Frage!

Story Points sind eine relative Methode, um den Aufwand zu messen, der erforderlich ist, um eine User Story zu realisieren. Warum also nicht Stunden nutzen?

Dies liegt daran, dass jedes Teammitglied unterschiedliche Fähigkeiten hat, was bedeutet, dass die Zeit, die es braucht, um eine User Story zu realisieren, von Person zu Person unterschiedlich ist. Anstatt einen Durchschnittswert zu nehmen, der nicht viel aussagt, möchten Sie die Komplexität der User Story messen. Für Teammitglieder ist es viel einfacher, sich auf die Komplexität einer Story zu einigen als auf die Anzahl der Stunden. Dies ist auch der Grund, warum Sie nicht versuchen sollten, Story Points in Stunden zu übersetzen. Sehr oft sieht man Faustregeln, bei denen ein Story Point 4 oder 8 Stunden entspricht. Versuchen Sie, das nicht zu tun!

User Stories liegen in der Verantwortung des Product Owners. Die PO entscheidet über die Priorität der User Stories auf den Backlog Items. Für den PO sind Story-Punkte eine bessere Maßeinheit als Stunden, da er nicht wissen muss, wie die Storys umgesetzt werden. Jede User Story wird durch die Ausführung einer Reihe von Aufgaben umgesetzt. Aufgaben definieren, wie die User Story umgesetzt wird und liegen in der Verantwortung des Teams. Aufgaben werden normalerweise in Stunden und nicht in Story Points gemessen.

​

9. Wie viele Story Points sollte ein Team pro Sprint bewältigen?

​

Darauf gibt es keine wirkliche Antwort, da jedes Team anders ist. Abgesehen davon ist es wichtig, sich daran zu erinnern, dass Story Points nur die Größe von Storys relativ zueinander schätzen, nicht absolut. Und dass Story Points nicht in Scrum integriert sind, sondern lediglich ein Werkzeug, das viele Teams/Organisationen nützlich finden.

Einer der Hauptvorteile von Agile besteht darin, die wertvollsten Funktionen zuerst bereitzustellen. Wenn diese Features durch Storys repräsentiert werden, die zu groß sind, um bequem in einen einzelnen Sprint zu passen, können sie mit ziemlicher Sicherheit in kleinere Storys aufgeteilt werden.

Letztendlich entscheidet das Team gemeinsam, wie viel Arbeit es im kommenden Sprint übernehmen kann.

10. Wem gehört das Sprint-Backlog?

​

Es ist nicht verwunderlich, dass hier Verwirrung entsteht, da der Product Owner für das Product Backlog verantwortlich ist und man davon ausgehen kann, dass er auch für das Sprint Backlog verantwortlich ist. Der Scrum Guide ist jedoch ziemlich klar, dass „nur das Entwicklungsteam beurteilen kann, was es im kommenden Sprint erreichen kann“. Der Product Owner darf das Sprint Backlog also nicht einseitig ändern, nachdem der Sprint begonnen hat.

Das Sprint Backlog wird sich im Laufe des Sprints sicherlich ändern, wenn neue Informationen ans Licht kommen, aber diese Änderungen sollten immer das Ergebnis eines Gesprächs zwischen dem Product Owner und dem Rest des Teams sein. Und die Änderungen sollten das Sprint-Ziel, das das Team gemeinsam erarbeitet hat, nicht gefährden. Kurz gesagt, das gesamte Team besitzt das Sprint Backlog.

11. Warum kann der Product Owner nicht auch Scrum Master sein?

​

Dies scheint eine verrückte Frage zu sein, die gleichbedeutend ist mit „Warum kann der Busfahrer nicht auch der Busschaffner sein?“ Und doch wird dieser Rollenkonflikt oft wahrgenommen.

Die Rollen von Product Owner und ScrumMaster schließen sich stark aus. Tatsächlich sollte zwischen ihnen eine natürliche Spannung bestehen: der Product Owner, der die Interessen des Unternehmens innerhalb des Teams vertritt; und der ScrumMaster, der die Interessen des Teams innerhalb des Unternehmens vertritt. Wenn eine Person beide Rollen spielt, wird sie je nach Hintergrund/Zugehörigkeit/Veranlagung natürlich zu der einen oder anderen hingezogen – was weder dem Team noch dem Unternehmen gegenüber fair ist.

12. Wann sollten Aufgaben zugewiesen werden?

​

Theoretisch sind Scrum-Teams funktionsübergreifend und selbstorganisierend und, wie oben erwähnt, ist das gesamte Team für das Sprint-Backlog (und das Erreichen des Sprint-Ziels) verantwortlich. Solange sich das Team im Sprint Planning Meeting darauf einigen kann, wie die Arbeit erledigt wird, ist es nicht unbedingt notwendig, jede Aufgabe einem Teammitglied zuzuweisen.

Aber viele Teams – insbesondere solche, in denen jedes Mitglied auf eine andere Disziplin spezialisiert ist – finden es sinnvoll, auf diese Weise zu arbeiten und Aufgaben zu verteilen, nachdem das Sprint Backlog vereinbart wurde. Diese Minipläne sollten jedoch nicht in Stein gemeißelt sein – sie sollten sich im Laufe des Sprints ändern und anpassen können.

13. Wann erfolgt die Schätzung?

​

Storys müssen geschätzt werden, bevor sie in ein Sprint Backlog aufgenommen werden können, daher ist es hilfreich, wenn vor dem Sprint Planning Meeting eine gute Anzahl von Storys geschätzt wird. Dies findet normalerweise in einem separaten Product Backlog Grooming (oder Management) Meeting statt – bei dem das gesamte Team gemeinsam die relative Größe der Storys an der Spitze des Product Backlogs schätzt.

Während das Backlog Grooming in die Sprintplanung integriert werden kann, bietet es einen deutlichen Vorteil, separate Meetings abzuhalten. Es hält die Sprint-Planung auf die beiden Ergebnisse der Entscheidung fokussiert, welche Arbeit im kommenden Sprint erledigt wird und wie sie ausgeführt wird.

14. Wer definiert die Definition von ready/done?

​

Es liegt am Team als Ganzes, sich auf beide Definitionen zu einigen, anstatt fertige Versionen auszuhändigen. Beide Definitionen werden sich mit zunehmender Erfahrung und Eignung des Teams weiterentwickeln. Sie sollten regelmäßig besucht werden – die Sprint Retrospektive ist die perfekte Gelegenheit.

In Organisationen mit mehreren Scrum-Teams mit gemeinsamen Definitionen von Ready and Done sollten die Definitionen in Scrum of Scrum-Meetings mit Vertretern jedes Teams vereinbart werden.

15. Wie groß sollte ein Scrum-Team sein?

​

2003 sagte Jeff Sutherland, dass ein Scrum-Team aus nicht mehr als sieben Mitgliedern bestehen sollte. Nun empfiehlt der Scrum Guide eine Teamgröße zwischen drei und neun Mitgliedern. Generell gilt: Je größer das Team, desto mehr Arbeit kann es übernehmen. Aber auch die Planung und Koordination der Arbeit größerer Teams führt zu einer höheren Komplexität.

16. Wie soll der Product Backlog bestellt werden?

​

Das Product Backlog sollte so geordnet werden, dass die höchstwertigen, detailliertesten Storys oben und die niedrigstwertigen, am wenigsten detaillierten Storys ganz unten stehen. Der Product Owner ist dafür verantwortlich, das Product Backlog so zu bestellen, dass ein maximaler Mehrwert für das Geschäft entsteht.

Ein häufiges Missverständnis ist, dass der Rückstand nach Priorität geordnet werden sollte. Aber wenn wir bedenken, dass sich das Product Backlog ständig mit dem Produkt verändert und weiterentwickelt – basierend auf Feedback von Stakeholdern usw. – dann ist es leicht zu erkennen, wie ein Element mit hoher Priorität es in das Backlog schaffen könnte, aber noch nicht detailliert genug ist eine Position in der Nähe der Spitze.

17. Mit welchen Problemen kann ich bei der Implementierung von Scrum rechnen?

​

Viel! Da Kultur das Verhalten von Menschen bedeutet, muss sich die Kultur meistens ändern. Es wird Widerstand geben. Die Leute werden es verspotten. Konservative Parteien werden Beweise verlangen. Sie werden solide Geschäftsfälle sehen wollen, bevor eine Genehmigung erteilt wird. Am Anfang schwimmt er oft gegen den Strom. Sie müssen bestimmt sein. Geben Sie nicht so leicht auf.