Release Date

Finally, a date is set. Motivation is difficult if you feel you're putting your work into a black hole, paddling up stream, etc. That's true of any project under any methodology. Release date problems come in two forms: Setting an overly aggressive/arbitrarily early date, or failing to set a shipment date at all. We were in the latter category. Most projects I've worked fall into the former, however. But it's not quite that simple.

The optimal release date for a project is not so much a line as a large, grey band, fading from red (too early) to black (too late). As you approach any given date, the likelyhood of that date being the correct date becomes more focused. A wise project manager will defer giving dates as long as possible, and give them with great qualification. The doesn't help the business owner who needs predictability for sales and training. This is all old news, so far.

Our real question at this moment is "How is Agility helping me set and ship on my release date?". Well, for us it is allowing us to view how many features are done (ready to go with product) and how many features are outstanding. We can limit the variability in our estimates because we constrain future estimates to what remains, no some ambiguous shot in the dark. So we have set an arbitrary ship date. With our project backlog we can see most importantly what is not going to be ready by date X. Knowing that, we are able to work with the business owner to determine if this is acceptable functionality, or a date needs to be pushed.

In our specific case we have not been able to fully integrate QA, so we are requiring a trailing QA cycle (as under SDLC) to finalize the product for this realease.