In JIRA Software hält eine neue Form von Berechtigungen Einzug: Sprint-Berechtigungen zur Verwaltung von Sprints. In diesem Artikel diskutieren wir die Intention dieser neuen Funktion und zeigen, wie Sprint-Berechtigungen Teams helfen, die Planung und das Tracking der Arbeit zu vereinfachen, Overhead abzubauen und Risiken zu minimieren, da sogenannte Single Points of Failure abgeschafft werden können und eine Umgebung entsteht, in der das ganze Team agiler sein kann.
Klassische Berechtigungen in JIRA Software
Um zu verstehen, wie Sprint-Berechtigungen funktionieren, sollte man sich erst einmal das Konzept der Berechtigungen grundsätzlich ansehen. In JIRA Software bestimmen Berechtigungen, was Nutzer sehen und tun können, und sie beeinflussen die Art, wie ein jeder Nutzer arbeitet, sofern man nicht gerade Admin ist. Berechtigungen gibt es auf diversen Ebenen – von der Frage, wer ein neues Projekt anlegen kann, über die Festlegung, wer in einem bestimmten Vorgangstyp kommentieren darf, bis hin zum Recht, einen Workflow zu verändern. Die hierarchische Sicht auf Berechtigungen gestaltet sich so:
- Globale Berechtigungen: Sie gelten für JIRA Software als Ganzes und nicht für individuelle Projekte (beispielsweise, ob User andere Nutzer sehen können).
- Projektberechtigungen: Diese sind Berechtigungsschemata organisiert und gelten für Projekte: Wer kann z.B. Vorgänge im Projekt sehen, erstellen, editieren oder zuweisen? Berechtigungen auf Projektebene helfen festzulegen, was Nutzer in einem Projekt tun dürfen.
- Vorgangsberechtigungen: Sie beziehen sich auf die Sichtbarkeit einzelner Tickets für Teammitglieder oder bestimmte Rollen. Beispielsweise können Vorgangsberechtigungen dazu genutzt werden, Vorgangstypen aufzusetzen, die nur Projektadmins sehen können.
In dieser Hierarchie fehlt nun etwas: Sprint-Berechtigungen, die man sich auch als Sprint-Verantwortlichkeiten denken kann. Historisch waren Sprint-Berechtigungen auf Projekt- und globale Admin-Berechtigungen limitiert. In vielen Teams hat sich das auf der Rollenebene manifestiert und darin, dass das Team auf jemanden wie einen Produktmanager oder Teamleiter angewiesen war, der neue Sprints anlegt oder künftige Sprints bearbeitet.
In viele Teams gibt es diese Personenrollen auch tatsächlich. Aber ungeachtet dessen ist es nicht sinnvoll, dass nicht das gesamte Team solche grundlegenden Verantwortlichkeiten wahrnehmen kann: Zu agilen Teams gehören Cross-Funktionalität und geteilte Ownership. Diese Berechtigungen waren Teil der Projektrechte eines Administrators, um Risiken zu minimieren, aber die Notwendigkeit, Probleme im Hinblick auf Sprint-Verantwortlichkeiten erst eskalieren zu müssen, ist für Teams belastend, unflexibel und bremsend.
Ist der Produktmanager oder Teamleiter nicht im Haus, muss dass Team, das z.B. einen Sprint schließen will, warten, bis er zurückkommt (oder eine andere Person mit den entsprechenden Rechten auftreiben). Um hier Abhilfe zu schaffen und um dem mehr Kontrolle dahingehend zu bieten, wie es arbeitet, hat Atlassian Sprint-Berechtigungen eingeführt. In JIRA Software heißt dieses Feature Sprint verwalten.
Sprint-Verantwortlichkeiten und Sprint-Verwaltung
Die neuen Sprint-Berechtigungen lösen die oben genannten Probleme weitgehend durch diese Möglichkeiten: Erstens werden Teams in der Lage versetzt, besser zu organisieren, wie sie mit Sprints arbeiten. Zweitens entsteht eine neue Vertrauensebene dahingehend, wie Teams und individuelle Teammitglieder Sprint-Verantwortlichkeiten angehen.
Die folgenden Möglichkeiten bieten die diese Sprint-Verantwortlichkeiten:
- Sprints erstellen
- Sprints starten
- Sprints fertigstellen
- Sprint-Informationen editieren (Name und Daten)
- Sprints neu ordnen (zurzeit nur für künftige Sprints)
- Sprints löschen (zurzeit nur künftige Sprints)
- Sprints wiedereröffnen
- Den Sprint-Footer bewegen
Wer bereits mit Berechtigungen vertraut ist, dem wird die obige Liste bekannt vorkommen, denn das sind im Grunde die bestehenden Admin-Projektberechtigungen. Für wen Berechtigungen neu sind, der kann sich die Verwaltung von Sprints als Türöffner in eine agilere Welt des Teams vorstellen.
Best Practices für Sprint-Berechtigungen
Es ist sinnvoll, granular darüber nachzudenken, wie das Team mit Sprints arbeitet. (Hinweis: Mit diesem neuen Feature wird jeder, der Admin-Rechte für das Projekt hat, automatisch auch berechtigt, Sprints zu bearbeiten.) Brauchen Sie einen Projektadministrator als Gatekeeper für das Starten und Stoppen von Sprints? Oder soll das einer Gruppe von Scrum Mastern überlassen werden?
Für Letzteres spricht, dass viele Teams mit Dienstleistern wie externen Scrum Mastern oder Agile Coaches zusammenarbeiten. Wenn solch eine Person berechtigt sein soll, die Sprint-Informationen zu editieren, nicht aber, Versionen oder Komponenten in einem Projekt zu verändern, können ihr Sprint-Berechtigungen eingeräumt werden, um ihren Einfluss auf das Projekt als Ganzes zu minimieren.
Nicht jedes Team arbeitet auf diese Weise, aber dieses Beispiel bietet eine Vorstellung davon, wie man Sprint-Berechtigungen sinnvoll nutzen kann: User erhalten die Möglichkeit, Sprints wiederzueröffnen oder fertigzustellen, ohne die Projektinfrastruktur ändern zu können. In anderen Organisationen erhält das gesamte Team die entsprechenden Rechte, weil das Unternehmen ihm vertraut, das Richtige zu tun.
Diese neuen Berechtigungen helfen dem gesamten Team, mehr Ownership für den Sprint zu übernehmen, an dem die Mitglieder tagaus, tagein arbeiten. Aber sie unterstützen auch Projekt- und globale Admins: Die fein granularen Kontrollen sind geeignet, viele Support-Anfragen zu vermeiden.
Grundsätzlich sollten Sie schauen, wo Berechtigungen Ihr Team bremsen und inwiefern diese neue Ebene das Team besser dabei unterstützen könnte, effizient zu arbeiten.
Wenn eine neue Instanz von JIRA Software aufgesetzt wird, sind die Sprint-Berechtigungen per Voreinstellung für alle Projekte aktiviert und jeder User hat die Möglichkeit, die oben beschriebenen Sprint-Verantwortlichkeiten wahrzunehmen. Das ist vor allem prima, wenn neue Teams und/oder neue Teammitglieder hinzukommen.
Sprint-Berechtigungen für eine bessere agile Software-Entwicklung
Durch diese neue Berechtigungsebene, die Sprints und Boards enger miteinander verknüpft, schiebt JIRA Software agile Prinzipien in den Vordergrund. Sprints sind Kernbestandteile von Agile, und das gilt für alle damit verbundenen Aktivitäten: Planning, Standups, Reviews usw. Alle diese Teamaktivitäten hängen in bestimmten Kontexten mit Sprint-Berechtigungen zusammen, sofern das Team intensiv mit JIRA Software arbeitet.
In einem Sprint-Planungsmeeting muss das Team in der Lage sein, den Sprint-Footer zu nutzen, um Arbeit zu beschätzen, und wenn es damit fertig ist, muss es einen Sprint starten können. Wenn ein Sprint läuft, muss das Team die Fähigkeit haben, Sprint-Infos wie Namen und Daten bearbeiten. Wenn ein Sprint versehentlich oder verfrüht geschlossen worden ist, muss es ihn wiedereröffnen können. Die Möglichkeit, Sprints zu verwalten, beseitigt viele Blocker, die Teams behindern.
Die neuen Sprint-Berechtigungen werden in zwei Releases ausgeliefert. Das erste Release, das in JIRA Software Cloud bereits live ist und für die Server-Version in Kürze kommt, beinhaltet die Liste mit Sprint-Verantwortlichkeiten, die oben behandelt wurde. Das zweite Release wird dem Team schließlich mehr Flexibilität beim Hinzufügen und Entfernen von Vorgängen eröffnen.
Wir sind Ihr JIRA-Partner
Haben Sie Fragen zu JIRA Software? //SEIBERT/MEDIA ist offizieller deutscher Vertriebspartner von Atlassian und einer der größten Atlassian Experts weltweit. Wir unterstützen Sie gerne bei allen Aspekten rund um eine Einführung und produktive Nutzung der unterschiedlichen JIRA-Deployments in Ihrem Unternehmen – von der strategischen Beratung und Planung über die Lizenzierung, Implementierung und Anpassung bis hin zur Aktivierung der Mitarbeiter und der Optimierung der Nutzung.
Atlassian JIRA wird von drei neuen Standalone-Produkten abgelöst: JIRA Software, JIRA Service Desk und JIRA Core
JIRA Software 7: Die effiziente und schlanke Sidebar
88 Argumente für JIRA
JIRA-Projekte: Strategie, Struktur, Taktik
Stolperfallen bei der JIRA-Einführung
Wie Mitarbeiter und Projektmanager mit JIRA arbeiten sollten
