My goal with this article is to share good planning practices which I find to work well in practice. A fundamental difference between agile planning and traditional planning is that agile planning is very collaborative in nature: the team is responsible for planning, not just the project manager. In this article I discuss:
Figure 1. The schedule at iteration one.
Figure 2. The schedule at iteration five.
Figure 3. The schedule at project end.
Many organizations struggle with the concept of iterations. This advice should help:
The best estimates are:
Questionable software development practices are motivated by the decision to develop an accurate up-front estimate. To develop such an estimate you need to understand the requirements which you are supposed to implement and the architecture which you are going to build to. The desire for greater accuracy increases the need for more detailed information, which in turn motivates you to adopt:
Ironically up-front estimates are often motivated by the desire of organizations to reduce their financial risk on IT teams yet in practice this decision not only has the opposite effect it also motivates you to increase your technical risk too. My experience is that when business people are educated on the impact of this strategy, and when they're given other viable strategies for planning and governing IT teams, they soon choose to abandon up-front estimating. I highly suggest getting senior IT management and senior business management to sit down and talk with each other about this critical issue.
See also:
The types of metrics I collect:
Here's a few good ideas which you should consider: