Was können wir von Scrum lernen? – Teil 2: Artefakte

Was die Planung von Aufgaben angeht, so schlägt Sutherland, einer der Autoren des Agilen Manifests, vor, „eine Liste mit allem zu erstellen, was in einem Projekt getan werden kann, und diese dann zu priorisieren“ (Sutherland, Scrum 201), den Backlog. Der Backlog ist ein nützliches Instrument, um einen Überblick über die noch zu erledigenden Aufgaben und Punkte zu erhalten. Um einen guten Backlog zu erhalten, muss er gepflegt werden, d. h. die Elemente darin müssen nach Prioritäten geordnet, organisiert und proaktiv verwaltet werden.

Backlog Elemente, User Stories und Epics

Backlog-Elemente werden in der Regel als User Stories oder Epics formuliert. Nicht jeder Punkt ist zu Beginn eines Projekts ausreichend detailliert definiert. Ein Epic ist eine große, eher vage User Story, bei der die Anforderungen nur skizziert sind, weshalb sie hinsichtlich ihres Umfangs oder ihrer Komplexität nicht abgeschätzt werden können. Epics könnten „Einreichung einer Klage“, „Unternehmensgründung“ oder „Verkauf eines Hauses“ sein. In diesen Epics sind die einzelnen Punkte noch nicht ausreichend aufgeschlüsselt, aber sie dienen dazu, einen allgemeinen Überblick über das Projekt zu erhalten.

Wenn möglich, können die Backlog-Elemente zu Beginn des Projekts in allen Einzelheiten definiert werden, aber es liegt in der Natur von Agile, dass sich Anforderungen ändern und man flexibel bleiben muss. Einige Elemente werden erst später im Projektverlauf definiert, wenn alle Informationen vorliegen. Wenn es sich bei dem Epic beispielsweise um „eine rechtsverbindliche Gerichtsentscheidung“ handelt, ist zu Beginn noch nicht klar, ob es eine Entscheidung, einen Vergleich oder eine oder mehrere Rechtsmittel geben wird. Diese Punkte werden nach Bedarf hinzugefügt und/oder geändert.

Eine User Story ist das Element, das das Szenario oder die Situation beschreibt, in der dieses Element verwendet wird, sowie das „Was“, „Für wen“ und das „Warum“, und schlussendlich seinen Wert (Wolf/Solingen/Rustenburg, Die Kraft von Scrum: eine inspirierende Geschichte über einen revolutionären Projektmanagementansatz ; [Inspiration zur revolutionärsten Projektmanagement-Methode] (2012) 131).

Eine Möglichkeit, eine User Story zu formulieren, ist: „Als ROLLE möchte ich BESCHREIBUNG, damit, ZWECK/NUTZEN„. Die „Rolle“ kann ein Benutzer, ein Systemadministrator, etc. sein. In der „Beschreibung“ wird die Funktionalität oder das Ziel beschrieben. Am schwierigsten zu definieren ist im juristischen Zusammenhang der „Nutzen„. Das bedeutet nicht, dass der Kunde keinen Nutzen aus einer Rechtsdienstleistung zieht, aber die Formulierung muss widerspiegeln, dass ein Nutzen nach Abschluss eines Projekts entstehen könnte oder dass ein Nutzen darin besteht, dass etwas nicht geschieht, im letzteren Fall wäre dieses Element nie abgeschlossen.

Die User Story für einen Vertrag könnte zB lauten: „Als Geschäftsführer möchte ich Standard-AGBs haben, um Verträge, die zu meinem Unternehmen und Geschäftsmodell passen, standardisiert abschließen zu können.“

Anwaltliche Dienstleistungen als Element haben nicht „Funktionen“ wie Software, bei der eine User Story leicht beschrieben werden können. In vielen Fällen wird die User Story eher dem Epic entsprechen, da einige Aufgaben einfache To-Dos sind. Nach den Scrum-Prinzipien ist es aber das Ziel, ein wertvolles Inkrement, dh eine User Story, die die Definition of Done erfüllt, am Ende eines Sprints zu haben.

Die Verwendung von User Stories in juristischen Projekten wird oft nicht so gut funktionieren wie in der Softwareentwicklung, aber auf strategischer und projektzielbezogener Ebene kann die Formulierung dieser Stories der Anwält:in helfen, die Motivation der Mandant:innen einzuschätzen, was die Kommunikation verbessert und bei der Wahl einer juristischen Strategie hilft.

Story Points & Schätzung

Story Points werden häufig als Grundlage für die Schätzung der Größe eines Elements herangezogen. Sie sind ein abstraktes Maß für die Komplexität. Ein Kritikpunkt an Story Points ist, dass sie nicht das Risiko eines Elements erfassen, wie z.B. das Risiko einer Verzögerung oder Dringlichkeit (Reddy, The Scrumban [r]evolution 143).

Zwei Methoden zur Schätzung sind Scrum Poker und T-Shirt Sizing; die Schätzung wird von den Teammitgliedern durchgeführt. Unterschiedliche Schätzungen im Team sind kein Problem, sie müssen nur diskutiert werden, um sicherzustellen, dass das Team nichts übersehen hat. Die Gründe für die unterschiedlichen Einschätzungen und das Lernen daraus sind entscheidend, zB wurden andere Inhalte und Aufgaben angenommen.

Definition of Done

Um ein Element abzuschließen, wird die User Story an der Definition of Done (DoD) gemessen. In der Softwareentwicklung kann diese Projektübergreifend einheitlich sein, und enthält beispielsweise Softwaretests; bei juristischen Aufgaben ist diese schwerer zu definieren. Es sollten drei Aspekte berücksichtigt werden: der Standpunkt der Mandant:innen (was wollen diese?), der Standpunkt der Anwält:in (z. B. Abwägung der Haftung oder Erreichen der Kanzleistandards) und die rechtlichen Anforderungen (z. B. vertraglich oder gesetzlich). Infolgedessen reicht die „Anforderung“, dass der Mandantin ein Element prüft und akzeptiert, möglicherweise nicht aus. Bei der Definition eines Elements muss ein Gleichgewicht zwischen dem grundlegenden Inhalt einer Aufgabe, der möglicherweise nichts über die Qualität aussagt, und den Anforderungen der Mandant:innen und Anwält:innen hergestellt werden. Die Anforderungen der Mandant:innen können wie Akzeptanzkriterien in die DoD aufgenommen werden. Dies trägt auch dazu bei, den Umfang einer Aufgabe zu, und hilft dabei, im Falle einer möglichen Haftung die erforderliche Dokumentation für die Anwält:in zu erstellen.

In den Arbeitsabläufen zwischen Anwält:innen und ihrem Team hilft eine detaillierte DoD auch die Erwartungen zu definieren, und verbessert schließlich auch die Lernkurve des Teams und die Qualität der Ergebnisse.

DoD für einen Vertrag:

• Allgemeine Klauseln werden verfasst
• Formatierung und Stil werden angepasst
• Vertragsparteien, Ansprechpartner und Unterzeichner sind eingetragen
• Die Verpflichtungen der Parteien sind definiert
• Der kommerzielle Rahmen ist definiert
• Das Geschäftsmodell der Mandantin wird umgesetzt
• Der Vertrag ist ausgewogen und fair, um die Beschwerden der Vertragspartner zu minimieren
• Anwaltliche Überprüfung
• Überprüfung und Genehmigung durch die Mandantin
• Übermittlung des Vertrags an die andere Partei
• Vertragsverhandlungen (dieser Punkt muss idR ebenfalls auf mehrere Punkte aufgeteilt werden)
• Unterzeichnung des Vertrags

Schließlich ist klarzustellen, dass einige Anforderungen nicht oder nur in besonderen Fällen in eine DoD aufgenommen werden sollten, weil sie ein sehr großes Haftungsrisiko für Anwält:innen darstellen können. Diese sind zum Beispiel:

• Gewinnen eines Rechtsstreits (kann nur in den seltensten Fällen zugesagt werden)
• Abschluss eines Vertrags (Dritte können nicht berücksichtigt werden)
• Unanfechtbarkeit von Klauseln/Bedingungen (Änderungen der Rechtsprechung sind nicht vorhersehbar)

Autorin: Mag. Katharina Bisset, MSc ist selbstständige Rechtsanwältin in NÖ, CEO und Co-Founderin der LegalTech Unternehmen NetzBeweis GmbH und der Nerds of Law. Davor war sie mehrere Jahre in großen IT-Unternehmen tätig. Ihre Spezialgebiete sind IT-, IP-, Medien- und Datenschutzrecht. Zusätzlich zur juristischen Ausbildung hat sie einen Master of Science in Engineering in Business Process Management and Engineering. Sie ist darüber hinaus Disziplinarrätin in der RAK NÖ, Mitglied des Arbeitskreis IT und Digitalisierung des ÖRAK und Lektorin auf der FH Wiener Neustadt und der FH des BFI Wien. Katharina Bisset ist Autorin des Buchs: Agile Lawyer – Implementing Agile Principles in the Attorney-Client Relationship

- WERBUNG -