E-Government
Vom:
10.1.2019

Scrum bei publicplan – Agiles Schätzen

Autor:in
Benjamin Ehrchen
Wie lassen sich Projekte in der Softwareentwicklung effizient planen? Unser Scrum Master Benjamin Ehrchen geht in seinem aktuellen Artikel darauf ein, wie agiles Schätzen funktioniert.

Agilität bedeutet nicht, ohne Ziel oder Route auf die Reise zu gehen. Im Gegenteil: Agile Softwareprojekte haben natürlich die Anforderung, geschätzt und geplant zu werden. Agile Softwareentwicklung möchte möglichst genau planen, gibt sich dabei jedoch realistisch und trägt der Empirie Rechnung. Diese besagt, dass sämtliche Detail-Planung in den meisten Fällen hinfällig wird, sobald Projekte in die entscheidende Phase übergehen.


Im fortgeschrittenem Stadium werden häufig Anforderungen angepasst und der Aufwand steigt ins Unermessliche. Parallel dazu wachsen die Kosten. Dem Problem entgegnet Agilität, indem sie die Entwicklung von Produkten inkrementell gestaltet und damit auch die Planung in kleine Häppchen unterteilt. So minimiert sie das hohe Risiko klassischer Softwareprojekte, sobald man zu weit in die Zukunft planen möchte.
Der Kunde kann dadurch bis zum Ende der letzten Entwicklungsphase mitwirken. Die Kosten bleiben konstant und planbar. Auch bei inkrementeller Entwicklung ist jedoch das Bedürfnis berechtigt, diese Inkremente in irgendeiner Form zu schätzen und damit für den Product Owner planbar zu machen. Irgendwie müssen Releases und Auslieferungen ja im Voraus gestaltet werden. Hierbei entstehen einige Probleme und Widersprüche, die in der Folge aufgelöst werden sollen.

Schwierigkeiten bei der Schätzung agiler Projekte

Ein Problem besteht darin, dass User Stories per Definition ungenau sind. Sie sind lediglich eine Erinnerung daran, dass zu ihrer Lösung vor allem Kommunikation notwendig ist. Dies steht im Widerspruch dazu, dass für eine möglichst genaue Einschätzung der Anforderungen ein hoher Detailgrad nötig ist.
Darüber hinaus werden Nebentätigkeiten (Diskussionen, Planungen, Management, Meetings, Rüstzeiten etc.) häufig gar nicht bis kaum bei Schätzungen berücksichtigt. Auch der Vorgang des Schätzens an sich ist ein Problem für die Genauigkeit. Schätzungen sind eben genau dies: Schätzungen und damit im Wortsinn bereits ungenau. Sie stellen keine Garantie dafür dar, dass eine Anforderung in der eingeschätzten Zeit umgesetzt werden kann. Dafür gibt es bei der Umsetzung schlichtweg zu viele Unwägbarkeiten, die nicht vorausgesehen werden können.
All dies führt letztendlich zu der Frage: Was genau schätzen wir auf welche Weise?

Genaues Schätzen im Scrum

Agile Schätzung kann dafür eine Lösung bieten. Man möchte gar nicht mehr suggerieren, 100 % Schätzgenauigkeit erreichen zu können. Stattdessen versucht man sich durch Erfahrungswerte und permanente Triangulation (Abwägen von Relationen der Stories untereinander) diesem Wert lediglich zu nähern. Dabei gilt es auch, den Schätzaufwand zu berücksichtigen: Ist eine zu 100 % genaue Schätzung den sehr hohen Mehraufwand überhaupt wert?

Agiles Schätzen beantwortet diese Frage mit einem klaren Nein und verweist auf den Effizienzgewinn der bewusst hingenommenen Schätzungenauigkeit. Entsprechend wird bei agilem Schätzen auch nicht die Dauer der Umsetzung geschätzt. Das würde eine hohe Schätzgenauigkeit suggerieren. Dagegen schätzt man lediglich die relative Größe der einen Kundenanforderung im Vergleich zu den anderen Kundenanforderungen eines Projekts.

Der Fokus liegt damit auf den User Stories. Diese lassen sich mithilfe von bspw. Story Points nach Größenklassen ordnen. Dabei bezieht man sich auf initial festgelegte Referenzstories. Die Erfahrung bzw. die permanent ermittelte Velocity eines Teams zeigt dann mittelbar die Dauer der Umsetzung von Anforderungen an. Das wiederum lässt sich in Release-Planungen übersetzen. Die relative Größe einer Anforderung wird also getrennt von ihrer Dauer geschätzt.

Kriterien für agiles Schätzen

Folgende Kriterien können bspw. herangezogen werden, um die Anforderungen relational zu einander einzuschätzen:

  • Komplexität einer Story
  • Risiken bei der Umsetzung
  • Kenntnis der Basistechnologie
  • Externe Abhängigkeiten
  • Anzahl an zu implementierenden Formularen
  • Zusätzlich benötigte Datenbanktabellen
  • Schwierigkeit der Integration in bestehende Systeme

Sie möchten mehr über unsere agile Arbeitsweise erfahren? Dann besuchen Sie unseren Blog.
Hier finden sie verschiedene Artikel zum Thema Agilität in Softwareprojekten sowie agile Projekte in der Verwaltung.

Autor:in
Benjamin Ehrchen
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum.
Alle Artikel ansehen
Beitrag teilen

Ähnliche Artikel

Kontaktieren Sie uns

Schreiben Sie uns
publicplan verpflichtet sich, Ihre Privatsphäre zu schützen und zu respektieren. Weitere Informationen finden Sie in unserer Datenschutzerklärung.
Indem Sie unten auf "Einsenden" klicken, stimmen Sie zu, dass publicplan die oben angegebenen persönlichen Daten speichert und verarbeitet, um Ihnen die angeforderten Inhalte bereitzustellen.
Jetzt senden
Your information has been saved.
Looks like we're having trouble

Newsletter

Updates und NEws erhalten

Thank you! Your submission has been received!
Looks like we're having trouble

Wir behandeln Ihre Daten mit der nötigen Sicherheit. Zum Datenschutz