Perils of the One Month Sprint

Volatility behaves much like interest (think money). Volatility is constant over a time period. It also has a compounding effect. Therefore, while the rate of volatility doesn't change, the longer you allow the time period to be the more likely volatility will have a disastrous effect. This is, in fact, one of the principle problems (with waterfall) that iterative development seeks to overcome.

In a one-month cycle I have found two things to be true:

• Volatility has increased to the point that we are working on a non-optimized set of tasks (i.e. no longer working on most important items from the backlog).
• A month is a long enough period that developers can do a smaller version of the "back-loading" problem facing larger projects.

The long and the short is that a month is long enough we can get lazy, then try to do a rush job at the end, and by the end of the period our original assumptions have had time to get stale.

Granted, these problems are nothing compared to what you would see on a six to 12 month project, but they are creeping in. And what of the perceived benefits of more test time (for qa) and better stability and more complete docs? None of it happened. Granted, our one test resource went on vacation for two weeks, but I wasn't seeing it happen anyway.