Scrum

Scrum 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. Es ist eine Umsetzung von Lean Development für das Projektmanagement.

Quelle "Wikipedia"

Vorgehen

Um Scrum Projekte in smenso Cloud umzusetzen sind folgende Punkte zu beachten:

• Backlog Projekt
• Sprint Projekt
  • jeder Sprint ist ein separates Projekt (z.B. Sprint 02/21) und wird mit Aufgaben aus dem Backlog oder offenen Aufgaben aus dem vorherigen Sprint befüllt
• Wahlweise kann auch noch ein "Roadmap" Projekt erstellt werden, um Epics auf die Jahre zu planen

Aufbau "Backlog" Projekt

Deine Projektordner: Storys | Backlog Frontend | Backlog Backend

Typ:  ✅ Aufgabe  |  🐞 Bug |  🏆 Feature Request | 👑 Epic | 📘 Story | 🔍 Retrospektive
Story: Story 1  |  Story 2  |  Story 3  |  usw.
Story Points: 1 | 2 | 3 | 5 | 8 | 13 | 20 | 40 | 100
Umgebung: Backend (Cloud/API/DB) | UI/UX | Mobile UI/UX

Es ist am besten, wenn man das Backlog Projekt in der Listenansicht darstellt. Anbei ein Screen der Listenansicht:

Wie man sieht, werden die einzelnen Aufgaben im Backlog Projekt durch den Flavor Typ weiter klassifiziert. So kann man festlegen, welche Aufgaben Storys, Epics oder Aufgaben sind.

Storys 

User Storys werden oft als einfacher Satz formuliert und sind wie folgt aufgebaut:

"Als [Kundentyp] [möchte] ich, [damit]."

Sehen wir uns das im Einzelnen an:

• "Als [Kundentyp]": Für wen entwickeln wir? Wir begnügen uns nicht mit einem Berufstitel, sondern bemühen uns um den Kundentyp der Person: Max. Unser Team sollte ein gemeinsames Verständnis von Max haben. Wir haben hoffentlich viele Maxe interviewt und können nachvollziehen, wie diese Person tickt, wie sie denkt und fühlt. Wir können uns in Max hineinversetzen.
• "Möchte": Damit beschreiben wir die Absicht – und nicht die Funktionen, die der Benutzer verwendet. Welchen Zweck möchte der Kunde eigentlich erreichen? Bei dieser Aussage geht es nicht um die Umsetzung: Wenn du einen Teil der UI beschreibst, statt das Benutzerziel zu erläutern, hast du den Sinn verfehlt.
• "Damit": Wie passt der unmittelbare Wunsch des Kunden, etwas tun zu können, in sein Gesamtbild? Von welchem Nutzen möchte er allgemein gesehen profitieren? Welches große Problem muss hier gelöst werden?

User Storys könnten beispielsweise so aussehen:

• Als Rolle A möchte ich meine Freunde einladen, damit wir diesen Service gemeinsam nutzen können.
• Als Rolle B möchte ich meine Arbeit organisieren, damit ich mehr Kontrolle darüber habe.
• Als Manager möchte ich die Fortschritte meiner Kollegen nachvollziehen können, damit ich über unsere Erfolge und Fehlschläge besser berichten kann.

Du musst diese Struktur nicht übernehmen, aber sie hilft dir, zu definieren, wann eure Arbeit erledigt ist. Wenn der gewünschte Nutzen dieses Kundentyps klar ist, ist die Story vollständig. Wir empfehlen Teams, ihre eigene Struktur festzulegen und einzuhalten.

In den Unteraufgaben werden dabei die Checklistenpunkte definiert, die für eine Story wichtig sind.

Über die Timeline können z.B. Epics grafisch als Roadmap geplant werden, so dass man immer den Überblick darauf behält.

Aufbau "Sprint" Projekt

Deine Projektordner: Sprint Backlog | To Do | In Bearbeitung | In Review | Erledigt | Next Sprint | Retrospektive

Typ:  ✅ Aufgabe  |  🐞 Bug |  🏆 Feature Request | 👑 Epic | 📘 Story | 🔍 Retrospektive
Story: Story 1  |  Story 2  |  Story 3  |  usw.
Story Points: 1 | 2 | 3 | 5 | 8 | 13 | 20 | 40 | 100
Umgebung: Backend (Cloud/API/DB) | UI/UX | Mobile UI/UX

Für den Sprint eignet sich am besten die Boardansicht:

Die Aufgaben die im Sprint zu tun sind, werden im ersten Ordner "Sprint Backlog" gesammelt und können darin an die verschiedenen Bearbeiter verteilt werden.

Jeder Bearbeiter kann sich dann eine eigene Ansicht erstellen mit den auf sich selbst gefilterten Aufgaben. So verliert man nicht die Übersicht über die eigenen Aufgaben.

Wird eine Aufgaben bearbeitet, wird diese per drag&drop im Board weitergeschoben, bis diese erledigt ist oder u.U. auf den nächsten Sprint verschoben werden muss. 

Sollte der hier beschriebene Workflow nicht passen, können einfach weitere Ordner erstellt oder weggelassen werden.

Aufgaben die in den nächsten Sprint kommen, werden einfach in das neue Sprint Projekt verschoben.

Natürlich stehe alle generellen Funktionen wie @Mentions, Timeline, Charts und Widgets zur Darstellung zur Verfügung.

Retrospektive

Nach jedem Sprint sollte eine Retrospektive durchgeführt werden.

Wir empfehlen dies in smenso Cloud durchzuführen, um immer auf ältere Retrospektiven zugreifen zu können - auch projektübergreifend.

Agenda Sprint Retrospektive

1. Was haben wir gut gemacht?
2. Worüber müssen wir reden?
3. Was haben wir gelernt?
4. Was müssen wir künftig anders machen?
5. Was haben wir noch nicht verstanden?

Konkrete Aufgaben werden als Unteraufgaben erfasst und konkreten Personen zugewiesen.