Slider Kollaboration der publicplan GmbH

Scrum bei publicplan - Agiles Schätzen

Blog

Kontakt

publicplan GmbH

Kennedydamm 24
40476 Düsseldorf

 

Tel +49 (0)211 635501-80
Fax +49 (0)211 635501-89

 

Torstraße 218
10115 Berlin

 

Tel +49 (0)30 6098980-80
Fax +49 (0)30 6098980-89

infoatpublicplan.de

Scrum bei publicplan - Agiles Schätzen

Autor
Benjamin Ehrchen
Datum

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

 

Agilität bei publicplan - Übersicht über alle wichtigen Punkte beim agilen 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 beispielsweise 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 beispielsweise 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