Schlagwort-Archive: Softwareprojekt

4 bewährte Verfahren für Sprint Plannings

1 Antwort

In diesem Artikel gehen wir vier Grundsätze der Sprintplanung durch, die wir für besonders hilfreich halten.

Die agile Zeremonie des sogenannten Sprintplannings oder schlicht „Plannings“ dient in jedem Sprint dazu, die Ausführung neu zu fokussieren, Überraschungen zu minimieren und eine insgesamt höhere Codequalität zu garantieren.

Überprüfen Sie Ihre Roadmaps, bevor Sie sich treffen

Die Zeit vergeht schneller als wir denken. Daher ist es eine gute Idee, die Roadmap Ihres Projekts in den ersten zwei Wochen des neuen Jahres zu überprüfen. Die Roadmap bildet den Kontext für zwei wichtige agile Konzepte: Epics und Versionen, die das Rückgrat für die agile Programmplanung bilden und dabei helfen, die Lieferung längerfristiger Arbeit zu verfolgen. Vergewissern Sie sich, dass die Roadmap aktuell und für das gesamte Team sichtbar ist und dass Epics und Versionen vor dem Sprint Planning Meeting korrekt in Jira aufgelistet sind.

Halten Sie eine Besprechung vor der Besprechung ab

Die Sprintplanung umfasst zwei wichtige Aufgaben: die Pflege des Backlogs und die Entscheidung, welche Arbeiten im kommenden Sprint abgeschlossen werden sollen. Bei Atlassian haben wir die Erfahrung gemacht, dass das Backlog Grooming am besten in einem separaten Meeting mit dem Product Owner und dem Scrum Master vor dem eigentlichen Sprint Planning Meeting stattfindet. Für das gesamte Entwicklungsteam ist diese Vorbesprechung optional.

Was ist Backlog Grooming?

Backlog Grooming stellt sicher, dass das Backlog gesund ist. Wie sieht das aus? Gut, dass Sie fragen. Ein gesundes Backlog:

  • priorisiert jedes Arbeitselement, wobei die wichtigste Arbeit an erster Stelle steht
  • enthält vollständig ausgearbeitete User Stories, mit deren Umsetzung das Entwicklungsteam beginnen kann
  • Enthält eine aktuelle Schätzung für jedes Arbeitselement

Die Teams bei Atlassian halten einige Tage vor der Sprintplanung kurze Backlog Grooming Meetings ab. Planen Sie 30 Minuten für dieses Meeting ein, um die Aufgaben zu sichten, die Sie in den nächsten zwei Sprints am ehesten angehen werden. Manchmal werden Sie Punkte finden, die nicht detailliert genug sind, um ausgeführt zu werden, oder die mehr kontextbezogene Informationen vom Product Owner benötigen. Das ist das Schöne an der Erstellung des Backlogs im Voraus. Diese Lücken können zwischen den Meetings gefüllt werden, so dass sie während der eigentlichen Sprint-Planung keine Hindernisse (oder Zeitfresser) darstellen. Durch die Erstellung des Backlogs im Vorfeld hat das Team während der Sprintplanung mehr Zeit, seine Optionen für den Sprint zu prüfen und bei Bedarf Elemente für den nächsten Sprint zu markieren.

Team-Aktivität: Manche Teams haben Probleme mit der Schätzung. Story Points bieten einen soliden Rahmen für die Schätzung der Arbeit. Binden Sie das Team in eine Aktivität namens stille Schätzung ein. Legen Sie zu Beginn der Übung die Story-Point-Werte (0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100) in Spalten auf eine weiße Tafel. Bitten Sie dann das Team, die Benutzergeschichten in der Spalte zu platzieren, die sie für am genauesten halten. Die meisten Geschichten werden sich auf eine Zahl konzentrieren, und wenn es Unstimmigkeiten über den Punktwert der Geschichte gibt, ist es an der Zeit, eine Diskussion darüber zu eröffnen, warum. (Siehe auch unseren Artikel zu: Die 6 besten Planning Poker Tools zur freien Verfügung)

Informieren Sie die Sprintplanung mit Daten

Der Schwerpunkt des Sprint Planning Meetings liegt auf der Festlegung und Vereinbarung des Sprint-Ziels – der Menge an Arbeit, die das Team glaubt, während des Sprints erledigen zu können. Der Product Owner, der Scrum Master und das gesamte Entwicklungsteam müssen dabei anwesend sein. Wir bei Atlassian empfehlen ein Minimum von einer Stunde für jede Woche des Sprints, die Sie in der Besprechung abdecken wollen. Beginnen Sie beispielsweise mit einem zweistündigen Sprint Planning Meeting, um einen zweiwöchigen Sprint abzudecken. Idealerweise sollten Sie die Sprintplanung zu Beginn der Woche ansetzen. Dann werden der Kontext und der Arbeitsfluss des Teams weniger durch das Wochenende gestört.

Tipp: Planen Sie die Sprint-Retrospektive und das Sprint-Planning-Meeting nicht zusammen. Geben Sie dem Team genügend Zeit, um die Retrospektive zu verdauen und effektiv zur Sprintplanung beizutragen – vielleicht indem Sie dazwischen ein Teamessen einschieben.

Aus Erfahrung

Zu Beginn der Besprechung stellt der Scrum Master alle relevanten Aktionspunkte aus der Retrospektive des Teams vor. Als Nächstes gibt der Product Owner Produkt- oder Markt-Updates, damit alle auf dem gleichen Stand sind und den breiteren Kontext noch im Kopf haben.

Nach der Nachbesprechung ist es Aufgabe des Product Owners, das eigentliche Planungsgespräch zu beginnen. Zu Beginn verwendet der Product Owner die durchschnittliche Geschwindigkeit des Teams (die Menge an Arbeit, die typischerweise in einem Sprint abgeschlossen wird), um einen Vorschlag für eine Reihe von Storys für den Sprint, den so genannten „Sprint Forecast“, zusammenzustellen, der den Wert für den Kunden maximiert. Der Product Owner sollte auch diese drei Faktoren berücksichtigen:

  • Feiertage, persönlicher Urlaub und teamweite Ereignisse
  • Priorität der Stories im Backlog (idealerweise schlagen sie die am höchsten eingestuften Elemente vor)
  • Wie (und ob) diese Arbeit das Produkt seinem Endziel näher bringen wird

Tipp: Product Owner können den Sprint Marker verwenden, um die Velocity zu berechnen.

Wenn das Team neu ist und keine etablierte Geschwindigkeit hat, sollte der Product Owner keine Sprintprognose vorschlagen. Stattdessen sollte dies eine Übung für das gesamte Team sein, da es wichtig ist, dass jedes Mitglied zustimmt. Zunächst wird das Team die Vorhersage nach bestem Wissen und Gewissen treffen und ein paar Sprints nach dem Prinzip „Versuch und Irrtum“ durcharbeiten. Sobald die Geschwindigkeit des Teams – die durch das Velocitydiagramm in Jira sehr schön veranschaulicht wird – numerisch festgelegt ist, verwenden Sie diese Metrik, um die Sprint-Prognose zu erstellen.

Sobald der Product Owner seine Ideen für den Sprint Forecast vorgestellt hat, kann das Team diesen validieren (und/oder anpassen) und sich auf einen Aktionsplan für den Sprint einigen.

Tipp: Das Team sollte bei jedem Sprint darüber nachdenken, wie die technischen Schulden reduziert werden können. Die Erstellung eines Schnellfilters, der Bugs im Backlog des Teams hervorhebt, ist eine einfache Möglichkeit, wichtige Bugs zu markieren, die in den Sprint aufgenommen werden sollen, während das Team an User Stories in verschiedenen Bereichen der Codebasis arbeitet. Der Schnellfilter „tech debt“ verwendet die JQL-Abfrage „type in (bug)“, um die Ansicht auf Bugs zu beschränken. Erweitern Sie einfach die JQL-Abfrage, um bei Bedarf weitere Fehlertypen einzubeziehen.

Der nächste Schritt in der Sprint-Planung besteht darin, die Stories durchzugehen und zu beschreiben, welche Arbeiten zur Fertigstellung jeder Story erforderlich sind. Während das Team plant, sollten Sie sicherstellen, dass jemand die wichtigsten Punkte in jedem Jira-Ticket festhält. Auf diese Weise sind sowohl die Entscheidung als auch die Begründung später leicht zu erkennen. Das Team sollte sich Fragen stellen wie…

  • Hat sich die Definition der Story geändert, seit sie geschrieben wurde? Gibt es neue kontextbezogene Informationen, die das Team berücksichtigen muss?
  • Ist die Schätzung für die Story noch gültig? Ist das gesamte Team mit der Schätzung einverstanden? Wenn nicht, sollte der Scrum Master das Team bei der Neuschätzung anleiten.
  • Welche Aufgaben sind für die Fertigstellung dieser Story erforderlich? Verwenden Sie Teilaufgaben, um die Arbeit zu parallelisieren und den Ablauf zu optimieren. Wenn das Team bei der Aufteilung der Arbeit auf einzigartige Stories stößt, sollten diese Aufgaben zu völlig unabhängigen Stories erhoben werden.
  • Welche Auswirkungen hat das Testen auf diese Story? Wie können wir das Testen automatisieren? (Denken Sie daran, dass manuelle Testskripte im Wesentlichen technische Schulden sind).
  • Sind spezielle Fähigkeiten erforderlich? Wie können wir die Zeit des Spezialisten optimieren, ohne den Rest des Teams zu behindern?
  • Wie wirkt sich diese Geschichte auf die Architektur des Produkts aus? Gibt es bestimmte Personen, die das Team in den Entwurf und die Codeüberprüfung einbeziehen muss?
  • Gibt es Abhängigkeiten zwischen den Stories? Können wir angesichts dieser Abhängigkeiten die gesamte Arbeit während des Sprints abschließen?

Die Versuchung ist groß, diese detaillierte Übung überstürzt durchzuführen. Aber eine gute Planung zahlt sich aus, sobald der Sprint beginnt. Hier geht es vor allem darum, zu verstehen, wie die Arbeit erledigt werden soll, wobei der Scrum Master die Diskussion im Team fördert. Es ist wichtig, dass jeder gehört wird, damit sich das Team verantwortlich fühlt, sobald der Plan steht.

Tipp: Während der Sprint-Planung ist es einfach, Stories in den Sprint hinein- und wieder herauszuschieben, während das Team seine Sprint-Prognose erstellt. Klicken Sie einfach mit der rechten Maustaste auf ein Issue, um es in den oder aus dem Sprint zu verschieben.

Auf die Plätze, fertig, Sprint!

An diesem Punkt des Meetings sollte das Team mit dem Sprint Forecast zufrieden sein. Am Ende der Sprintplanung empfiehlt es sich, von allen Anwesenden mündlich zu bestätigen, was das Team am Ende des Sprints tatsächlich ausliefern wird. Stellen Sie außerdem sicher, dass jedes Teammitglied mindestens eine Aufgabe hat, mit der es beginnen kann, und dass niemand doppelte Arbeit leistet.

Das Engagement und die Moral des Teams schwanken natürlich von Sprint zu Sprint. Diese Schwankungen zeigen sich oft während der Sprint-Planung, aber widerstehen Sie der Versuchung, sich sofort damit zu befassen. Nutzen Sie stattdessen die Retrospektive des Teams, um alle Probleme zu verstehen, die sich auf die Moral auswirken. Teams, die schnell auf Kultur- und Entwicklungsprobleme reagieren, sind zufriedener, produktiver und schreiben besseren Code.

Aus den Fehlern der Anderen lernen: Wege zum Erfolg im IT-Projektmanagement

Schreibe eine Antwort

3 Tipps, um auch große IT-Projekte erfolgreich zu steuern

Schon mal von einem großen IT-Projekt gehört, das in der geplanten Zeit und im Rahmen des vorgesehenen Budgets erfolgreich abgeschlossen wurde? Nein? Kein Wunder. In der IT-Welt haben Großprojekte, die ihr Ziel innerhalb der vorgesehenen Zeit und ohne Überschreitung des Budgets erreichen, Seltenheitswert. Wir zeigen drei typische Fehler, die in großen Softwareprojekten vorkommen und Wege, sie zu vermeiden.

Eine gemeinsame Studie von McKinsey und der Oxford-Universität hat gezeigt: Alle großen IT-Projekte (Startbudget über 15 Millionen USD) erfordern fast 50% mehr Budget als geplant und 7% davon überziehen die vorgesehene Projektzeit, während sie etwa die Hälfte der Ziele verfehlen. Die schwarzen Schafe sind die Softwareprojekte. Nichteinhaltung von Kosten- und Zeitrahmen sind hier fast schon vorprogrammiert.

Problem 1: Mangelndes Interesse des Managements

Zeigt das Management kaum Interesse, ist es kein Wunder, wenn das Projekt nicht fortschreitet. Wenn das Management nichts tut, mit der Behauptung, sich mit der IT nicht auszukennen, die ganzen „IT-Sachen” dem technischen Team überlässt, wird das Techniker-Team selbst die Führung übernehmen und alle Entscheidungen treffen. Dadurch können neue Probleme entstehen. Meistens fehlt dem technischen Team nicht das fachliche Know-How, sondern der klare Blick auf die geschäftlichen Ziele. So kann es dazu kommen, dass die Techniker Entscheidungen treffen, welche unbeabsichtigter Weise mit Geschäftsinteressen kollidieren.

Die Lösung: Durch Präsenz und Commitment sind Sie immer auf dem Laufenden und vermeiden so, dass „die Techniker“ die Projektführung übernehmen und prozessbezogene Belange oder Geschäftsinteressen übersehen. Management-Präsenz und regelmäßige Kommunikation mit dem technischen Team sind die Voraussetzung dafür, dass Prozesse und Geschäftsziele mit der technischen Umsetzung harmonieren. Das gesamte IT-Projekt profitiert von einer Kultur, die auf regelmäßigem Austausch zwischen Management und dem technischen Team beruht. Ein gutes technisches Team wird jederzeit in der Lage sein, klar darzustellen, was es tut. Anderenfalls gehen Sie davon aus, dass das Team gar nicht richtig weiß, was es tut.

Problem 2: Zu starker Fokus auf Kostenreduzierung

Gerade in Krisenzeiten sucht jeder Wege, um kostenreduzierend und effizient zu handeln. Einsparungen sind gut, doch kann der Schuss auch nach hinten losgehen: beispielsweise dann, wenn dafür Projektmitarbeiter eingespart werden oder weniger gut ausgebildetes Projektpersonal eingekauft wird. Projekte mit weniger spezialisierten Ressourcen sind bekannt dafür, den Zeitplan und das Budget nicht einzuhalten sowie für Qualitätsprobleme oder Abstriche bei der Umsetzung der Anforderungen.

Die Lösung: Berechnen Sie das Budget so, dass Sie die Kosten für gut ausgebildete, erfahrene Projektmitarbeiter einplanen. Dann finden Sie die richtigen Leute für die anstehenden Aufgaben viel leichter. „Quick and dirty“ rechnet sich selten. Sollten Sie an Outsourcing ins billigere Ausland denken, berücksichtigen Sie eventuelle Probleme durch Sprachhürden, unterschiedliche Kommunikations- und Arbeitskulturen, Erreichbarkeit, z.B. bedingt durch Zeitverschiebungen. Bedenken Sie auch, dass ein. erfolgreiches Projekt nicht nur Entwickler braucht. Die vernünftige Projektsteuerung und Zielverfolgung ist Aufgabe des Projekt-Managements. Erfolgsentscheidend sind auch die Ergebnisse der Business Analysten und der Tester. Bevor Sie den Rotstift ansetzen, überlege Sie, wie viele, für die anstehenden Aufgaben nicht ausreichend qualifizierte Mitarbeiter, das Projekt, bzw. das Unternehmen sich leisten kann.

Problem 3: Fehlende Zielklarheit

Technikfreaks neigen in ihrer Begeisterung dazu, Dinge sofort anzupacken. Was auch immer dieses Verhalten herbeiführt, es führt immer zu mangelhafter oder gar fehlendende Planung. Ohne den Umfang, die Zeile, und das erwartete Projektergebnis genau zu verstehen, kann der Versuch, auf dieser Basis ein Projekt zu lenken, nur scheitern. Ein erfolgreiches Projekt bedeutet mehr als die Lieferung des endgültigen Softwareprodukts. Es geht auch um das Erreichen des erwünschten Projektergebnisses innerhalb des geplanten Zeitraums und Budgets. Fehlt eine koordinierte Planung, tritt Folgendes auf:

  • Unklarheit über Umfang und Ziel
  • Verwirrung bezüglich Rollen und Verantwortlichkeiten
  • Ineffiziente Ressourcennutzung
  • Nichtverfügbarkeit von Ressourcen zu kritischen Zeiten
  • Ungleichmäßige Arbeitsbelastung des Teams
  • Falsche Zeit- und Kosteneinschätzungen (durch unerwartete Ereignisse)
  • Schwache Leistung u.a. durch Überarbeitung, Frust, verspätete Lieferung, fehlerhafte Ergebnisse etc.

Die Lösung: Es scheint banal: diese Nebenwirkungen fehlender Zielklarheit in einem Großprojekt sind mittels expliziter, klarer Festlegung und durch regelmäßige Zielkommunikation vermeidbar. Durch die engmaschige Verfolgung der Ziele und des Ist- Zustandes in jeder Phase, erkennen Sie frühzeitig Zielabweichungen und Unklarheiten Zielerreichung gesamt und im Detail zu betrachten verstärkt die Klarheit. Auch wenn ausschließlich Spezialisten am Werk sind, kann es bei Unklarheiten über das Ziel des Projekts zu Chaos und Frustration verursachenden Effekten kommen. Stellen Sie sich ein Orchester vor, in dem lauter Virtuosen der jeweiligen Instrumente spielen, aber der Dirigent fehlt. Das will keiner hören!

Fazit

In IT-Projekten ist engmaschige Kommunikation essentiell, um auf der Zielgeraden zu bleiben, wie überall, wo Menschen mit Menschen zusammenkommen und ein Gemeinschaftswerk zum Erfolg bringen wollen. Ohne ein gutes, engagiertes Management mit Leitbildcharakter sowie Absprachen und Zielklarheit in jeder Phase sind Chaos, Frust und Fehler vorprogrammiert. Ebenso, wenn Sie am falschen Ende sparen.