The very first time I managed a project there was very little tracking. I would start with a Functional Specification and then using that work with the developers to come up with some estimate. After that it was left to them to deliver. If someone were to ask me when a project would be done, my answer was less than scientific.
The most frequent question a stakeholder would ask is “Are we on track?”. This question can be broken down into three:
What have we done and are we completely confident that it really is done?
How much work is left?
Are there any risks that prevent us from meeting this date?
Using the example of a shopping site from earlier, I would break this requirement “Build a shopping cart where customers can make purchases” into smaller chunks of work. In effect list everything that needs to be built, tested, migrated, created – every task we can think of into a list. See Appendix A for a sample list.
The next step would be to sit down with the developers and ask them to estimate. Estimation is a topic in itself but for now lets assume we get man-day estimates. The more developers you have the more the potential for variance. Its up to you to balance between having a lot of developers and thereby spending a lot of time and having too few so that not enough contrarian thought goes into the estimates.
Assuming you have a list and man-day estimates all you have to do is sum the total and arrive at Total Effort. Suppose Total Effort is 1000 man-days – you now know that if you have 5 developers you would take 15 months or so.
It is a good idea to validate this. One approach is to lay a timeline on a large conference table and then post names on the rows and weeks on the columns. Ask the team that did the estimation to lay the cards out and see if the 10 developers can really do it in 15 months. You may be surprised at the output of this exercise.
In the Agile world these tasks are called stories. They ought to conform to the INVEST principle (Independent, New, Valuable, Estimable, Small, Testable). There is a reason for this and it is covered in detail in Chapter 2, User Stories. I will add though that the Independent principle is important to get out of a Gantt chart mode where one task can only begin when another one is over. It is almost impossible to do this a 100% but you will find it worth your while and almost mandatory.
Another estimation approach is to use story points. Why? Again its covered in the chapter on estimation but for now let us say that this allows us to take the variabilities around days out. How many hours in a day, how good is one developer over another etc. Story Points is a measure of complexity. So if say the simplest story is a 1, the question is how much more complex are the others over this simple story.
For the sake of simplicity let us assume that our shopping cart application has a total of 1000 stories. Let us say that these add up to 3000 points. Now what?
One approach is to lay random cards down on the table and ask the developers to tell you when to stop when they feel they cannot achieve any more. If you end up with 100 points. We now have an estimate that tells us that our team will finish first iteration with about 100 points worth of value. Simple math tells us that it would take 30 iterations or 15 months to achieve the backlog.
Now if your stakeholder were to come to you at the beginning you have an answer. We know its not accurate – the only accurate estimate are the actuals – but the information we have is better than no information.
After your first iteration your team would have completed a few stories worth say 60 points. After 2 weeks you now that your estimate of an end date could be 50 iterations. And so on it goes.