1. Iterations can be too short.
The general recommendation is that iterations should be as short as possible - we decided at the outset to try 4 week cycles however we subsequently moved to 6 week cycles. We did this for 2 main reasons:
- The overhead of Scrum (1 day planning & 1 day review & retrospective) per team was too big. We run 2 separate teams - therefore the overhead on a 4 week iteration would be 3-4 days every 20 - which I think you will agree is not very desirable. Management (especially me!) found that the planning overhead very burdensome and the teams felt that they were only really hitting their stride when they had to stop and re-plan. So we changed it. There are times when the 6 week cycle is quite long - when an analysis task (we call this a SPIKE task) must be completed in one SPRINT in order to facilitate planning for a subsequent sprint. This can cause an undesirable sequential dependency which can be worked around by good ol' fashioned common sense if it causes a problem.
- Our product stories tend to be quite complex - by this I mean that we are not building a web app in which the delivery framework is well understood and the functions discrete. We are building middleware infrastructure with deep dependency chains which straddle tools, runtime and management infrastructure. In order for each iteration to be "potentially releasable" (Ha Ha) - we wanted to be able to define stories at a product capability level, we did not want our stories to straddle multiple sprints if we could help it.
We found that 6 weeks encompassed all but the most fiendish stories so we settled on this.
