The Evolutionary Planning process uses three main elements, see also booklets 2, 5 and 7:
We’ll show now how these three elements fit together to get and keep the project under control.
In many projects all the work we think* we have to do is cut into pieces, the pieces are estimated, and the estimates are added up to arrive at an estimate of the effort to do the work. Then this is divided over the available people (however, beware of Brooks’ Law!), to arrive at an estimate of the duration of the work, which, after adding some contingency, is presented as the duration of the project (figure 1).
A problem is that in many cases the required delivery date is earlier. The
tension between estimated and expected delivery causes extra time spent in
discussions, while the required delivery date doesn’t change, leaving even
less time for the project.
Because the delivery date is a requirement just as all the other requirements (see:'The importance of time'), it has to be treated as seriously as all the other requirements.
figure 1: Standard approach: it takes what it takes, but often that’s too late
The technique is always the same. We estimate what we think we have to do, see that we need more time than we have and then discuss the TimeLine with our customer or other appropriate Stakeholders and explain (figure 2):
Basic TimeLine: what will surely be done,
what will not be done, and what may be done
if we would keep working the way we're working now
If the total project takes more than 10 weeks, we define a Horizon at about 10 weeks on the TimeLine, because we cannot really oversee longer periods of time. A period of 10 weeks proves to be a good compromise between what we can oversee, while still being long enough to allow for optimizing the order in which we deliver results. We don’t forget what’s beyond the horizon, but for now, we concentrate on the coming 10 weeks.
TimeLine: find out top-down what will happen, calibrate bottom-up
to see what will really happen, then use your disappointment of what
you see to do something about it (see option#6 at 'Saving time')
Within these 10 weeks, we plan DeliveryCycles (figure 3) of maximum 2 weeks, asking: "What are we going to deliver to whom and why?"
Deliveries are for getting feedback from Stakeholders. We are humble enough to admit that our (and their) perception of the requirements is not perfect and that many of our assumptions may be incorrect. Therefore we need communication and feedback. We deliver to eagerly waiting Stakeholders, otherwise we don’t get feedback. If the appropriate Stakeholders aren’t eagerly waiting, either they’re not interested and we may better work for other Stakeholders, or they have to be made eagerly waiting by delivering what we call Juicy Bits. How can Juicy Bits have a high priority? If we don’t get appropriate feedback, we will probably be working based on incorrect assumptions, causing us to doing things wrong, which will cause delay later. Therefore, if we need to deliver Juicy Bits to Stakeholders to make them eagerly waiting in order to get the feedback that we awfully need, this has a high priority.
Once we have divided the work over Deliveries, which are Horizons as well, we now concentrate on the first few Deliveries and define the actual work that has to be done to produce these Deliveries. We organize this work in TaskCycles of one week. In a TaskCycle we define Tasks, estimated in net effort-hours (see booklet#2, section 6.1, for a more detailed explanation). We plan the work in plannable effort time, which defaults to 2/3 of the available time (~26 hrs in case of a 40 hr week), confining all unplannable project activities like email, phone-calls, planning, small interrupts, etc, to the remainder of the time. We put this work in optimum order, divide it over the people in the project, have these people estimate the time they would need to do the work, see that they don’t get overloaded and that they synchronize their work to optimize the duration.