Student Syndrome

One of the good concepts I’ve found while reading Goldratt’s books was the Student Syndrome, which Wikipedia defines like this:

Phenomenon that many people will start to fully apply themselves to a task just at the last possible moment before a deadline. This leads to wasting any buffers built into individual task duration estimates.

During the recent discussions about estimations, which happened in many posts, Chris Leishman wrote about the 3 reasons (P’s) for estimation (which are extremely correct, in my opinion), and selected performance as one of them. As Chris wrote:

The throughput (velocity) of a team is determined by the amount of ‘work’ being done over a given time-period and is measured in terms of the estimate.

After reading this post, I realized that measuring only delivered story points in an iteration (one thing I always thought was right), might not be enough to enable the full capacity of a team.

Explaining, story points are used as de facto standard in agile projects because they provide the separation between time and effort. This way, when I estimate a story as a developer, I have no time commitment to implement that story, and therefore cannot be blamed if I take more/less time than expected (what is probable, since estimation is just an educated guess).

While this practice is good because protects the developer from bad managers, at the same time it provides a lot of room for the occurrence of the Student Syndrome, since nobody knows if the story was completed in the predicted time or not, and all the buffers that were mentally created by the developers during estimation get lost in non necessary activities, like gold plating, for example.

And what I have been noticing in projects, is that stories that get played at the beginning of an iteration generally receive a lot more attention (necessary or not) that the ones that are being done close to the iteration’s end, which proves the concept that more work could be done, if we had some intra iteration kind of measure.

Despite being against the addition of any unnecessary metric to a project, I’m starting to believe that something should be done in this case, like reestimate stories in hours, or measuring cycle time instead of story points, or any other kind of practice that brings awareness to the difference between our estimations and what is actually happening in a story level.

Cheers.

Advertisements
7 comments
  1. Dave Kirby said:

    There was a study reported in the book Peopleware that compared projects by who did the estimating. Programmers who were allowed to do their own estimates were shown to be more productive than programmers who had an estimate imposed by a manager. Programmers who had the estimates done by a neutral outside expert were even more productive.

    The most surprising result was that programmers on projects with NO estimates were most productive of all, and by a significant margin. I suspect that if you do not have a deadline (either imposed externally or by yourself) then the student syndrome does not kick in at all – you can’t leave things to the last minute since there is no last minute.

  2. @Dave

    I can understand your point and agree that programmers with no estimates can be more productive, but I’d like to see more information about which were their motivations, and how they were being “evaluated”. What comes to my mind is that a productivity study, when people know they are going to be measured by their productivity, is different than a real project, which has many other issues.

    And even if I agree with this scenario, most projects have iterations, and that by itself is a deadline, which can lead to the problem I described in the post.

    Cheers

  3. The student syndrome is actually one of my arguments against the typical XP/Scrum practice of batching stories into iterations – eg. doing an iteration planning meeting to decide what will be worked on in the next iteration. Some argue that it creates a sense of commitment and motivation – I argue that the student syndrome will apply and the work will possibly be delayed until the last minute.

    Hence I’m much more in favour of having a continuous flow of stories pulled through a delivery pipeline, where the incentive is to simply continuously improve the throughput.

  4. @Chris

    Thanks for your comment. I totally agree with you, but I think that one important point you mentioned is the idea of throughput.

    And if you’re going to measure throughput somehow, you have to use some kind of “iteration” for that, since you need a time measure for it.

    Cheers

  5. Absolutely true. I never advocate getting rid of iterations – just not batching work into them. Of course, you can simply record the times that goal units (story points) reach the end of the process, and then use that data to calculate throughput over any time period you like depending on what you want to look at. Obviously we must take care to remember that as the time period gets smaller, the statistical variation in throughput will get larger.

    Even then, however, iterations are good because they give you a time frame in which to schedule feedback – feedback to the business in the form of a showcase and feedback from the team in the form of a retrospective or other improvement exercise.

  6. Your site was extremely interesting, especially since I was searching for thoughts on this subject last Thursday.

    I’m Out! :)

%d bloggers like this: