Auch ich finde die Formulierung "Die iterative Abschätzung der Sprints lässt keine (sinnvolle) Abarbeitung des Projekts zu fixierter Dauer (terminierte Deadline) und fixiertem Aufwand (Festpreis) zu." unglücklich. Es stimmt schon, dass das Sprint Planning auf die Planung des nächsten Sprints fokussiert. Betrachte ich also isoliert nur dieses Event ist natürlich eine Sprint-übergreifende Planung (die dann die "sinnvolle" Abarbeitung eines Projekts ermöglicht) nicht präsent. Das Problem hierbei ist aber die isolierte Betrachtung; und das Vernachlässigen der Aufgaben des Product Owners, der genau diese übergreifenden Themen bei der Pflege des Product Backlogs stets im Auge behält. Der Eindruck, der durch die Äußerung entsteht, ist, dass Scrum für diese Art der Planung nicht geeignet sei (insbesondere durch die Verwendung einer Wertung in Form von "keine (sinnvolle) Abarbeitung". Dies ist schlicht falsch. Es ist gerade der Vorteil der iterativen Abarbeitung insbesondere bei festem Termin und/oder Festpreis dem Kunden das unter diesen Rahmenbedingungen beste Produkt zu liefern. Dies wird -- gerade durch das iterative Vorgehen -- ermöglicht, weil dem Kunden enge Feedbackschleifen angeboten werden. Insofern schließe ich mich den Äußerungen von Peter Jetter und Martin Rohner an. Als weiteres: Den als ersten genannten Punkt unter "Nachteil / Grenzen / Risiken" verstehe ich auch nicht. Schließlich ist agiles Vorgehen nun mal verschieden vom klassischen Projekt. Konsequenterweise müssen sich Personen, die sich hierauf einlassen mit Veränderungen umgehen. Dies allerdings unter der Rubrik "Nachteil / Grenzen / Risiken" zu führen, empfinde ich als unglücklich. Denn dies gilt doch für jedwede anderen Arbeitsweisen, die für ein Projektteam neu sind und die "einen starken Einschnitt in die gewohnten Arbeitsabläufe des Projektteams darstellen".