Playing Games with Estimates and Deadlines

Probably the clearest example is creating slack time for a project. The worst case of poor estimating is when the manager doing the final estimate does not allow any time for false starts or even bathroom breaks. This is almost as bad as missing Christmas because you did not get the memo indicating the date!

Slack has a negative connotation, indicating not paying attention to something or laziness . This is unfortunate, as it is the lack of slack time that causes many schedule, and thus cost, overruns [DeMarco02]. The XP concept of velocity is not a part of these estimates. Therefore, a meeting called suddenly by the boss causes the product to be as late as the meeting is long.

How do conscientious managers keep slack in their schedules? By keeping two sets of books; essentially , lying. As an example, let us take a short development cycle of three weeks. Let us say that there is enough slack time in the tasks and that the cycle, with slack, is four weeks long. The manager knows that a schedule can be a self-fulfilling prophecy [Abdel-Hamid89]. Therefore, the manager tells the developers three weeks and upper management four. This way, the manager can be budgeted for the four weeks the bosses think it will take, while the development team will strive to be done in three weeks. When they eventually finish, in three weeks and a couple days, the developers are not too surprised by a little lateness in schedule, and upper management is very happy that they saved money. The two-faced manager looks like a scheduling genius.

Eventually, upper management notices this team never uses all the funds allotted to it, and the developers realize that they can be late a couple of days without serious repercussions . Pressure is exerted in both directions. The manager in the middle appears to be like other colleagues in poor estimation again. The game is over.

How much slack is needed? The difference between velocity and full-time work. The developers can never be 100 percent time on task, or they would not be human. For example, one of the authors (Tomayko) once worked for a large software development organization. He noticed some workers who took forever, it seemed, to get started in the morning. These persons would talk to those already working by peeking over cubicle walls, coffee cup in hand. Of course, little or nothing would get done during that period. There were also breaks and lunch . Velocity is a concept that resulted from managers and programmers realizing that a day is not a full day.

There is some slack time needed even if velocity is used. As an example, some time must be scheduled for rework if software inspections are to be used. There is no way of knowing how long rework will take, since the results of inspections are not known when they are scheduled. One solution is to look at the historical data on the length of such work. The game described previously can be played for this effort. Other slack time is needed for change. In an XP project, the cycles are kept short and unit tests are part of development, thus minimizing the effects of change.

Again we ask, how much slack? And, again, we can use historical data. Of course, we assume that a CIO does not get off a plane from a conference and say, We have to have X by this time next year.

Task  

Make a one-month schedule for a software development project with appropriate slack time for each task.