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
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
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.
The types of metrics I collect:
Here's a few good ideas which you should consider: