Verwaltung eines Multi-Produkt-Backlogs

Wie lässt sich die Verwaltung eines Backlogs mit mehreren Produkten übersichtlich darstellen, so dass der Product Owner die Backlog-Verwaltung und die Release-Planung mit mehreren Stakeholdern komfortabel und effizient vornehmen kann? Wir haben uns hier zur Strukturierung eines Backlogs mit mehreren hundert Tickets dafür entschieden, einmal den Canvas for JIRA von Comalatech auszuprobieren, der eine Erweiterung von Atlassians JIRA darstellt.

In einem Workshop haben wir eine Matrix aufgespannt, die wir anschließend digital abgebildet haben. Besonders wichtig für die Release-Planung ist dabei die Aufgliederung des Backlogs nach dem MoSCoW-Prinzip. Die Backlogs der einzelnen Produkte werden nach diesem Prinzip eingeteilt in diese Kategorien:

  • Must-have-Anforderungen (sie sind essenziell für die Anwendung und unbedingt umzusetzen)
  • Should-have-Anforderungen (Anforderungen, die nicht zwangsläufig umgesetzt werden müssen, aber dennoch einen hohen Nutzen haben)
  • Could-have-Anforderungen (falls noch Zeit und Budget vorhanden ist)
  • Won’t-have-Anforderungen (Sie sind sinnvoll, aber nicht jetzt)
Canvas for JIRA für die Verwaltung eines Multi-Produkt-Backlogs

Canvas for JIRA für die Verwaltung eines Multi-Produkt-Backlogs

Unterstützung bei der Planung von Releases

Diese MoSCoW-Kategorien sind recht leicht verständlich und machen auch deutlich, auf welchen Teil sich für die Planung der nächsten Releases zunächst fokussiert werden kann. Diese Ansicht hilft also dabei, in einer Release-Planung für die Produkte schnell zu prüfen, was Berücksichtigung finden sollte.

Tickets der Kategorie „Won’t have“ entfernen wir aus dem Backlog, um diesen übersichtlich zu halten. Wir haben aber noch zusätzlich eine Ebene „High Business Value“ zum Einsatz gebracht, mit der zum Ausdruck gebracht werden kann, dass bestimmte Funktionalität (die in Must, Should oder Could liegen kann) ein gutes Verkaufsargument liefern würde.

Visualisierung der Arbeit für den Product Owner

Durch diese Art der Visualisierung wird auch einfach deutlich, wenn Tickets bestehen, die noch keiner Komponente/keinem Produkt zugeordnet wurden oder die noch nicht mit einer Priorität versehen wurden. Dadurch kann der Product Owner einfach sehen, wo er noch aktiv werden muss. In der ersten Spalte befinden sich dazu die „unlabelled“ Tickets, die dann per Drag&Drop einfach in die passende Spalte gezogen werden können.

Sind neue Tickets noch nicht dem richtigen Produkt zugeordnet worden, wird ganz oben eine erste Zeile angezeigt. Hier kann der Product Owner dann ebenfalls tätig werden und die Tickets dem entsprechend passenden Produkt zuordnen.

——–
TIPPS UND TRICKS ZUM PRODUKTMANAGEMENT VON INTERNETANWENDUNGEN
Immer auf dem aktuellen Stand bleiben: Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder den RSS-Feed.

VERANSTALTUNGSHINWEIS: Tools4AgileTeams Konferenz in Wiesbaden

Werbeanzeigen

Softwareunterstützung für Scrum-Teams: JIRA und Confluence

Die Verwendung von Tools ist bei Scrum-Teams ein Thema, an dem sich die Geister scheiden. Die einen schwören darauf, die anderen halten es für überflüssig. Was für alle Teams und Teammitglieder gelten muss, wenn sie Softwareentwicklung mit einem agilen Verständnis betreiben möchten, ist: „Individuals and interactions over processes and tools“ (Agile Manifesto). Die Tools dürfen nicht als Ersatz für den persönlichen Austausch zwischen den Produktentwicklern betrachtet werden. Unter dieser Prämisse sehe ich durchaus einige sehr hilfreiche Anwendungen für Tools. Wie bei der Internetagentur //SEIBERT/MEDIA in den Scrum-Teams mit den Atlassian-Produkten JIRA und Confluence arbeiten, habe ich in einem aktuellen Artikel dargestellt.

Zum Artikel im Blog von //SEIBERT/MEDIA

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Foto: zoonabar

QR-Codes zur Aktualisierung von Taskboards – 7 Fragen an Matt Müller


Wer den Raum eines Softwareentwicklungs-Teams betritt, dass sich die Vorteile der agilen Softwareentwicklung zunutze macht, wird in der Regel eines sehen können – ein Taskboard mit Aufgabenbeschreibungen auf Karten, das vom Team zur Organisation der Aufgaben genutzt wird.
Immer wieder sind Besucher bei uns irritiert über diese Rückkehr zu Tafel und Papier, ausgerechnet in einer Softwareschmiede. Viele Teams setzen dabei neben dem Offline-Taskboard zusätzlich auf eine elektronische Aufgabenverwaltung. Die Verwaltung der Aufgaben an einem Taskboard im Teamraum sorgt für eine hohe Transparenz und macht den Arbeitsfluß in einem besonderen Maße sichtbar. Die Verwaltung von Aufgaben in einem elektronischen System hat ebenfalls ihre Vorteile. So lassen sich dort auch große Mengen von Vorgängen dauerhaft für die spätere Bearbeitung vorhalten, einfach mit Links und Grafiken versehen und es kann eine Anbindung an ein Zeiterfassungssystem erfolgen. Die Verwendung von beidem führt jedoch zu einer Herausforderung: Änderungen am Status einer Aufgabe (z.B. „offen“, „in Bearbeitung“, „geschlossen“) müssen in beiden Systemen, digital und analog, erfolgen.

Umso spannender fand ich es, bei meinem ehemaligen Kollegen Matthias Müller von einer selbst entwickelten Lösung für einen einfacheren Abgleich zwischen Taskboard im Teamraum und elektronischer Aufgabenverwaltung zu lesen.
Matthias hat sich bereit erklärt, mir ein paar Fragen zu seiner Lösung zu beantworten.

Matthias, erzähl‘ uns erst einmal wer Du bist und was Du machst.

Hallo Paul! Ich arbeite als Softwareentwickler bei der Rhein Main Multimedia GmbH in Mainz. Wir sind eine Tochtergesellschaft der Verlagsgruppe Rhein Main und somit als Dienstleister hauptsächlich im Umfeld der Onlineangebote unserer Tageszeitungen im Bereich CMS und allen Randgebieten unterwegs. Im Kern der RMM sind wir neben Online Sales und Projektkoordination ein Team von fünf Kollegen, die sich um die Planung und Umsetzung neuer Projekte und Anforderungen an bestehende Systeme kümmern. Im Bereich der agilen Softwareentwicklung sind wir noch Rookies – wir beschäftigen uns seit Anfang des Jahres damit. Dabei machen wir nicht „Scrum by the Book“, weil dies als alleiniges Toolkit für die Vielzahl der von uns betreuten Applikationen nicht als tauglich erschien, sondern bewegen uns in einer gesunden Mischung der unserer Ansicht nach nützlichsten Komponenten aus Scrum und Kanban.

In den letzten Wochen hast Du in Deinem Blog „any-where“ über eine von Dir entwickelte Lösung berichtet, um einen Abgleich zwischen einem Offline-Taskboard und der elektronischen Aufgabenverwaltung mit trac herzustellen. Wie kamst Du auf die Idee und wie funktioniert Deine Lösung?

Hoffentlich hole ich jetzt nicht zu weit aus. Ich arbeite seit 2010 bei RMM und war bis Ende letzten Jahres in ein großes Projekt mit einem unserer spanischen Dienstleister als technischer Berater involviert. Das Projekt scheiterte leider. Wie ich nun weiß, aufgrund der vielen üblichen Fehler, die man machen kann: Falsche Anforderungsanalyse, fehlende Transparenz, das parallele Arbeiten an vielen Tasks und Komponenten, Terminfixierung statt Qualitätsfixierung, fehlende Prioritäten und der Plan eines Big Bang Releases. Erkannt wurde dies früh, aber leider nicht angegangen aufgrund der politischen Struktur des Unternehmens und des Projekts. Anfang des Jahres beschlossen wir, dass dies so nicht mehr passieren darf. Wir begannen, unsere Arbeitsweise hin zu mehr Agilität und Effizienz zu bewegen. Eine Entscheidung übrigens, die direkt aus dem Team heraus angestoßen wurde und einen wirklich spannenden Prozess folgen ließ, der eine merkliche Verbesserung unserer täglichen Organisation und vor allem der Transparenz aller Aufgaben und Projekte mit sich brachte. Ich will das gar nicht im Detail ausführen. Aber unter anderem hängt in unserem 4-Mann-Büro nun ein großes Taskboard, das über alle Projekte hinweg unsere Tasks erfasst und jeden Morgen in einem Daily Stand-up besprochen wird. Auf der Suche nach einem OpenSource-Tool für agile Entwicklung stieß ich auf Agilo als (recht) brauchbare Erweiterung für Trac. Dieses setzen wir nun ein und brauchten quasi sofort eine einfache Möglichkeit, das Offline-Medium Board mit dem Online-Medium Agilo zu verheiraten. Agilo und Trac bringen von Hause aus keine Unterstützung mit. Deshalb entwickelte ich ein kleines Java-Tool TracPrinter, welches aus einem Applet heraus das Drucken von Task-Cards erlaubt. Mit diesem schafften wir den Weg in die eine Richtung: Aus dem Intranet ans Board.

Nun kommt es bei uns oft vor, dass ein Ticket bearbeitet wurde, in „Done“ auf dem Board verschoben, aber in Agilo nicht aktualisiert wurde. Das ist ärgerlich, weil es neben dem Aufwand des nachträglichen Änderns in Agilo viele zu beantwortende Nachfragen gab, wenn die Tickets in Agilo kontrolliert wurden. Wir brauchten also einen einfachen Weg, Tickets in Agilo schnell schließen zu können. Da quasi jeder Zugang zu einem iPhone oder Android-Gerät mit WI-FI-Zugang zum Intranet hat, dachte ich, dass es das einfachste wäre, über das Smartphone eine Möglichkeit zu schaffen, Tickets in Agilo zu bearbeiten. Als einfachste Lösung schienen hier QR-Codes in Frage zu kommen: Somit wurde TracPrinter erweitert um eine Funktion, welche QR-Codes mit einem hinterlegten internen Link zu einem einfachen PHP-Script auf die Ticket-Karten schließt. Nach Scannen des QR-Codes öffnet der Browser dieses Script auf dem Server im Intranet. Derzeit schließt dieses wirklich nur „hart“ das Ticket. So haben wir erreicht, dass Tickets direkt nach Fertigstellung oder im Daily Stand-Up innerhalb von Sekunden geschlossen werden können.

Wie bewährt sich diese Lösung bei Euch im Praxis-Einsatz?
Die Gesamtlösung mit TracPrinter und der neuen QR-Code-Lösung unterstützt unsere Prozesse recht gut. Wie bei allen Dingen steht und fällt dies natürlich mit der Gewohnheit der User: Man muss natürlich dran denken, den TracPrinter zu nutzen, um ein Ticket, das man gerade erstellt hat, auch ans Board zu bekommen. Hier kommen wir öfter an den Punkt, dass ein Ticket zwar in Agilo ist, aber nicht am Task-Board hängt. Aber wir werden besser. Das korrekte Schließen des Tickets in Agilo wird im Daily Stand-Up mittlerweile abgefragt und im Zweifel direkt per Smartphone geschlossen. Hier haben wir wirklich einen Gewinn.

Welche weiteren Entwicklungspotenziale siehst Du für Deine Lösung?
Noch ist alles eine Sammlung loser Tools: Agilo hat seine eigene URL, der TracPrinter ist unter einer eigenen URL im Intranet erreichbar, ebenso das Script, welches Requests via QR-Codes entgegennimmt. Das klappt natürlich – geplant ist allerdings, alles zusammen in eine Erweiterung für Trac zu überführen, um alles an einer Stelle zu haben und den manuellen Schritt des Druckens von Karten direkt in die Erzeugung von Tickets zu integrieren. Darüber hinaus habe ich ja erwähnt, dass via QR-Code die Tickets hart geschlossen werden: Man kann noch nicht differenzieren, ob ein Ticket done oder invalid ist. Auch eine Schnittstelle zur Kommentarfunktion von Agilo existiert nicht. Da die Lösung aber gut angenommen wird, ist der Plan, ein mobiles Interface für Agilo zu schaffen, das es erlaubt, direkt alle Informationen über ein Ticket abzurufen und eine Möglichkeit zu schaffen, den verschiedenen „Schließmöglichkeiten“ in Agilo gerecht zu werden. Somit kann man noch mehr Zeit vor dem Board statt vor Agilo im Notebook verbringen 🙂 Das wird die Kommunikation über Tickets bestimmt weiter fördern.

Ein dänisches Scrum-Team von Vodafone hat vor einigen Monaten eine Lösung für den Abgleich zwischen JIRA und einem Offline-Taskboard mittels RFID-Technologie vorgestellt und dafür einige Aufmerksamkeit bekommen. Wie siehst Du die QR-Lösung im Vergleich zu einer RFID-Lösung? Was hat mehr Potenzial für die Zukunft?

Ja, die RFID-Lösung ist sehr fancy. Vor allem das automatische Einblenden des Burndown-Charts ist spektakulär und wirklich motivierend! Man sieht in Echtzeit den Effekt der Abarbeitung des eigenen Tickets. Tatsächlich war das Video, das ich im Dezember in Deinem Blog über diese Lösung gesehen habe, durchaus ein Impulsgeber für die Ideen, die hier mit Trac und QR-Codes nun umgesetzt sind. Das Problem, Onlinetools mit Offlinemedien zu synchronisieren, ist im Bereich der agilen Entwicklung sicher an vielen Stellen aktuell. Die Entscheidung, Papier zu nutzen und nicht auf einen „großen Touchscreen“ als digitales Board zurückzugreifen und alles direkt online abzubilden, wird ja bewusst getroffen. Nun sind QR-Codes sehr billig, RFID aber leider nicht. Das ist sicher auch einer der Gründe, weshalb wir auf QR-Codes setzen 🙂 Ich weiß ehrlich gesagt nicht, ob und welche Möglichkeiten es bereits mit QR-Codes für marktführende Tools wie Jira gibt. Ich kann mir aber durchaus vorstellen, dass dies eine tolle Unterstützung für viele Projekte sein kann. Uns nutzt es sehr – und solange nicht jeder die Möglichkeit hat, einen RFID-Scanner hinter sein Board zu hängen, ist dies sicher die effizientere Variante. Wenn das Vodafone-Modell aber in Serie geht, werde ich hier sicher vorschlagen, das zu kaufen 🙂

Wie siehst Du in Zukunft die Entwicklung zwischen elektronischem Taskmanagement und Taskboards in Teamräumen. Was für Möglichkeiten werden sich uns da in den nächsten 5-10 Jahren bieten?

Es dauert sicher nicht lang, bis der erste Anbieter ein elektronisches Hardware-Board für den kommerziellen Vertrieb bereitstellt. Auf welcher Technologie dies basiert, sei mal offen gelassen. Aber ich kann mir sehr gut vorstellen, dass es sehr interessante Lösungen geben wird, die in Richtung der Vodafone-Version gehen werden. Das Problem hier ist m.E. nicht unbedingt die technische Machbarkeit und die Kosten sondern vielmehr die Vielzahl der Produkte im Bereich „Taskmanagement“ und die Eigenarten der agilen Arbeit in Organisationen. Dem gerecht zu werden ist sicher eine Herausforderung für Hersteller. Am Ende ist ein einfaches Whiteboard doch schneller den persönlichen Bedingungen angepasst. Natürlich könnte ein Anbieter speziell für die Schnittstelle zu Jira (oder warum auch nicht Agilo/Trac?) ein solches Board herstellen. Ich bin selbst gespannt, was hier kommen wird. Ob RFID hier eine Lösung ist oder tatsächlich mit QR-Codes gearbeitet wird, die von einem Scanner direkt im Board verarbeitet werden können, ist sicher eine Frage der Kosten. Papier ist billiger als RFID. Aber wer weiß, wie sich das entwickelt.

Zum Schluss noch einmal zum Thema QR-Codes: Werden diese dauerhaft interessant und vielfältig im Einsatz sein oder stellen sie nur einen Übergang zu neuen Technologien und Lösungen dar?

Für mich ist unsere QR-Lösung tatsächlich der erste Fall, wo ich – jenseits von logistischen oder produktionstechnischen Anwendungsfällen – einen persönlichen professionellen Nutzen in QR-Codes sehe. Jetzt nutze ich sie täglich als Unterstützung meiner täglichen Arbeit 🙂 Im Consumerbereich sieht das anders aus: Für Endanwender sind QR-Codes ja schon heute bspw. für Ticketing oder Check-ins vielfältig im Gebrauch. Ihr Gebrauch ist einfach und kostengünstig. Wir arbeiten hier auch an Projekten, in denen QR-Codes im Bereich des Couponings und Location Based Services eine Rolle spielen werden. Somit werden sie uns noch eine Weile begleiten 🙂

Vielen Dank, Matthias!
Sehr gerne!

So sehen die Printouts mit QR-Code dann aus:
QR-Codes zur einfachen Aktualisierung eines Taskboards (Foto: Matthias Müller)

Blogartikel von Matthias Müller zu seinen Erweiterungen für trac:

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Genial: Taskboard und JIRA automatisch abgleichen

Wie cool wäre es, die Vorteile eines Offline-Taskboards mit denen eines Aufgaben-Managementsystems wie JIRA vollständig zu verknüpfen? Wir selbst nutzen beides und sind auch überzeugt davon. Aber ein Nachteil ist offensichtlich: Das Taskboard muss immer offline und in JIRA aktualisiert werden. Jeder Task muss daher zweimal angepackt werden.

Nicht so bei einem Scrum-Team von Vodafone aus Dänemark. Deren ScrumMaster Ole Hojris Kristensen hat eine Lösung mit RFID-Technologie gebaut, bei der die Aktualisierung in JIRA direkt erfolgt, wenn ein Task von einem Status in einen anderen verschoben wird.

Weitere Sprint-Verläufe des Teams können bei YouTube verfolgt werden.

In diesem Präsentationsvideo stellt Ole vor, wie der automatische Abgleich zwischen Taskboard und JIRA funktioniert.

Was haltet ihr von dieser Konstruktion?

Via: Jeff Sutherland

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oder RSS-Feed.

%d Bloggern gefällt das: