====== Verfahren zur Aufwandsschätung ======

===== Allgemeine Voraussetzungen =====
**nach \cite[S. 26f.]{Bleek2008}**
  * organisatorische und technische Rahmenbedingungen müssen feststehen und dem Team bekannt sein
  * es muss auf möglichst kleiner Ebene geschätzt werden (z.B. Maximalgröße einer Anforderung 1 Entwickler/1 Woche) -> realistischere Schätzungen
  * das Entwicklerteam schätzt selbst und für sich selbst, da nur sie selbst ihr Tempo kennen und einschätzen können
  * als Einheiten sollten nicht "harte" Einheiten wie Manntage verwendet werden, sondern abstrakte Einheiten wie Aufwandspunkte
    * diese geben nur ein Verhältnis zwischen den einzelnen Anforderungen an
    * es muss möglichst schnell ein Umrechnungsfaktor ermittelt werden zwischen Aufwandspunkten und Manntagen, damit eine Interationsplanung durchgeführt werden kann -> dieser Faktor ist ein Ergebnis der ersten Iteration (Ermittlung über Umrechnung der tatsächlichen Arbeitsaufwände / erledigte Aufwandspunkte)
  * alle Teammitglieder müssen in die Schätzung eingebunden werden, damit nicht die Wortführer oder die schnellsten Programmierer die Schätzungen vorgeben (mögliche Lösungen siehe unten)
  * ehrliche Schätzungen sind wichtig, um wirklich alle Meinungen zu berücksichtigen
    * hat vielleicht jemand die Task nicht richtig verstanden und überschätzt sie?
    * hat die Gruppe einen Aspekt übersehen, den eine einzelne Person bemerkt hat? 
    * fühlen sich Teammitglieder mit dem Aufgabengebiet unwohl, weil es für sie Neuland ist?
 
===== Konkrete Verfahren =====

==== Planning Poker ====
**nach \cite[S. 27]{Bleek2008}**
  * Verwendung normaler Pokerkarten
  * Bereich der Schätzung festlegen: z.B. 1-10 (mit Ass als 1)
  * Extrakarte für Diskussionsbedarf festlegen (z.B. die Dame)
  * Anforderung/Task wird vorgelesen und jeder Entwickler legt eine Karte verdeckt auf den Tisch
  * alle Entwickler drehen gleichzeitig ihre Karte um
  * Diskussionsbedarf besteht, wenn...
    * die Diskussionskarte gelegt wurde
    * die Schätzungen sehr hoch sind (-> Task evtl. auf kleinere Tasks aufteilen)
    * die Schätzungen stark voneinander abweichen (-> Missverständnisse, Fehlinterpretationen der Teammitglieder)
  * Endwert kann Mittelwert, Höchstwert oder niedrigster Wert sein, der Vorsicht halber sollte eher zum Höchstwert tendiert werden

==== Sching-Schang-Schong-Schätzen ====
**nach \cite[S. 31]{Bleek2008}**
  * eignet sich gut zum ad-hoc Schätzen in kleinen Gruppen
  * Kommentare á la "Das schaffe ich doch mit links" werden unterbunden
  * Einschätzungen sollen ehrlich geäußert und Anpassungen schwächerer Teammitglieder an Wortführer unterbunden werden
  * Vorgehen wie bei Stein-Schere-Papier: Anzählen, dann zeigt jeder seine Schätzung als Anzahl der Finger einer Hand (Wertebereich also 1-5)
  * liegen die Schätzungen mehr als 2 Punkte auseinander muss diskutiert werden