If you have an iterative development process like scrum you will split up the project in sprints. According to the scrum theory you should define a fixed duration for sprints. This is a good practice but I prefer sprints of variable length. Why? Because you should not plan your project with focus on a development process, you should have the focus on the customer. As result of each sprint you want to deliver a set of features which creates customer value. And of course such feature sets will nearly never with the fixed sprint length you may have defined.

But independently of your choice, to have a fixed or variable sprint length, you may want to define the number or length of the sprints for your project. This definition should be done for each project because it depends on the project circumstances. The two main influencing factors for me are: uncertainty and preferred review procedure.

 
Uncertainty

Why do we develop in iterations or sprints? Because we want to weaken the uncertainty we have in software projects. The final software product will always differ from the product you have specified at the start of the project. This difference may be small or large but you will ever have some unclear, new, dropped or changed requirements during a project. Therefore also the good old waterfall principle is not done in a straight line. Also this principle contains the advice to develop in iterations.

In summary we want to implement the software solution to compensate and minimize the negative effects of the uncertainty. But the uncertainty varies in every project. So we also vary the iteration count and length. Therefore my advice is: Define the number and length of your sprints with respect to the grade of uncertainty in your project.

 
Review procedure

A second influence factor is the preferred review procedure. At the end of each sprint there is a review with the product owner. It makes no sense to finish a sprint without such a review and therefore without any feedback. So you have to respect you product owner and his willingness to do reviews. Especially if such a review generates high costs for the product owner.

Therefore, at the start of the project, you have to define review intervals with the product owner. Afterwards you can organize the number and length of your sprints with respect to this review interval.

 
Rate of uncertainty

As described, the iteration frequency is mainly driven by the grade of uncertainty in your project. And the uncertainty depends on the quality of customer requirements and their change frequency. To evaluate this you may ask yourself some questions:

• Does the customer exactly know what he wants?
• Can the customer define his wishes well?
• Do the wishes and actual needs match?
• Is it possible to minimize the difference between the wishes and the actual needs before the implementation starts?
• Is it possible to define clear acceptance criteria’s for the customer wishes?
• How often the customer change his wishes?
• How much effort do you expect for the implementation of the customer wishes, especially compared to their change rate?

If you have to answer this questions several times with “I don’t know”, “That’s unclear” or “This may change very often” then you have to use a higher iteration frequency with short iterations.

 
Summary

It is not necessary to do all projects with agile development processes, but each project should be carried out with the appropriate iteration frequency. And this frequency depends on some factors given by the project. So you should find and define the right iteration frequency at the start of each project.