nach {[quellen:Bleek2008|S. 26f.]}

• 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?

• Planning Poker
• Sching-Schang-Schong-Schätzen