Tipps für agile Schätzung, die bei britischen Teams wirklich funktionieren
13. August 2026
Praktische Tipps zur agilen Schätzung für britische Software-Teams im Jahr 2026. Verbessern Sie Story-Pointing, Planning Poker und Sprint-Prognosen.
Warum britische Teams mit Story Points kämpfen
Story Points können sich abstrakt anfühlen, besonders für Teams, die von stundenbasierten Schätzungen umsteigen. In Großbritannien erleben wir oft, dass Teams auf „Bauchgefühl" zurückgreifen oder Aufgaben ohne gemeinsame Basis miteinander vergleichen. Kulturelle Höflichkeit kann ebenfalls eine Rolle spielen: Nachwuchskräfte scheuen sich möglicherweise davor, die Schätzungen älterer oder erfahrenerer Kollegen infrage zu stellen. Um diesen Kreislauf zu durchbrechen, definiert klare Referenz-Storys, auf die sich euer gesamtes Team einigt. Hinterlegt sie an einem sichtbaren Ort, etwa in einem Team-Wiki oder einer angepinnten Slack-Nachricht. Überprüft sie vierteljährlich, denn das Tempo und der Kontext eures Teams ändern sich. Wenn alle verstehen, dass es bei Punkten um Komplexität und Risiko geht und nicht um Zeit, wird Schätzen zu einem Werkzeug für Ausrichtung statt zu einer Quelle von Angst.
Planning Poker mit einem Twist
Planning Poker ist ein Klassiker, aber Remote- und Hybrid-Teams in Großbritannien brauchen eine Variante, um es effektiv zu machen. Spielt nicht einfach nur in Echtzeit, sondern probiert asynchrones Planning Poker für Teams in verschiedenen Zeitzonen aus. Nutzt Tools wie ein Online-Board, auf dem Entwickler ihre Karten vor dem Meeting abgeben können. Wenn ihr euch dann trefft, konzentriert euch nur auf die Stories, bei denen die Schätzungen stark abweichen. Das spart Zeit und stellt sicher, dass auch die „ruhigen" Entwickler gehört werden. Eine weitere Variante: Bittet nach dem Aufdecken der Karten die Personen mit der höchsten und der niedrigsten Schätzung, ihre Überlegungen zu erklären – aber beschränkt das auf jeweils zwei Minuten. Das verhindert, dass sich Diskussionen in die Länge ziehen, und respektiert die typisch britische Vorliebe für knappe, unkomplizierte Gespräche.
Stützen Sie Schätzungen auf historische Daten statt auf Meinungen
Viele UK-Teams schätzen aus dem Gedächtnis, was unzuverlässig ist. Nutzen Sie stattdessen die historische Velocity Ihres Teams, um Schätzungen plausibel zu machen. Schauen Sie sich die letzten drei bis fünf Sprints an: Wie viele Punkte haben Sie tatsächlich abgeschlossen, und welche Arten von Storys sind überzogen? Wenn Sie eine Story haben, die wie eine „5“ aussieht, prüfen Sie, ob vergangene 5-Punkte-Storys mehr oder weniger Aufwand verursacht haben als erwartet. Falls Sie ein Muster der Überschätzung erkennen, passen Sie Ihre Basiswerte an. Tools wie Jira oder Azure DevOps können diese Berichte automatisch erstellen. Verlassen Sie sich jedoch nicht allein auf Daten: Besprechen Sie das „Warum“ hinter den Zahlen. Eine Story kann zwar ähnlich groß sein, aber eine neue Integration oder einen Stakeholder mit anderen Erwartungen beinhalten.
Große Stories zuerst mit T-Shirt-Größen aufteilen
Wenn Ihr Product Backlog vage, große Features enthält, wird die Schätzung zur Glaskugel-Leserei. Beginnen Sie mit T-Shirt-Größen (XS bis XL) als schnellem Filter, bevor Sie ins Detail gehen. So können Product Owner und Delivery Manager in Großbritannien priorisieren, ohne zu früh in die Einzelheiten einzusteigen. Wenn eine Story ein „XL“ ist, bitten Sie Ihr Team, sie mithilfe von Techniken wie User Story Mapping oder der Aufteilung nach Geschäftsregeln in mehrere „M“- oder „L“-Stories zu zerlegen. Bringen Sie nur Stories in die Sprint-Planung, die kleiner als „S“ oder „M“ sind. Das reduziert Überraschungen und hält Ihren Sprint-Backlog realistisch. Denken Sie daran: Das Zerlegen von Stories ist auch eine gemeinsame Verantwortung – nicht nur die des Product Owners.
Vermeiden Sie die 'Stundensatz'-Falle bei der Schätzung
Einer der größten Fehler, den Teams im Vereinigten Königreich machen, ist die Umrechnung von Story Points in Stunden für Stakeholder-Berichte. Sobald man anfängt zu sagen: „Ein 3-Pointer entspricht zwei Tagen“, ist man zurück beim zeitlichen Druck, und das Team wird Schätzungen aufblähen, um sich abzusichern. Nutzen Sie stattdessen Points, um die relative Komplexität auszudrücken, und lassen Sie die Velocity in eine Lieferprognose einfließen. Wenn Ihre Finanzabteilung wissen möchte, wann eine Funktion ausgeliefert wird, geben Sie ihr eine Spanne auf Basis Ihrer historischen Velocity an (z. B. „voraussichtlich zwischen 3 und 5 Wochen“). Das ist ehrlich und reduziert die Versuchung, Schätzungen in die Höhe zu treiben. Halten Sie Schätzgespräche fokussiert auf Aufwand, Abhängigkeiten und Risiko – nicht auf Produktivitätskennzahlen.
FAQ
Für kleine Teams funktioniert Planning Poker in Kombination mit der historischen Velocity am besten. Halten Sie Ihr Story-Repository klein und klar definiert. Nutzen Sie ein schnelles Abstimmungstool (wie planningpoker.com oder eine Slack-App), um Planungsaufwand zu vermeiden. Der Schlüssel ist, eine gemeinsame Ausgangsbasis zu haben und die Schätzungen alle paar Sprints mit der tatsächlichen Velocity abzugleichen.