Like every product, this one has a deadline. We need to look at all the things we might do and decide which ones we will do. Here s how we do it.
According to Extreme Programming, here s how we should plan all projects for the best results by the deadline:
Break down what has to be done into small chunks .
Estimate each chunk in terms of value to the project and time needed to do the chunk .
Choose chunks to do based on their estimated value and time.
Do some chunks.
Measure velocity of doing (chunks per unit time).
Use velocity to predict how much can really be done by the desired date.
Use experience to refine relative precision of estimates.
Managers and customers often resort to pressure or demands when faced with a deadline. As developers, we know that this doesn t work, and if they re paying attention, managers and customers know it too. Despite the pressure, they still don t get quite what they want, and if they put too much pressure on, the quality suffers. The tendency is to blame the developers, but frankly this is silly.
The right approach is to know how hard each feature is and to know how fast the team is at implementing features. Then, using this information, plus the value of each proposed feature, choose what to do next . Teams that use this approach find that they operate with much more knowledge of what s going to happen and with much less stress. They re able to produce code that actually works. And, perhaps most valuable , the team will begin to negotiate the feature content based on information rather than sound volume.
We re using this process very informally here in the book, to decide what we should do next for the XML Notepad.