Sparv Blog

Das Logbuch mit Dokumentationen und Neuigkeiten von den Menschen hinter Sparv.

Unsere Definition eines Sprints

Eines unserer Ziele bei der Entwicklung von Sparv ist es schnell und agil zu entwickeln. Wir bauen Sparv aktuell als privates Sideproject neben dem Beruf bzw. Studium auf und müssen deshalb immer wieder mit unvorhergesehenen Anpassungen in unserer zeitlichen Planung rechnen.

Um nicht in die Falle übermäßiger Planung oder einer stockenden Zusammenarbeit zu gelangen, haben wir uns gleich zu Beginn dazu entschieden, die Entwicklung nach einem bestimmten Muster anzugehen.

Unser Grundgerüst basiert dabei auf Sprints, die eine flexible Länge haben (standardmäßig zwei Wochen) und in denen ganz bestimmte Aufgabenpakete umgesetzt werden sollen. Neben dieser zeitlichen Einteilung haben wir im gleichen Rhythmus, zum Ende eines jeden Sprints, ein persönliches Treffen gelegt, um alle anfallenden Fragen, Anregungen und kommende Aufgaben abzusprechen. Des Weiteren schließen wir den vergangenen Sprint bei Treffen mit einer Review und Retro ab und kontrollieren so unsere erarbeiteten Lösungen gemeinsam.

Alles hat einen Anfang

Wenn wir jetzt einmal tiefer in unsere eigene Definition eines Sprints eintauchen müssen wir zu Anfang über unseren Ideenpool und das Backlog sprechen. Diese zwei Bereiche sind bewusst getrennt und haben in unserem Trello Board, dass wir zur visuellen Verwaltung unserer Tasks verwenden, eine besondere Bedeutung.

Der Ideenpool ist ein allgemeiner Sammelort für alle Arten von Ideen, die wir im Hinterkopf behalten möchten oder gezielt im nächsten persönlichen Meeting ansprechen wollen. Ein Tagespunkt bei jedem persönlichen Meeting ist es nämlich, alle Einträge aus dem Ideenpool einmal anzusprechen und zu schauen, ob diese Einträge noch aktuell sind bzw. was damit als nächstes geschehen soll.

Wenn ein Eintrag im Ideenpool als valide oder interessant erachtet wird, dann kann es gut sein, dass dieser als Nächstes in unser Backlog verschoben wird. Das Backlog ist für uns mehr oder weniger eine lange Liste an Aufgaben oder Features, die wir in nächster Zeit angehen werden, offen ist lediglich noch der genaue Zeitpunkt der Umsetzung.

Talk, Talk, Talk

Neben der reinen Aufbereitung und Dokumentation von Ideen und kommenden Aufgabenpaketen müssen wir vor der eigentlichen Umsetzung natürlich die einzelnen Sprints noch gemeinschaftlich planen. Dies geschieht zuallererst in einer kurzen Vorplanung, in der kommende Aufgabenpakete in die Spalte “Next Up” verschoben werden, um eine klarere Aufteilung für die kommende Sprintplanung zu signalisieren.

Die eigentliche Planung an sich ist jedoch relativ simple. Im eigentlichen Sinne sprechen wir gemeinschaftlich über die zeitlichen Freiheiten in der kommenden Zeit des Sprints und versuchen die Aufgabenpakete den zeitlichen Möglichkeiten anzupassen. Wenn die Planung abgeschlossen ist, werden alle Aufgabenpakete, die es in den kommenden Sprint geschafft haben, in die Spalte “Current Sprint” verschoben.

Während des Sprints gibt es noch Spalten wie “In Progress” und “Review”, die mehr oder weniger den aktuellen Status der einzelnen Aufgabenpakete transparenter signalisieren soll. Neben dieser Darstellung ist es an Arbeitstagen eines jeden Einzelnen ebenfalls Pflicht, eine kurze Statusmeldung in unseren Slack Channel zu posten, um den jeweils Anderen auf dem aktuellen Stand zu halten. Gerade diese Statusmeldung haben sich bei uns in der letzten Zeit für äußerst hilfreich erwiesen, da wir so selbst über den kurzen Zeitraum eines Sprints nie das Gefühl haben nicht wirklich zu wissen, an welchem Problem der Andere gerade arbeitet und wo man ihn vielleicht unterstützen kann.

Zurückblicken und lernen

Wie zuvor schon erwähnt haben wir nach jedem Sprint ein persönliches Meeting. In diesem Meeting sprechen wir, in der sogenannten “Review”, über alle Aufgabenpakete des vergangenen Sprints. Im Prinzip stellt jede Person seine Ergebnisse vor und man schaut gemeinsam, ob diese Ergebnisse den Kriterien aus dem Aufgabenpakete genügen und unsere Definition of Done eingehalten wurde - denn nur dann gilt ein Aufgabenpaket als gelöst.

Nach der Review gehen wir in eine kurze Retro über und schauen auf den Sprint aus einer persönlichen Perspektive zurück. Diese Methodik scheint evtl. etwas unkonventionell, hat bei uns aber schon gute Ergebnisse wie z.B. die schon angesprochenen Statusmeldungen hervorgebracht. Insgesamt liegt für uns der Mehrwert einer Retro in dem frühen Ausmerzen von Kommunikationsproblemen und kleinen Stolpersteinen im Prozess, die man in einem Gespräch aus der persönlichen Sicht oftmals gut erkennen kann.

Nach all diesen Schritten und einer abgeschlossenen Review und Retro geht es für uns noch an die Dokumentation dieser Punkte. Dies machen wir zum Einen in Stichpunkten in Dropbox Paper und zum Anderen öffentlich als Podcast und als Blogpost. Auch wenn die Dokumentation teilweise zeitintensiv erscheint und so ein bisschen gegen unsere Grundprinzipien spricht, so haben wir großen Gefallen an der öffentlichen Kommunikation unserer Fortschritte gefunden und sehen es auch aus einer persönlichen Sicht als Konservierung dieser interessanten und spaßigen Fahrt während der Entwicklung von Sparv.

Und nun?

Im Groben ist das also unsere Definition eines Sprints bei der Entwicklung von Sparv. Wir beide haben kein wirklich tiefgreifendes Wissen in Methodiken beim Thema Projektmanagement, versuchen jedoch ein bisschen unsere Erfahrungen in einen kleinen aber schnellen Prozess zu gießen. In unserer Definition haben wir bewusst auf die typischen Schlagwörter wie Scrum, Kanban usw. verzichtet, auch wenn wir einige Teile aus den verschiedensten Projektmanagementmethodiken verwenden. Hier ging es mehr darum einen kleinen Überblick zum “Status quo” aufzuzeigen und in einem späten Zeitpunkt eventuell nochmal darauf zurückzukommen und die “Learnings” zu unserem Prozess einfließen zu lassen. Denn darum geht es am Ende auch - an einem Punkt anzufangen, zu lernen und den Prozess wieder besser zu machen.

Profilbild von Jan Früchtl

Jan Früchtl

Hi! Ich bin die eine Hälfte von Sparv und arbeite hauptsächlich als Product Designer daran, Sparv besser und verständlicher zu machen.

Mail Twitter