Von der Zahl zum Gespräch: Wie ein agiles Ritual seine eigentliche Stärke entfalten kann.
Wer Planning Poker nur als Schätzwerkzeug versteht, verpasst seinen größten Wert: das Gespräch. Denn häufig sind es nicht die Zahlen, sondern die Diskussionen, aus denen Klarheit, Verständnis und konkrete Unteraufgaben hervorgehen – besonders bei verteilten Teams, die Planning Poker online nutzen.
Planning Poker hat einen festen Platz in der agilen Welt. Kaum ein Team, das sich nicht regelmäßig mit Karten in der Hand über Schätzungen austauscht – sei es vor Ort oder über ein Planning-Poker-Tool online. Meist mit einem Ziel: eine Zahl zu finden. Doch was wäre, wenn diese Zahl nebensächlich ist? Wenn Planning Poker online nicht der Planung, sondern der Erkenntnis dient?
Tatsächlich wird immer öfter hinterfragt, ob das Schätzen von Story Points im traditionellen Sinne noch zeitgemäß ist. Die Kritik kommt nicht von außen, sondern aus der agilen Community selbst. Teams berichten, dass sie zwar regelmäßig schätzen – sich aber kaum besser verstehen. Dass die Planung zwar detaillierter, aber nicht klarer wird. Und dass das eigentliche Ziel – ein gemeinsames Verständnis – auf der Strecke bleibt.
Vom Werkzeug zur Routine
Planning Poker ist ursprünglich kein Selbstzweck. Es sollte helfen, die subjektive Einschätzung einzelner Teammitglieder sichtbar zu machen, um daraus eine kollektive Intuition zu formen. Stattdessen ist in vielen Teams – insbesondere beim Planning Poker online – ein Ritual entstanden: Karte zeigen, Diskussion abwarten, Mittelwert finden, fertig.
Dabei liegt die eigentliche Kraft nicht in der Zahl, sondern in der Reibung. Wenn jemand eine 2 legt und eine andere Person eine 13, steckt dahinter nicht Uneinigkeit, sondern Unterschiedlichkeit. Unterschiedliche Sichtweisen, Erfahrungen, Sorgen – und manchmal auch blinde Flecken.
Die heimliche Hauptdarstellerin: Das Gespräch
Wirklich hilfreich am Planning Poker ist oft gar nicht die Zahl, die am Ende steht. Sondern der Weg dorthin. Die Diskussion. Die Rückfragen. Die kritischen Stimmen. Es zwingt das Team dazu, eine Story gründlich durchzudenken – und das ist vielleicht die wichtigste Aufgabe im gesamten Sprintvorbereitungsprozess.
Gerade bei verteilten Teams, die Planning Poker online nutzen, ist das strukturierte Gespräch von unschätzbarem Wert. Wer ein Planning-Poker-Tool sucht, das diese Diskussionen besonders unterstützt und fördert, findet mit Agile Casino eine passende Lösung – entwickelt speziell für Teams, die mehr wollen als nur eine Zahl. Es bringt Fokus, Gemeinsamkeit und – vor allem – Klarheit.
In dieser Hinsicht ist Planning Poker ein trojanisches Pferd: Unter dem Deckmantel der Aufwandsschätzung bringt es das Team dazu, implizites Wissen sichtbar zu machen und Lücken zu erkennen.
Oft fallen in diesen Momenten Sätze wie:
„Brauchen wir da nicht noch eine Abfrage an das andere System?“
„Wer macht eigentlich das Monitoring?“
„Sollten wir das nicht in zwei Stories aufteilen?“
Das sind keine Schätzfragen – das sind Erkenntnisse. Und sie führen dazu, dass die tatsächliche Umsetzung klarer, realistischer und koordinierter wird.
Konkrete Unteraufgaben entstehen
Je genauer das Team in der Diskussion wird, desto greifbarer wird die Arbeit. Idealerweise entstehen aus einer guten Planning-Poker-Runde direkt konkrete Unteraufgaben:
API-Endpunkt analysieren und Dokumentation sichten
Monitoring-Alarm für neuen Service konfigurieren
Fallback-Szenario bei Fehler definieren
UX-Detail mit Design-Team abstimmen
Testdaten vorbereiten
Diese Unteraufgaben sind selten Teil der ursprünglichen Story-Beschreibung – sie entstehen erst im Gespräch. Und gerade deshalb ist dieses Gespräch so wertvoll.
Vom Messen zum Verstehen
Natürlich bleibt Aufwandsschätzung wichtig. Aber sie ist kein Selbstzweck. Eine Zahl nützt wenig, wenn sie auf einem brüchigen Verständnis basiert. Planning Poker stellt dieses Verständnis in den Mittelpunkt – und erzeugt dabei eine neue Dynamik: Eine, die nicht durch Velocity getrieben ist, sondern durch Qualität.
Denn eine gute Story ist keine, die leicht schätzbar ist. Eine gute Story ist eine, die bereit ist, zu überleben – Diskussion, Zweifel und Überprüfung. Sie muss „durchs Team“ – im besten Sinne.
Warum das jetzt wichtig ist
In einer Zeit, in der viele agile Rituale routinierter, aber nicht wirksamer werden, braucht es neue Impulse. Planning Poker – besonders online – ist kein Tool zur Aufwandsermittlung, sondern ein Werkzeug für kollektive Klarheit.
Vielleicht ist es Zeit, Planning Poker nicht nur als Schätzwerkzeug zu sehen – sondern als das, was es im besten Fall sein kann: ein Vehikel für Team-Dialog, gemeinsame Erkenntnis und klare, handhabbare Stories. Wer diesen Aspekt erkennt, profitiert oft mehr von den Diskussionen als von der Zahl am Ende.
In diesem Artikel gehen wir vier Grundsätze der Sprintplanung durch, die wir für besonders hilfreich halten.
Die agile Zeremonie des sogenannten Sprintplannings oder schlicht „Plannings“ dient in jedem Sprint dazu, die Ausführung neu zu fokussieren, Überraschungen zu minimieren und eine insgesamt höhere Codequalität zu garantieren.
Überprüfen Sie Ihre Roadmaps, bevor Sie sich treffen
Die Zeit vergeht schneller als wir denken. Daher ist es eine gute Idee, die Roadmap Ihres Projekts in den ersten zwei Wochen des neuen Jahres zu überprüfen. Die Roadmap bildet den Kontext für zwei wichtige agile Konzepte: Epics und Versionen, die das Rückgrat für die agile Programmplanung bilden und dabei helfen, die Lieferung längerfristiger Arbeit zu verfolgen. Vergewissern Sie sich, dass die Roadmap aktuell und für das gesamte Team sichtbar ist und dass Epics und Versionen vor dem Sprint Planning Meeting korrekt in Jira aufgelistet sind.
Halten Sie eine Besprechung vor der Besprechung ab
Die Sprintplanung umfasst zwei wichtige Aufgaben: die Pflege des Backlogs und die Entscheidung, welche Arbeiten im kommenden Sprint abgeschlossen werden sollen. Bei Atlassian haben wir die Erfahrung gemacht, dass das Backlog Grooming am besten in einem separaten Meeting mit dem Product Owner und dem Scrum Master vor dem eigentlichen Sprint Planning Meeting stattfindet. Für das gesamte Entwicklungsteam ist diese Vorbesprechung optional.
Was ist Backlog Grooming?
Backlog Grooming stellt sicher, dass das Backlog gesund ist. Wie sieht das aus? Gut, dass Sie fragen. Ein gesundes Backlog:
priorisiert jedes Arbeitselement, wobei die wichtigste Arbeit an erster Stelle steht
enthält vollständig ausgearbeitete User Stories, mit deren Umsetzung das Entwicklungsteam beginnen kann
Enthält eine aktuelle Schätzung für jedes Arbeitselement
Die Teams bei Atlassian halten einige Tage vor der Sprintplanung kurze Backlog Grooming Meetings ab. Planen Sie 30 Minuten für dieses Meeting ein, um die Aufgaben zu sichten, die Sie in den nächsten zwei Sprints am ehesten angehen werden. Manchmal werden Sie Punkte finden, die nicht detailliert genug sind, um ausgeführt zu werden, oder die mehr kontextbezogene Informationen vom Product Owner benötigen. Das ist das Schöne an der Erstellung des Backlogs im Voraus. Diese Lücken können zwischen den Meetings gefüllt werden, so dass sie während der eigentlichen Sprint-Planung keine Hindernisse (oder Zeitfresser) darstellen. Durch die Erstellung des Backlogs im Vorfeld hat das Team während der Sprintplanung mehr Zeit, seine Optionen für den Sprint zu prüfen und bei Bedarf Elemente für den nächsten Sprint zu markieren.
Team-Aktivität: Manche Teams haben Probleme mit der Schätzung. Story Points bieten einen soliden Rahmen für die Schätzung der Arbeit. Binden Sie das Team in eine Aktivität namens stille Schätzung ein. Legen Sie zu Beginn der Übung die Story-Point-Werte (0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100) in Spalten auf eine weiße Tafel. Bitten Sie dann das Team, die Benutzergeschichten in der Spalte zu platzieren, die sie für am genauesten halten. Die meisten Geschichten werden sich auf eine Zahl konzentrieren, und wenn es Unstimmigkeiten über den Punktwert der Geschichte gibt, ist es an der Zeit, eine Diskussion darüber zu eröffnen, warum. (Siehe auch unseren Artikel zu: Die 6 besten Planning Poker Tools zur freien Verfügung)
Informieren Sie die Sprintplanung mit Daten
Der Schwerpunkt des Sprint Planning Meetings liegt auf der Festlegung und Vereinbarung des Sprint-Ziels – der Menge an Arbeit, die das Team glaubt, während des Sprints erledigen zu können. Der Product Owner, der Scrum Master und das gesamte Entwicklungsteam müssen dabei anwesend sein. Wir bei Atlassian empfehlen ein Minimum von einer Stunde für jede Woche des Sprints, die Sie in der Besprechung abdecken wollen. Beginnen Sie beispielsweise mit einem zweistündigen Sprint Planning Meeting, um einen zweiwöchigen Sprint abzudecken. Idealerweise sollten Sie die Sprintplanung zu Beginn der Woche ansetzen. Dann werden der Kontext und der Arbeitsfluss des Teams weniger durch das Wochenende gestört.
Tipp: Planen Sie die Sprint-Retrospektive und das Sprint-Planning-Meeting nicht zusammen. Geben Sie dem Team genügend Zeit, um die Retrospektive zu verdauen und effektiv zur Sprintplanung beizutragen – vielleicht indem Sie dazwischen ein Teamessen einschieben.
Aus Erfahrung
Zu Beginn der Besprechung stellt der Scrum Master alle relevanten Aktionspunkte aus der Retrospektive des Teams vor. Als Nächstes gibt der Product Owner Produkt- oder Markt-Updates, damit alle auf dem gleichen Stand sind und den breiteren Kontext noch im Kopf haben.
Nach der Nachbesprechung ist es Aufgabe des Product Owners, das eigentliche Planungsgespräch zu beginnen. Zu Beginn verwendet der Product Owner die durchschnittliche Geschwindigkeit des Teams (die Menge an Arbeit, die typischerweise in einem Sprint abgeschlossen wird), um einen Vorschlag für eine Reihe von Storys für den Sprint, den so genannten „Sprint Forecast“, zusammenzustellen, der den Wert für den Kunden maximiert. Der Product Owner sollte auch diese drei Faktoren berücksichtigen:
Feiertage, persönlicher Urlaub und teamweite Ereignisse
Priorität der Stories im Backlog (idealerweise schlagen sie die am höchsten eingestuften Elemente vor)
Wie (und ob) diese Arbeit das Produkt seinem Endziel näher bringen wird
Tipp: Product Owner können den Sprint Marker verwenden, um die Velocity zu berechnen.
Wenn das Team neu ist und keine etablierte Geschwindigkeit hat, sollte der Product Owner keine Sprintprognose vorschlagen. Stattdessen sollte dies eine Übung für das gesamte Team sein, da es wichtig ist, dass jedes Mitglied zustimmt. Zunächst wird das Team die Vorhersage nach bestem Wissen und Gewissen treffen und ein paar Sprints nach dem Prinzip „Versuch und Irrtum“ durcharbeiten. Sobald die Geschwindigkeit des Teams – die durch das Velocitydiagramm in Jira sehr schön veranschaulicht wird – numerisch festgelegt ist, verwenden Sie diese Metrik, um die Sprint-Prognose zu erstellen.
Sobald der Product Owner seine Ideen für den Sprint Forecast vorgestellt hat, kann das Team diesen validieren (und/oder anpassen) und sich auf einen Aktionsplan für den Sprint einigen.
Tipp: Das Team sollte bei jedem Sprint darüber nachdenken, wie die technischen Schulden reduziert werden können. Die Erstellung eines Schnellfilters, der Bugs im Backlog des Teams hervorhebt, ist eine einfache Möglichkeit, wichtige Bugs zu markieren, die in den Sprint aufgenommen werden sollen, während das Team an User Stories in verschiedenen Bereichen der Codebasis arbeitet. Der Schnellfilter „tech debt“ verwendet die JQL-Abfrage „type in (bug)“, um die Ansicht auf Bugs zu beschränken. Erweitern Sie einfach die JQL-Abfrage, um bei Bedarf weitere Fehlertypen einzubeziehen.
Der nächste Schritt in der Sprint-Planung besteht darin, die Stories durchzugehen und zu beschreiben, welche Arbeiten zur Fertigstellung jeder Story erforderlich sind. Während das Team plant, sollten Sie sicherstellen, dass jemand die wichtigsten Punkte in jedem Jira-Ticket festhält. Auf diese Weise sind sowohl die Entscheidung als auch die Begründung später leicht zu erkennen. Das Team sollte sich Fragen stellen wie…
Hat sich die Definition der Story geändert, seit sie geschrieben wurde? Gibt es neue kontextbezogene Informationen, die das Team berücksichtigen muss?
Ist die Schätzung für die Story noch gültig? Ist das gesamte Team mit der Schätzung einverstanden? Wenn nicht, sollte der Scrum Master das Team bei der Neuschätzung anleiten.
Welche Aufgaben sind für die Fertigstellung dieser Story erforderlich? Verwenden Sie Teilaufgaben, um die Arbeit zu parallelisieren und den Ablauf zu optimieren. Wenn das Team bei der Aufteilung der Arbeit auf einzigartige Stories stößt, sollten diese Aufgaben zu völlig unabhängigen Stories erhoben werden.
Welche Auswirkungen hat das Testen auf diese Story? Wie können wir das Testen automatisieren? (Denken Sie daran, dass manuelle Testskripte im Wesentlichen technische Schulden sind).
Sind spezielle Fähigkeiten erforderlich? Wie können wir die Zeit des Spezialisten optimieren, ohne den Rest des Teams zu behindern?
Wie wirkt sich diese Geschichte auf die Architektur des Produkts aus? Gibt es bestimmte Personen, die das Team in den Entwurf und die Codeüberprüfung einbeziehen muss?
Gibt es Abhängigkeiten zwischen den Stories? Können wir angesichts dieser Abhängigkeiten die gesamte Arbeit während des Sprints abschließen?
Die Versuchung ist groß, diese detaillierte Übung überstürzt durchzuführen. Aber eine gute Planung zahlt sich aus, sobald der Sprint beginnt. Hier geht es vor allem darum, zu verstehen, wie die Arbeit erledigt werden soll, wobei der Scrum Master die Diskussion im Team fördert. Es ist wichtig, dass jeder gehört wird, damit sich das Team verantwortlich fühlt, sobald der Plan steht.
Tipp: Während der Sprint-Planung ist es einfach, Stories in den Sprint hinein- und wieder herauszuschieben, während das Team seine Sprint-Prognose erstellt. Klicken Sie einfach mit der rechten Maustaste auf ein Issue, um es in den oder aus dem Sprint zu verschieben.
Auf die Plätze, fertig, Sprint!
An diesem Punkt des Meetings sollte das Team mit dem Sprint Forecast zufrieden sein. Am Ende der Sprintplanung empfiehlt es sich, von allen Anwesenden mündlich zu bestätigen, was das Team am Ende des Sprints tatsächlich ausliefern wird. Stellen Sie außerdem sicher, dass jedes Teammitglied mindestens eine Aufgabe hat, mit der es beginnen kann, und dass niemand doppelte Arbeit leistet.
Das Engagement und die Moral des Teams schwanken natürlich von Sprint zu Sprint. Diese Schwankungen zeigen sich oft während der Sprint-Planung, aber widerstehen Sie der Versuchung, sich sofort damit zu befassen. Nutzen Sie stattdessen die Retrospektive des Teams, um alle Probleme zu verstehen, die sich auf die Moral auswirken. Teams, die schnell auf Kultur- und Entwicklungsprobleme reagieren, sind zufriedener, produktiver und schreiben besseren Code.
Die Backlogs von Projekten sind oft voll und unübersichtlich. Um eine Struktur hineinzubringen, nehmen sich Scrum Teams Zeit, um die Items gemeinsam zu schätzen. Planning Poker ist eine beliebte Methode dafür, eine weitere Möglichkeit stellt aber auch Magic Estimation dar. Was daran so magisch ist und wie das Ganze funktioniert, erfahren Sie hier.
Wo liegt die Magie?
Warum sollten Sie Magic Estimation verwenden, wenn Planning Poker doch genauso zum Ziel führt und in den meisten Teams bereits im Einsatz ist? Die Magie des Schätzverfahrens liegt in der Zeiteinsparung!
Beim Planning Poker gibt es im Vorfeld viel zu klären. Erst wenn keine Fragen mehr offen sind, beginnt die verdeckte Schätzung. Dabei ist jedes Teammitglied an jeder einzelnen Schätzung beteiligt. Das hat zwar den Vorteil, dass jeder seine Stimme abgibt, es nimmt jedoch auch viel Zeit in Anspruch.
Nach jedem Durchgang kommt es zusätzlich zu einer Diskussion zwischen der höchsten und der niedrigsten Schätzung. Zielführend? Bestimmt. Aber wir wissen alle, dass Zeit in Projekten eine Mangelware darstellt.
Wie funktioniert es?
Magic Estimation soll den Zeitaufwand beim Schätzen reduzieren. Es ist wie Planning Poker ein relatives Schätzverfahren, das Team setzt die Items also in Verhältnis zu einer Referenzstory.
Was muss vorbereitet werden?
Die Fibonacci-Reihe sollte auf dem Tisch, an der Wand oder am Whiteboard angebracht sein – je nachdem, wo das Team arbeitet
Die Storys müssen auf einzelnen Kärtchen vorliegen
Im Vorfeld wird eine Story beispielsweise per Planning Poker geschätzt, welche dann als Referenz gilt
Die Items aus dem Backlog müssen klar verständlich sein
Nun kommen wir zum Ablauf. Zu Beginn eines Durchlaufes liegt die Referenzstory bereits an dem geschätzten Fibonacci-Wert. Jeder Teilnehmer erhält zufällig einige ausgedruckte Storys.
Wichtig: Beim Schätzen der Storys wird nicht gesprochen!
Schritt 1: Jeder Teilnehmer platziert seine Storys innerhalb der Fibonacci-Reihe. Er orientiert sich dabei an der Referenzstory und darf die Karten nur direkt, nicht zwischen den Werten platzieren.
Schritt 2: Die Teilnehmer erhalten jetzt einige Minuten Zeit, um zu schauen, wie die Teammitglieder andere Storys geschätzt haben. Stimmt man deren Ansicht zu, verändert man nichts. Ist der Teilnehmer jedoch der Ansicht, dass eine Story zu hoch oder zu niedrig geschätzt ist, kann er diese verschieben. Er braucht die Verschiebung nicht begründen, muss die Karte aber mit einem Punkt oder einem Strich versehen. Damit können auch andere erkennen, dass diese Karte schon mal verschoben wurde. Diese Phase endet, wenn es keine Bewegung mehr auf dem Board gibt.
Schritt 3: Eine Karte kann mehrfach die Position wechseln. Sind auf einer Karte jedoch 3 Punkte vorhanden, scheint es noch Gesprächsbedarf zu geben. Dies ist in Form einer Diskussion möglich. Alle Karten mit drei Markierungen werden für diese Diskussion herausgezogen. Ab jetzt dürfen die Teilnehmer natürlich wieder sprechen. Ziel der Diskussion ist es, die Story zufriedenstellend im Board zu platzieren.
Herausforderungen und Vorteile von Magic Estimation
Damit Magic Estimation funktioniert, müssen die Items aus dem Backlog klar definiert und für alle verständlich sein. Ist dies nicht der Fall, ist der Diskussionsbedarf sehr hoch.
Ist dies jedoch gegeben, liegt der größte Vorteil klar auf der Hand: Anstatt dass alle Items nacheinander von jedem Einzelnen geschätzt werden müssen, schätzen die Teammitglieder die Storys im Magic Estimation parallel. Anschließend überprüfen sie diese. Es kommt nur zu einem Gespräch, wenn abweichende Meinungen vorliegen. Ist ein Team in diesem Verfahren bereits eingespielt, ist die Zeitersparnis enorm. Aus der Praxis berichten einige Teams, dass sie anstelle von ein bis drei Stunden nur noch maximal eine halbe Stunde für einen Schätzvorgang benötigen.
Ein weiterer Vorteil: Es lässt sich schnell erkennen, welche Storys zu groß sind und weiter zerlegt und ausdefiniert werden müssen.
Sprint Planning in Remoteteams ist an und für sich eine runde Sache. Als die Remotearbeit aufgrund der Pandemie anstieg, haben wir uns daran begeben und auch das Planning Poker runder gemacht. Jetzt haben wir unserem Agile Casino ein Update gegönnt. Mit dem Update kamen Features dazu, die Stabilität wurde erhöht. Im Folgenden gehen wir etwas ins Detail.
Hintergrund
Wir haben am Anfang der Pandemie einen Prototypen (eher schon ein MVP) für das Planning Poker. Was heißt hier „wir“? Das Team lässt mich an der Stelle mit Recht etwas im Stich, denn die haben Wichtigeres zu tun. Ich halte es allerdings für eine tolle Gelegenheit, auch mal zu demonstrieren, wie wir an die Entwicklung von modernen Cloudanwendungen herangehen.
Grundsätzlich – wenn auch klein – erfüllt es alle Eigenschaften einer Cloud-Anwendung (eine SaaS, Software as a Service). Es gibt zwar keine Abomodell (da es kostenlos ist), das könnte es aber geben (andere Scrumpoker online haben ja Pläne wie 8 Euro pro Monat etc.) und Abo ist ja ein Kennzeichen für eine Cloudanwendung. Unser Abomodell kostet quasi 0 Euro.
Das Update
In diesem Update ging es um ein paar Features und um Stabilität. Für den Betrieb im Cluster mussten wir Änderungen vornehmen. Auch die QS-Schritte haben wir auf ein professionelles Niveau gehoben, in dem wir die anfänglich rundimentären automatisierten Tests (sogenannte Integrationstests) erweitert haben.
An Features gibt es nun neben der Rolle des Entwicklers auch die Rolle des „Inspectors“. Denn es ist häufig der Fall, dass weitere Personen dem Planning beiwohnen, die den Entwicklern im Raum keinen Platz wegnehmen sollen. Inspektoren sind alle Nichtentwickler eines Scrumteams und Sonstige. Was bleibt also nach Scrum Guide noch? Genau: Der Scrum Master und der Product Owner. Sonstige können alle möglichen Stakeholder sein.
Es sind zwar weiterhin nur sieben Entwickler möglich (das es in einem Scrum Team nur maximal neun Personen geben darf, neun minus zwei ergibt sieben Entwickler). Ich finde diese Aussage im aktuellen Scrum Guide nicht mehr. Dahre denke ich, werde ich diese Begrenzung evtl. aufheben.
Außerdem habe ich den Invite Link verbessert. Der lässt sich jetzt einfacher in die Zwischenablage kopieren und ist professionell eingebunden.
Geplante Features
Jira: Ich ich denke bereits über eine Jira-Anbindung nach. Es wäre sehr nützlich, wenn geschätzte Werte gleich via Klick in die entsprechende Story im Jira übernommen werden könnte. Aber auch sehr aufwändig. Vielleicht packe ich das Feature mal in eine Art Premiumpaket, dass treue Leser und Kunden natürlich kostenlos erhalten.
Timer: Ein Timer wäre sehr nützlich, der für alle synchron läuft.
Score: Im Score-Board sollten die Spieler mit den Minimal- und Maximalwerten markiert werden. Die Spielergebnisse je Schätzrunde sollten auch hübscher dargestellt werden.
T-Shirt-Größen: Derzeit gibt es nur die vorgegebene Werteskala. Der User sollte weitere Skalen wählen können. Eventuell sollte er auch Skalen erstellen können.
Fazit
Der agile Ansatz funktioniert einmal mehr. Agile Casino bietet bereits jetzt eine gute Basis und den Nutzen, Schätzpoker in Remote-Teams störungsfrei und kostenlos durchzuführen.
Mit dem aktuellen Update kommen weitere Möglichkeit hinzu. Aus Qualitätssicherungssicht ist die Anwendung ab dieser Anwendung jetzt komplett stabil.
Was haltet ihr von dem ganzen Vorgang? Nutzt ihr das Tool oder wollt ihr es nutzen? Welche Features sollten wir noch reinbringen und was hat eurer Meinung nach Priorität? Schreibt es in die Kommentare.
