Veröffentlicht am 5. Februar 2026
Tools
Boards
Für unsere Arbeitsorganisation und -umsetzung brauchen wir verschiedene Boards. Diese stehen resp. hängen in unserem gemeinsamen Open-Space-Büro (Projekthomebase) und kommen bei den einzelnen Zeremonien zum Einsatz. Mittlerweile haben wir diese Boards virtuell erstellt, so dass wir auch remote darauf zugreifen und damit arbeiten können.
Das Refinement-Board zeigt alle Stories, die noch verfeinert («refined»), sprich beschrieben und geschätzt werden müssen. Danach gehen sie ins Sprint-Backlog, heisst, sie werden einem zweiwöchigen Sprint zugeordnet.
Das Umsetzungs-Board zeigt den Status eines Sprints an, sprich, wie viele Stories im laufenden Sprint bereits erledigt wurden und in welchem Status sie sich gerade befinden (Backlog, in Progress, in Testing, in Dokumentation oder done). Das Ziel ist, dass sich alle Stories nach Ablauf eines Sprints in «done» befinden.
Das Unconference-Board kommt bei der Planung der Projekttage zum Einsatz. Es dient zur Planung der einzelnen Sessions und visualisiert, wann welche stattfindet. Auf der X-Achse befinden sich die zur Verfügung stehenden Besprechungsräume, auf der Y-Achse die Zeitangaben.
Wir unterscheiden zwischen Product Backlog und Sprint Backlog. Das Product Backlog enthält den gesamten ausstehenden Arbeitsvorrat, ausgedrückt in Form von Stories inkl. entsprechender Aufwandschätzung (Storypoints). Das Sprint Backlog hingegen führt nur die Stories des jeweiligen Sprints auf, für die sich das Delivery-Team verpflichtet hat.
Eine User Story oder kurz Story, ist eine alltäglich formulierte, kurzgehaltene Software-Anforderung aus Sicht der Endanwender. Stories konkretisieren die Release-Ziele, um diese in zweiwöchigen Sprints umsetzen zu können. Nebst dem Kundenmehrwert enthält sie auch eine Aufwandschätzung für die Umsetzung in Form von Storypoints (1 Storypoint = 1 Arbeitstag). Die Beschreibung folgt dabei dem Muster: «Als xy will ich, dass …, damit ….» (bspw. «Als Benutzer will ich, dass im Datumsfeld nur Zahlen eingegeben werden können, damit Falscheingaben verhindert werden.»). Somit wird die Anforderung einheitlich und verständlich formuliert.
Das Refinement (Verfeinerung) findet in den Delivery-Teams statt. Dabei werden die Stories genau beschrieben und mindestens mit der Person, die die Story umsetzt, besprochen. So kann der Arbeitsaufwand für diese Story besser geschätzt und der Inhalt verifiziert werden. Ausserdem werden die Stories beim Refinement priorisiert und einem Sprint zugeordnet.
Prinzipien
Wir arbeiten nach dem Prinzip, dass sich die Entwickler ihre Arbeit selber «pullen» (ziehen) können. Das heisst, man nimmt eine Story zu sich und entscheidet selbst, wie viel Arbeit geleistet werden kann. Bleibt in einem Sprint noch Zeit übrig, können Stories aus einem folgenden Sprint vorgezogen werden, Bugs gefixt oder technische Schulden abgebaut werden.
Niemand wird zur Teilnahme an einem Meeting gezwungen. Dieses Prinzip besagt, dass wenn kein Mehrwert zu einem Meeting beigetragen werden kann, dieses ohne schlechtes Gewissen verlassen werden kann. Wichtig ist jedoch das Wort «patient» (=geduldig). Mindestens zehn Minuten sollte dem Meeting gefolgt werden, bevor man sich entscheidet, es zu verlassen. Umgekehrt darf jedes Teammitglied jederzeit einer Session beiwohnen, selbst wenn auf den ersten Blick inhaltlich nichts dazu beigetragen werden kann.
Bei dieser Sitzung werden im Projektteam Massnahmen diskutiert, die sich auf die Fortführung des Projekts auswirken. Es werden dabei keine perfekten Lösungen gesucht, sondern ein Konsent über den weiteren auszuprobierenden Schritt hergeleitet. Die Teilnahme an dieser Sitzung ist freiwillig, die beschlossenen Massnahmen wirken sich jedoch auf das ganze Team aus.
Time Box beschreibt einen vorgegebenen zeitlichen Rahmen, der eingehalten wird. Bei NewVOSTRA dürfen Sitzungen bspw. nicht länger als 60 Minuten dauern.
Auch in der Entwicklung wird die Time Box angewendet, bspw.: «Arbeite mal einen Tag daran und schaue, wie weit du kommst. Dann entscheiden wir, ob es sich lohnt, dieses Thema so weiterzuverfolgen».
Das Projektteam arbeitet mindestens an den zwei Projekttagen (Mittwoch und Donnerstag) zusammen in unseren Open-Space-Büros (Projekthomebase). Dies ermöglicht eine spontane barrierefreie Kommunikation (möglichst keine E-Mails) und hilft Missverständnisse und Zusatzschlaufen zu vermeiden.