The Magical Number 30
In agile processes, especially Scrum, 30 is a magical number. A working product increment should never take more than 30 days to produce. The reasoning, which is sound, is that you’ll know exactly what state the evolving product is in quicker than you normally would under a “traditional” process. You can then decide what to do next before expending more resources.
The trouble I have with this 30 day “law” is that not all requirements/user-stories/function-points/”shalls” are created equal. Getting from a requirement to tested, reviewed, integrated, working code may take much longer – especially for big, distributed systems or algorithmically dense components.
Arbitrarily capping delivery dates to a maximum of 30 days and mandating deliveries to be rigidly periodic is simply a marketing ploy and an executive attention grabber. When managers and executives accustomed to many man-months between deliveries get a whiff of the “30 day” guarantee, they: make a beeline to the nearest agile cathedral; gleefully kneel at the altar; and line up their dixie cups for the next round of kool-aid.