In many respects, agile development can already be considered a more efficient software development methodology – it’s hard to believe that this process can be accelerated even further. While there are a number of things that you need to do to properly manage the risk of agile development, the cornerstone of this process is the iteration document which describes the features you are implementing.
Generally speaking, in agile it really isn’t possible to estimate the project completion. This contrasts against other techniques such as waterfall where the completion of one project milestone is the beginning of the next major effort. In this regard, one might wonder if it is even necessary at all to estimate completion time for your iterations at all.
“To increase productivity, you have to produce the same output with less work. Estimating is a lot of work, and if you can cut it out, you produce more.”† (Andy Singleton; Distributed Agile – Interview)
In software development, there are only a few ways for deadlines to be set:
- Client / Executive Management. These tend to be milestones that are important to the business or contract. If you don’t meet this deadline, the value of your application may quickly become irrelevant.
- Project Dependency. On larger projects, your application or toolkit may have a dependency with another project. For example, the latest version of Microsoft Windows won’t ship until the Windows Calc team releases.
- Arbitrary. These kinds of deadlines are generally set by the development team and don’t have any real consequences other than a potential for delivering late.
The first two deadlines don’t really require any estimation, so these are fairly easy to establish. Whether or not you are actually able to meet the delivery date is irrelevant, the software is required by the business and therefore must be completed on that date.
An arbitrary deadline, however, requires the development team to assess all of the potential tasks and using a time-line resolve how long they think it might take to complete. Unfortunately, the process is in fact rather time consuming and will likely require weekly or bi-weekly meetings where the team reevaluates the current status to determine if the deadline can be met.
Is this effort to estimate the project completion really worth the effort? You won’t finish developing any sooner, and if you have already prioritized you will already be working on the most important features first.
Using an agile development process, you can continue to implement as many features as possible until the date has been met. At that point, whatever capabilities are ready will be those that are representative of that release. Of course, the business may reassess the viability of the software if there are certain critical components missing and may choose to extend the date so that certain features can be finished.
Assuming there is any reasonable amount of development time available, the agile process ensures that you implement the most important features first. If your project has any estimates for delivery date, they should simply reflect when the business requires the program or when your project dependency must be met. There is no real need to consider these date estimates, simply accept that as your project completion milestone and begin implementing the most important features first.