stimpfl.com
  • Über mich
  • Blog
  • Podcast
  • Kontakt
  • Menü Menü

Schlagwortarchiv für: highlight

Franz Stimpfl

Wie liege ich nicht zu falsch – Agiles Schätzen!

letztes Update: 6. Februar 2021/in Agiles PM, Grundlagen /von Franz Stimpfl

In diesem Blogpost dreht sich, wie der Titel schon verrät, alles um Schätzungen. Ich zeige euch, wie ihr eure Anforderungen auf eine agile Art und Weise abschätzen könnt und gebe euch ein grundlegendes Werkzeug für die Erstellung eures ersten agilen Plans mit auf den Weg.

Eine Sache, die ich am agilen Ansatz wirklich schätze ist, wie dieser auf die Freundlichkeiten verzichtet und uns daran erinnert, wie unsere Schätzungen eigentlich sind – nämlich wirklich, wirklich schlecht! Aber Schätzungen müssen wir abgeben um daraus Pläne für die Umsetzung zu erstellen.

Seien wir mal ehrlich – unsere Branche hat nicht gerade einen guten Ruf, wenn es darum geht, Erwartungen, die an Projekte gestellt werden, zu erfüllen. Es ist, als hätten wir irgendwann einfach vergessen, dass unsere Schätzungen wirklich nur schlechte Vermutungen sind, und zwar meisten übertrieben optimistische Vermutungen, um genau zu sein.

Steve McConnell nennt dies den “Cone of Uncertainty”, also den Kegel der Ungewissheit, der uns im Grunde daran erinnert, dass wir zu Beginn eines Projekts einfach viel zu viele Unbekannte haben, um ein gewisses Maß an Genauigkeit in Bezug auf den Zeitpunkt zu haben, an dem wir denken, dass ein Projekt fertig sein wird.

Erst nachdem wir etwas gebaut haben, können wir messen, wie lange die Erstellung gedauert hat, um danach diese Erkenntnis wieder in den Plan einfließen zu lassen.

Die einzige Frage, die wir zu Beginn eines Projekts beantworten sollten ist, ob dieses Projekt mit der zur Verfügung stehenden Zeit und den vorhandenen Ressourcen überhaupt möglich ist. Im Grunde können wir am Anfang des Projekts nur maximal eine grobe Schätzung oder den oft verwendeten Begriff „ballpark figure“ abgeben.

Wenn es also um Schätzungen geht, brauchen wir eine Methode, die es uns erlaubt, Budgets zu erstellen, für die Zukunft zu planen, uns daran erinnert, dass unsere Schätzungen wirklich schlechte Vermutungen sind, aber auch die inhärente Komplexität und Ungewissheit anerkennt, die mit dem Schreiben von Software einhergeht.

Nun gibt es zwei Dinge, die uns helfen werden, auf eine agile Art und Weise zu schätzen.

  1. wir halten die User Stories einfach
  2. wir schätzen die User Stories relativ

Es gibt keine separaten Schätzungen für die Analyse, die Entwicklung oder das Testen. Es ist eine einzige Zahl, die alles liefert, was notwendig ist, um diese User Story zum Funktionieren zu bringen. Außerdem ist wenig Aufwand bei der Schätzung sehr hilfreich. Wir werden nicht Stunden damit verbringen, zu versuchen, die Schätzungen genau richtig hinzubekommen. Wir werden eine Analyse durchführen, unsere beste Schätzung abgeben und dann schnell mit der nächsten User Story weitermachen. Tagelang auf das Zeug zu starren, wird nicht helfen, aber was die agile Schätzung wirklich zum Laufen bringt, ist die relative Dimensionierung von Stories. 

Machen wir ein kurzes Beispiel dazu. Versuche die Fläche dieser beiden Quadrate als exakte Zahl zu schätzen. Nimm dir ein paar Sekunden Zeit und sag mir genau, wie groß jedes dieser Quadrate ist. 

Okay, jetzt versuchen wir einen anderen Ansatz. Sag mir diesmal, um wieviel größer das blaue Quadrat im Vergleich zum oliven Quadrat ist?

Wenn du viermal zu groß geraten hast, herzlichen Glückwunsch, du bist ein geborener Schätzer. Die Millionen-Euro-Frage ist nun: „Was war einfacher? Die Schätzung auf die erste Art oder die Schätzung auf die zweite Art?“ 

Man nennt dies relative Schätzung, welche den Eckpfeiler von agilem Schätzen und agiler Planung darstellt. Denn sobald wir wissen, wie schnell das Team arbeiten kann und ihre User Stories relativ dimensioniert sind, können wir damit beginnen, wirklich gute Erwartungen in Bezug auf die Termine zu setzen.

Es gibt noch einen Punkt, den wir im Bezug auf agiles Schätzen noch verstehen müssen und zwar – die Schätzung ist ohne Einheiten. Wenn wir User Stories relativ zueinander einschätzen, messen wir die Größe, nicht die Zeit, die benötigt wird, um diese User Story zu entwicklen. Ein Kalendertag entspricht also nicht einer Einheit der Größe. Wir können auf diese Weise schätzen, weil verschiedene Leute unterschiedlich schnell arbeiten und manchmal Dinge, von denen wir denken, dass sie einen Tag dauern, am Ende vielleicht zwei Tage oder sogar eventuell nur einen halben Tag dauern.

Einheiten sind also nicht wirklich wichtig, es sind keine Zeitmaße, sondern ein Größenmaß, also nennen wir sie einfach Punkte und nehmen an, dass ein Punkt etwas ziemlich Einfaches ist. Etwas, das in der Umsetzung einen Tag dauern würde, drei Punkte für etwas Größeres, vielleicht ein paar Tage, fünf Punkte pro Woche und zehn Punkte für eine wirklich große Sache, die in der Größenordnung von zwei Wochen dauern würde.

Okay, genug der Theorie, sehen wir uns das mal in der Praxis an. Nehmen wir an, wir müssen abschätzen, wie lange es dauern würde, eine Anmeldeseite zu erstellen. Nehmen wir an, wir haben bereits unseren Projektumfang, wir haben ihn definiert, wir verstehen, was wir bauen und warum. Wir haben unsere Workshops zum Sammeln von User Stories durchgeführt und jetzt sind wir bereit, unsere erste User Story aus unserem Backlog zu schätzen.

Wie sollen wir das angehen? Nun, es gibt nichts magisches, um unsere User Stories zu schätzen. Im Grunde setzt man sich einfach mit dem Kunden zusammen und stellt eine Menge an Fragen, bis man sich damit wohlfühlt, eine Art Schätzung abzugeben, wie groß man denkt, dass diese User Story ist.

In diesem Fall könnten wir uns einige Mock-Ups ansehen, gehen die User Story mit dem Kunden durch, gehen sozusagen die Funktionalität Schritt für Schritt durch. Erfragen von unserem Kunden, was alles vorhanden sein muss, damit der Kunde zufrieden ist, also die Akzeptanzkriterien. Diese Akzeptanzkriterien sollten hinten auf die User Story geschrieben werden. Ich gehe jetzt davon aus, dass du natürlich Unit-Tests und Refactoring und all die anderen guten Sachen machen wirst und das nicht explizit auf. Dann kannst du im Grunde schon eine Schätzung abgeben.

Du schätzt und sagst, die User Story sieht aus, als wäre sie ungefähr drei Punkte Aufwand – das wird mich vielleicht ein paar Tage kosten. Jetzt machen wir es noch einmal, aber diesmal mit einer etwas komplizierteren User Story, mit einem etwas komplizierteren Screen, etwas mehr Arbeit auf der Datenbankseite und etwas mehr Fehlerbehandlung und Validierung. Wir können unsere Mock-Ups mit dem Kunden durchgehen, die Akzeptanzkriterien durchgehen, es in Aufgaben unterteilen und dann abschätzen. Bei dieser Schätzung könnten wir sagen, dass wir fünf Punkte brauchen und dann machen wir es noch einmal. Vielleicht ist diese nächste User Story eine ganz kleine, einfache, alles, was wir tun, ist die Auflistung der Einträge auf dem Bildschirm. Nehmen wir an, dass es sich um eine User Story mit einen Punkt handelt . Was jetzt letztendlich passieren wird, ist, dass wir eine wirklich schöne Basis von kleinen, mittleren und großen User Stories für das Projekt entwickeln werden, und wenn wir das haben, ist es einfach eine Sache, den Rest unserer User Stories durchzugehen und sie an die entsprechenden Stellen zu schieben. 

Das ist schon sehr gut, aber die Schätzung wird noch besser, wenn man sie im Team durchführt, und der Planungspoker ist eine lustige Art, User Stories in der Gruppe abzuschätzen. Das funktioniert im Grunde so: ein Kunde oder auch ein Storyteller liest dem Team eine Story vor, und die Entwickler stellen alle möglichen Fragen, um sicherzustellen, dass sie verstehen, was wirklich von der User Story verlangt wird. Das Team schätzt dann ab und manchmal sind die Schätzungen vielleicht hoch und manchmal niedrig, und es kommt zu einer großartigen Unterhaltung: „Warum denkst du, dass es so groß ist?“, „Warum denkst du, dass es so klein ist?“ „Nun, es ist, weil du dieses ganze…“ „hast du daran gedacht?“ 

Ob sie groß oder klein ist, ist eigentlich egal, wichtig ist, dass das Team darüber diskutiert und jemand etwas Wertvolles über die Geschichte lernt. Dann wird wieder geschätzt und hoffentlich kommt das Team nach ein paar Runden zu einer Art Konsens darüber, wie groß die User Story ist und die Teamschätzung ist besser, als wenn sie nur von einer Person gemacht worden wäre.

Das sind die Grundlagen der agilen Schätzung. Es ist keine Raketenwissenschaft! Was aber wirklich wichtig ist, ist die Größe von User Stories relativ zu bestimmen, denn wenn man das schafft, erledigt sich der Rest der Planung von selbst. 

https://www.stimpfl.com/res/uploads/2019/08/you-x-ventures-Oalh2MojUuk-unsplash.jpg 1280 1920 Franz Stimpfl https://www.stimpfl.com/res/uploads/2021/01/Franz-Stimpl-Signature-1030x242.png Franz Stimpfl2021-02-06 21:54:332021-02-08 20:59:27Wie liege ich nicht zu falsch – Agiles Schätzen!
Franz Stimpfl

Daily Stand-Ups … was sie wirklich bringen!

letztes Update: 14. Januar 2021/in Agiles PM, Grundlagen, SCRUM /von Franz Stimpfl

Tägliche Stand-Ups könnte man so beschreiben: „Jeden Tag trifft sich das Team zur gleichen Zeit am gleichen Ort, um von allen Teilnehmer den aktuellen Stand der Erreichung des Sprint-Goals bzw. mögliche Hindernisse, die das Sprint-Goal gefährden können, zu erfahren.“

Weiterlesen
https://www.stimpfl.com/res/uploads/2021/01/Fearless.png 1260 2240 Franz Stimpfl https://www.stimpfl.com/res/uploads/2021/01/Franz-Stimpl-Signature-1030x242.png Franz Stimpfl2021-01-14 09:43:002021-02-06 23:04:46Daily Stand-Ups … was sie wirklich bringen!
Franz Stimpfl

Agiler Ansatz im Fixpreisprojekt?!

letztes Update: 2. Februar 2020/in Agiles PM, Projektmanagement /von Franz Stimpfl

Warum Flexibilität nicht immer Kosteneffizienz bedeutet

Ist ein Fixpreisprojekt mit einem agilen Ansatz überhaupt durchführbar? Mir wurde diese Frage vor kurzem wiedereinmal gestellt und ich möchte dies als Anlass nehmen, dieses Thema auch in meinem Blog nicht unerwähnt zu lassen, vorallem, weil es einer der häufigsten Kritikpunkte agiler Methoden ist.

Beginnen wir mit der Definition eines Festpreisprojekts. Was sind die Rahmenbedingungen? Was sind die Probleme, die dabei auftreten? Welche Lösungsansätze gibt es?

Weiterlesen
https://www.stimpfl.com/res/uploads/2019/07/unsplash-c59hEeerAaI-unsplash.jpg 1281 1920 Franz Stimpfl https://www.stimpfl.com/res/uploads/2021/01/Franz-Stimpl-Signature-1030x242.png Franz Stimpfl2020-02-02 15:25:002021-01-30 09:12:50Agiler Ansatz im Fixpreisprojekt?!
Franz Stimpfl

Drei agile Konzepte für den täglichen Gebrauch

letztes Update: 28. Januar 2020/in Projektmanagement, SCRUM /von Franz Stimpfl

Was verbindet die existierenden Methoden?

Gerade am Anfang eines neuen Jahres stellen sich viele die Frage: „Wie kann ich  meine Arbeit produktiver und effizienter durchführen?“ Für dieses Thema gibt es unzählige Bücher und Blogeinträge. Ich möchte in diesem Post nicht auf die einzelnen Methoden eingehen sondern 3 Parallelen zu den Ansätzen agiler Methoden aufzeigen.

Weiterlesen
https://www.stimpfl.com/res/uploads/2019/07/startae-team-7tXA8xwe4W4-unsplash.jpg 1280 1920 Franz Stimpfl https://www.stimpfl.com/res/uploads/2021/01/Franz-Stimpl-Signature-1030x242.png Franz Stimpfl2020-01-28 15:30:502021-01-30 09:13:08Drei agile Konzepte für den täglichen Gebrauch

Aktuelle Beiträge

  • Wie liege ich nicht zu falsch – Agiles Schätzen! 6. Februar 2021
  • Daily Stand-Ups … was sie wirklich bringen! 14. Januar 2021
  • So werden eure Online-Meetings ein Erfolg! 4. April 2020
  • Grundlagen: S.M.A.R.T.e Ziele im Projektmanagement 14. Februar 2020
  • Scope Creep im Projekt vermeiden!? 10. Februar 2020

Kategorien

  • Agiles PM
  • Allgemein
  • Grundlagen
  • Projektmanagement
  • Remote Work
  • SCRUM

© Datenschutz Impressum

Folge einem manuell hinzugefügten Link

Newsletter

Exklusive Informationen für Abonnenten.

Jetzt abonnieren

Nach oben scrollen

Diese Website verwendet Cookies. Wenn Sie die Website weiter nutzen, gehen wir von Ihrem Einverständnis aus.

Erfahren Sie mehrAkzeptieren

Cookie- und Datenschutzeinstellungen



Wie wir Cookies verwenden

Wir können Cookies anfordern, die auf Ihrem Gerät eingestellt werden. Wir verwenden Cookies, um uns mitzuteilen, wenn Sie unsere Websites besuchen, wie Sie mit uns interagieren, Ihre Nutzererfahrung verbessern und Ihre Beziehung zu unserer Website anpassen.

Klicken Sie auf die verschiedenen Kategorienüberschriften, um mehr zu erfahren. Sie können auch einige Ihrer Einstellungen ändern. Beachten Sie, dass das Blockieren einiger Arten von Cookies Auswirkungen auf Ihre Erfahrung auf unseren Websites und auf die Dienste haben kann, die wir anbieten können.

Notwendige Website Cookies

Diese Cookies sind unbedingt erforderlich, um Ihnen die auf unserer Webseite verfügbaren Dienste und Funktionen zur Verfügung zu stellen.

Da diese Cookies für die auf unserer Webseite verfügbaren Dienste und Funktionen unbedingt erforderlich sind, hat die Ablehnung Auswirkungen auf die Funktionsweise unserer Webseite. Sie können Cookies jederzeit blockieren oder löschen, indem Sie Ihre Browsereinstellungen ändern und das Blockieren aller Cookies auf dieser Webseite erzwingen. Sie werden jedoch immer aufgefordert, Cookies zu akzeptieren / abzulehnen, wenn Sie unsere Website erneut besuchen.

Wir respektieren es voll und ganz, wenn Sie Cookies ablehnen möchten. Um zu vermeiden, dass Sie immer wieder nach Cookies gefragt werden, erlauben Sie uns bitte, einen Cookie für Ihre Einstellungen zu speichern. Sie können sich jederzeit abmelden oder andere Cookies zulassen, um unsere Dienste vollumfänglich nutzen zu können. Wenn Sie Cookies ablehnen, werden alle gesetzten Cookies auf unserer Domain entfernt.

Wir stellen Ihnen eine Liste der von Ihrem Computer auf unserer Domain gespeicherten Cookies zur Verfügung. Aus Sicherheitsgründen können wie Ihnen keine Cookies anzeigen, die von anderen Domains gespeichert werden. Diese können Sie in den Sicherheitseinstellungen Ihres Browsers einsehen.

Andere externe Dienste

Wir nutzen auch verschiedene externe Dienste wie Google Webfonts, Google Maps und externe Videoanbieter. Da diese Anbieter möglicherweise personenbezogene Daten von Ihnen speichern, können Sie diese hier deaktivieren. Bitte beachten Sie, dass eine Deaktivierung dieser Cookies die Funktionalität und das Aussehen unserer Webseite erheblich beeinträchtigen kann. Die Änderungen werden nach einem Neuladen der Seite wirksam.

Google Webfont Einstellungen:

Google Maps Einstellungen:

Google reCaptcha Einstellungen:

Vimeo und YouTube Einstellungen:

Datenschutzrichtlinie

Sie können unsere Cookies und Datenschutzeinstellungen im Detail in unseren Datenschutzrichtlinie nachlesen.

Einstellungen akzeptierenVerberge nur die Benachrichtigung