As was discussed elsewhere, it is impossible to estimate the project deadline time exactly and the typical error may be as large as the project time itself. Nevertheless it is possible to finish the project in time. One of the condition is the periodic demonstration of the prototype to the customer and negotiations about the small details that should not be mentioned in the good contract at all.
(You may listen to the video (click it) or read the text below it)
Naturally, the prototypes should be also delivered according to the agreed schedule, but the advantage is that the deviations of the prototype from the ideal target are acceptable by the definition.
Therefore the goal is to reduce the deviation of the prototype from the target to the minimum and this, according to ” Central Limit Theorem“ from the statistics is possible if we divide the iteration ( “sprint”) that produces the prototype into smaller tasks and features.
It is easier to illustrate this by the coin-flipping. The project management goal to reduce the time deviation form the schedule to minimum corresponds in this game keep our loss minimal. If we throw the coin just once we either win or loose completely. It is not good in the project management because the customer will not be especially grateful for sprint result delivered before the agreed schedule but the customer will be probably very angry if we don’t deliver no prototype in time.
Let us imagine now that we throw the coin 100 times and divide our stake (sprint time) into 100 pieces (tasks). Then the statistics tells us that our loss in average will be less than SCRT(100)*100%/100 = 10% (SQRT denotes the square root). In the project management it corresponds to the 10% deviation in time and since we divided all into 100 tasks, it means that the deviation of the prototype from the ideal target is no more than 10%. For the prototype it is the good result.
Therefore to be safe we should include in the prototype demonstration several features and every feature should be divided into several tasks in the sprint. As people used to say, we should not put all eggs in one basket.
In the previous considerations we implicitly assumed that though we may make the large mistake in the estimation of the time required to the specific task we nevertheless are unbiased, in other words the time error averaged over many predictions tent to zero. This requirement puts the limit on the number of the people in the project. Nevertheless the scalability is possible. I am going to discuss it in one of the future note. So subscribe to the feed :).