Requirements mit Jira

Newsletter — Ausgabe 2021/05

Registrieren Sie sich für den kostenlosen Newsletter 

Aktuelles, Tipps und Erfahrungen rund um #Jira #Requirements #Agile

Themen in diesem Monat

Product Backlog 101

Jira Software: Team-Managed Projects

Events & Weiterbildung

Release Updates

Goodies & Specials

Editorial

Dieser Newsletter wird herausgegeben von Andreas Birk und Software.Process.Management (Impressum)

Product Backlog 101

#Requirements, #Agile

Was ist eigentlich ein Product Backlog? Und was ist bei der Erstellung und Arbeit mit einem Product Backlog zu beachten? Dieser Artikel will Antworten zu diesen wichtigen Fragen des agilen Requirements-Managements geben.

Die Informationen stammen von wichtigen Webseiten zu agilen Methoden. Dort ist jeweils noch wesentlich mehr Inhalt verfügbar. Betrachten Sie den Artikel also auch als Einladung und Empfehlung zur weiteren Lektüre.

Product Backlog

Ein Product Backlog ist eine priorisierte Feature-Liste, die kurze Beschreibungen der gesamten angestrebten Produktfunktionalität enthält. So definiert Mike Cohn es in seinem Blog-Artikel „Scrum Product Backlog“ [1]. Dabei muss man beachten, dass es sich immer um die zukünftig zu entwickelnden Features handelt, die noch nicht für eine Entwicklungsiteration (in Scrum: Sprint) eingeplant sind.

Inhalte eines Product Backlogs sind in der Regel [1]:

  • Features
  • Fehler (Bugs)
  • Technische Maßnahmen (Technical Work)
  • Wissensaufbau (Knowledge Acquisition)

Features werden typischerweise in der Form von User Stories beschrieben.

Die Product Backlog Webseite des LeSS Frameworks weist darauf hin, dass ein Product Backlog Team-übergreifend sein kann [2]: „Mehrere Teams, die gemeinsam das selbe Produkt erstellen, arbeiten von einem einzigen Product Backlog aus, der die gesamte Arbeit definiert, die für das Produkt zu tun ist.“ Es soll also nicht jedes einzelne Team jeweils seinen eigenen Product Backlog besitzen.

Eine weitere gute Einführung zu Product Backlogs ist der Glossar-Eintrag der Agile Alliance [3]. Er betont, dass der Product Backlog die einzige maßgebliche Quelle ist für alles, was ein agiles Team bearbeitet.

Sieht aus wie ein Eisberg

Ein weiterer Blog-Artikel von Mike Cohn behandelt die Struktur von Product Backlogs [4]. Er benutzt die Metapher eines Eisbergs, um eine Dreiteilung der Backlog-Inhalte in Prioritätsgruppen zu empfehlen:

Die Spitze des Eisbergs: Einträge für die nächste Iteration. Sie besitzen die höchste Priorität, und sind konkret und relativ kleinteilig. Sie besitzen die ausreichend Detailinformationen, damit sie in einer einzigen Iteration implementiert, getestet und integriert werden können.

Der restliche über Wasser sichtbare Teil des Eisbergs: Einträge für die weiteren Interaktionen des nächsten Releases. Es handelt sich dabei um zunehmend größere, noch eher ungenau ausgearbeitete und somit weniger detaillierte Einheiten (quasi „grobe Ideen“).

Der große Teil des Eisbergs unter Wasser: Mögliche Themen für weitere Releases. Sie können noch sehr unscharf und vorläufig sein.

Diese Unterteilung sorgt dafür, dass der Fokus effizient auf die nächsten anstehenden Themen und Aufgaben konzentriert werden kann. Also entwickelt sich der Product Backlog auch über die Zeit weiter. Details zu Einträgen im Product Backlog werden schrittweise ergänzt.

Mike Cohn nennt die Faustregel, dass etwa 10 Prozent des Aufwands einer jeden agilen Iteration in die Verfeinerung des Backlogs fließen sollte, um künftige Iterationen vorzubereiten.

Überschaubar und handhabbar

Product Owner sollten immer darauf achten, dass sie den Product Backlog gut handhaben können. Dazu darf er nicht zu groß werden.

Das betont auch Mike Cohn in einem weiteren Blog-Artikel [5]. Dort beschreibt er vier Schritte, um einen Product Backlog klein und handhabbar zu halten:

  • Lösche alle Dinge, die Du doch nie tun wirst
  • Halte Themen, für die Du noch nicht bereit bist aus dem Product Backlog heraus
  • Überprüfe den Product Backlog regelmäßig
  • Ergänze Themen erst, wenn Du wirklich planst, sie recht bald zu tun

Wie erkennt man Themen, für die man noch nicht bereit ist? Mike Cohn nennt als Kriterium, ob man als Product Owner bereit wäre, das Team für Überstunden zu bezahlen, dass sie unbedingt ausliefern können.–Natürlich würde man es aber nie tun und das agile Prinzip der nachhaltigen Geschwindigkeit zu beachten. Aber als Entscheidungskriterium ist diese Frage gut geeignet.

Dinge, die noch nicht reif für den Backlog sind, sollten man also auf einer separaten Liste oder Sammlung führen. Falls man sie doch im Product Backlog führen möchte, sollten sie klar erkennbar sein und den unteren Bereich der Liste bilden.

Web-Links

Die genannten Artikel bieten noch eine Vielzahl weiterer Erklärungen, Tipps und Anregungen. Hier sind die Links zum späteren Weiterlesen und Vertiefen:

[1] Mike Cohn: Scrum Product Backlog
https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/product-backlog

[2] LeSS: Product Backlog at the More with LeSS website
https://less.works/less/framework/product-backlog

[3] Agile Alliance: Product Backlog (Agile Alliance Glossary)
https://www.agilealliance.org/glossary/backlog/

[4] Mike Cohn: Why your Product Backlog should look like an iceberg
https://www.mountaingoatsoftware.com/blog/why-your-product-backlog-should-look-like-an-iceberg

[5] Mike Cohn: Four steps to keep your Product Backlog Small and Manageable
https://www.mountaingoatsoftware.com/blog/four-steps-to-keep-your-product-backlog-small-and-manageable

Jira Software: Team-Managed Projects

#Jira, #Agile

Atlassian hat bei Jira Software die Unterscheidung eingeführt zwischen „Company-Managed Projects“ und „Team-Managed Projects“. Dabei handelt es sich um zwei neue Begriffe für die früheren Projekttypen „Classic“ (Company-Managed) und „Next Gen“ (Team-Managed). Betroffen sind agile Projektkonfigurationen auf Cloud-Instanzen.

Die neue Benennung macht den Unterschied besser deutlich als die alten Begriffe „Classic“ und „Next Gen“. Insbesondere wird so die seit 2018 schrittweise ausgebaute „Next Gen“ Variante klarer positioniert.

Team-Flexibilität und übergreifende Harmonisierung

Mit „Team-Managed Projects“ erleichtert Jira Software den Einstieg insbesondere für kleinere Entwicklungsorganisationen und für einzelne, spezialisierte Teams in größeren Organisationen. Sie können ihre Arbeitsweisen im Tool unkompliziert erstellen und schrittweise weiter ausgestalten. Die nötigen Konfigurationen, etwa neue Issue Types oder Felder erstellen, sind einfach und intuitiv.

Für die Zusammenarbeit in größeren Organisationen ist es wünschenswert, dass Arbeitsweisen über Teams hinweg ausreichend harmonisiert sind. Außerdem sind zentrale Infrastrukturen für das IT-Management vorhanden. Hier sind deshalb „Company-Managed Projects“ in aller Regel die erste Wahl.

Viele fortgeschrittene und umfangreichere Features von Jira Software sind nur im „Company-Managed“ Modus verfügbar.

Interessant kann die zeitweilige Kombination beider Optionen sein: Mit „Team-Managed“ kann man auch neue Arbeitsweisen leicht ausprobieren, um sie später den harmonisierten Rahmen von „Company-Managed“ zu überführen.

Erläuterungen und Anleitungen

Atlassian hat kürzlich Informationsseiten erstellt, die die Unterschiede zwischen „Team-Managed Project“ und „Company-Managed Projects“ gut erläutern, und den Umgang damit beschreiben:

Die Seite „What are team-managed and company-managed projects“ enthält eine Übersichtstabelle mit den Unterschieden und Entscheidungskriterien: https://support.atlassian.com/jira-software-cloud/docs/what-are-team-managed-and-company-managed-projects/

Eine Anleitung zum Umstellen eines Projektes zwischen beiden Modi bietet die Seite „Migrate between team-managed and company-managed projects“. (https://support.atlassian.com/jira-software-cloud/docs/migrate-between-team-managed-and-company-managed-projects/)

Eine solche Umstellung hat aber einige Fallstricke. Daher kann es in vielen Situation besser sein, man wechselt zu passenden Projektmeilensteinen auf ein jeweils zusätzliches neues Jira-Projekt.

Den Einstieg in „Team-Managed“ erläutert die Seite „Get started with team-managed projects“: https://support.atlassian.com/jira-software-cloud/docs/get-started-with-team-managed-projects/

Wenn Sie „Team-Managed“ einmal unkompliziert ausprobieren möchten, dann ist ein einfacher Weg die testweise Nutzung einer kostenfreien Cloud-Instanz (siehe https://www.atlassian.com/software/jira/pricing).

Events & Weiterbildung

Praxis-Knowhow zum agilen Requirements-Management bietet Ihnen der interaktiv gestaltete Online-Workshop am 23. Juni: Agile Requirements mit Atlassian Jira®. Als Mitglied der „Requirements mit Jira“ Community können Sie dafür auch attraktive Rabatte nutzen (siehe „Goodies & Specials“ in Ihrer Newsletter-E-Mail).

Im Juni folgt der nächste Termin in unserer kostenfreien Webinare-Serie. Das Thema am 10. Juni um 11:00 Uhr lautet: Requirements-Management mit Atlassian Jira®

Release Updates

#Jira

Welche Neuigkeiten gibt es aus Requirements-Sicht bei den kürzlichen Produkt-Releases aus dem Jira Ökosystem? Heute: News rund um Jira Software.

Mit der neuen Produktvariante Jira Work Management positioniert sich Atlassian neu für Business-Anwendungen außerhalb von Software-Entwicklung, DevOps und Service-Management. Es handelt sich um eine runderneuerte und neu positionierte Version von Jira Core, die das bisherige Angebot ersetzt.

https://www.atlassian.com/blog/announcements/introducing-jira-work-management

Mit Jira Software Release 8.17 vom 18. Mai 2021 kann in der Data Center Edition die Terminologie zentral gesteuert werden. Administratoren können aktuell die beiden generischen Jira-Begriffe „Sprint“ und „Epic“ systemweit anders belegen. Das ermöglicht es insbesondere, die Jira-Terminologie an die Konzepte und Formulierungen des Scaled Agile Framework (SAFe®) anzupassen. Dort spricht man von „Iteration“ und „Feature“, während „Epic“ eine weitere, von Jira abweichende Bedeutung besitzt.

https://confluence.atlassian.com/jirasoftware/jira-software-8-17-x-release-notes-1063559166.html

Auf Jira Software Cloud gibt es Performance-Verbesserungen zu verkünden: Backlogs und Boards laden nun deutlich schneller.

https://www.atlassian.com/blog/platform/better-performance-in-cloud

Goodies & Specials

10 % Rabatt für Online-Workshop

Für den Online-Workshop „Agile Requirements mit Atlassian Jira®“ am 23. Juni 2021 können Sie einen Rabatt von 10 % nutzen. Den Aktionscode finden Sie in ihrer Newsletter-E-Mail. Hier geht es zur Workshop-Buchung …

Erweiterter Rabatt für Online-Seminare

Als Mitglied dieses Newsletters buchen Sie die meisten unserer Online-Seminare dauerhaft zum Frühbucher-Tarif (entspricht 8 % Rabatt), zu Themen rund um Requirements-Tools, agiles Requirements-Management und agiles Software-Produktmanagement. Den aktuell gültigen Rabatt-Code finden Sie in ihrer monatlichen Newsletter-E-Mail unter dieser Rubrik „Goodies & Specials“.

Buchtipp

J. Patton, User story mapping: Discover the whole story, build the right product. Sebastopol, CA: O’Reilly & Associates, 2014.

Das Buch zu User Story Mapping behandelt viele Facetten des agilen Requirements-Managements, speziell wenn man für ein zu entwickelndes Produkt die Anforderungen für den initialen Product Backlog zusammenstellen will.

Eine sehr gute erste Einführung bietet auch der Blog-Artikel zu User Story Mapping.

Editorial

Atlassian fährt zügig fort, seine Positionierung weiter zu entwickeln. Nachdem kürzlich mit Jira Service Management das frühere Jira Service Desk neu aufgestellt wurde, ist nun auch das bisherige Jira Core runderneuert als Jira Work Management an den Start gegangen.

Bei Jira Software Cloud sind die bisherigen agilen Projektvarianten „Classic“ und „Next Gen“ als „Company-Managed Projects“ und „Team-Managed Projects“ neu und wesentlich klarer aufgestellt. Mit „Team-Managed“ erhalten einzelne Teams und kleinere Organisationen einen direkten und unkomplizierten Zugang zu Jira. „Company-Managed“ zusätzlich weitergehende Möglichkeiten und Team-übergreifende Harmonisierung für größere Organisationen.

Auf der methodischen Seite schauen wir in dieser Ausgabe auf das Thema „Product Backlog“. Der Schwerpunktartikel fasst die essenziellen Aspekte zusammen und empfiehlt weiterführende Lektüre. Der Buchtipp zu „User Story Mapping“ ist auch besonders dann interessant, wenn man den Backlog für ein Produkt neu erstellen möchte.

—Andreas Birk

Impressum

Newsletter „Requirements mit Jira“, Ausgabe 2021/05

Aktuelles, Tipps und Erfahrungen rund um #Jira #Requirements #Agile

Dr. Andreas Birk (ViSdP), Software.Process.Management

Usedomstr. 15, 70439 Stuttgart

https://swpm.de, Fon +49 711 6645 324, newsletter@swpm.de

USt-IdNr de814817588