====== Iterationsplanung ======
  * Was zuerst implementiert wird, entscheidet der Kunde! -> Priorisierung
  * Vorgehen nach \cite[S. 43]{Bleek2008}
    * Ausgangspunkt sind Storys, die Features (Nutzen für den Anwender) beschreiben
    * Kunde wählt die wichtigsten Storys aus und Entwickler schätzen die Storys -> nun ist Reihenfolge anhand Kosten/Nutzen möglich
    * Erkennen und Zerteilen der zu großen Anforderungen
    * bei umfangreichen Systemen kann nun nach dem Ansatz der Quick Wins oder Low-Hanging-Fruits vorgegangen werden: was kann schnell umgesetzt werden und verschafft dem Kunden einen hohen Mehrwert (insbesondere wichtig bei Ablösung von Altsystemen, da sonst ständig nur die bereits vorhandenen Funktionen nachprogrammiert werden)
    * Hilfen: Abhängigkeitsgraph (Anforderung 1 muss vor Anforderung 2 implementiert werden) und Graph, der die positiven Auswirkungen von Anforderungen zeigt (Anforderung 2 kann schneller, besser, einfacher implementiert werden, wenn Anforderung 1 bereits implementiert ist)
    * zusätzlich zu den fachlichen Anforderungen können auch technische Anforderungen (z.B. Refactorings) als Storys eingebracht werden, für die dann z.B. ein gewisser Teil der Arbeitszeit aufgewendet werden kann
  * die Planung erfolgt durchaus für einige Interationen im Voraus, muss aber nach den ersten Iterationen auf ihre Umsetzbarkeit geprüft werden
  * im Zweifelsfall sollten für eine Iteration lieber zu wenig Anforderungen geplant werden, als zu viele, da sonst die bekannten Probleme (Zeitdruck, mangelnde Qualität) auftreten. Der eventuelle Leerlauf kann für Retrospektiven oder Qualitätssicherung verwendet werden
  * alternativ kann mit obligatorischen und optionalen Anforderungen gearbeitet werden

===== Abhängigkeiten zwischen Anforderungen =====
**nach \cite[S. 42]{Bleek2008}**
  * wichtige Anforderungen (solche mit hohem Geschäftswert für den Kunden) werden zuerst implementiert (-> Kunde entscheidet), (scheinbare) Abhängigkeiten werden pragmatisch aufgelöst
    * optimalerweise arbeiten alle Entwickler gleichzeitig (!) an den wichtigsten Anforderungen (Aussage Herr Andert) -> Verantwortung und Wissen wird auf mehrere Schultern verteilt
  * Beispiel Stammdatenverwaltung: dürfte Grundlage für alle weiteren Funktionen sein, bringt aber kaum Mehrwert, daher reicht zu Beginn vielleicht eine Importschnittstelle oder eine Kommandozeilenapplikation
  * Beispiel Einsatzplanung: Autos, Personen und Aufträge werden benötigt, aber vielleicht nur ein Ausschnitt (Name, Kennzeichen, Adresse etc.)
  * schwierige Anforderungen sollten zuerst implementiert werden (evtl. als Proof of Concept), da diese durch ihre den Entwicklern meist unbekannten Bereiche schwer abzuschätzen sind und sonst die Planung durcheinander bringen können