Project Completion Estimation
Estimation are commonly used early in the project life to guess how long and how much the project will take. Naturally it is used to measure effort, time and money. The ultimate goal of estimation is decision making. It is a tool to assist in making a decision.
I don’t share this view of estimation as an inherently evil activity. If I’m asked if estimation is a Bad Thing my answer is the standard consultants’ answer of “it depends”. Whenever someone answers “it depends” the follow-up question is “upon what”. To answer that we have to ask why we are doing estimation – as I like to say “if it’s worth doing well, it’s worth asking why on earth you’re doing it at all”.
For me, estimation is valuable when it helps you make a significant decision.
My first example of an estimation-informed decision is allocation of resources. Organizations have a mostly fixed amount of money and people, and usually there are too many worthwhile things to do. So people are faced with decisions: do we do A or B? Faced with such a decision it’s useful to know how much effort (and cost) each will involve. To make sensible decisions about what to do, you need to have a feel for both the cost and the benefits.
Another example is to help with coordination. The blue team wants to release a new feature to their web site, but cannot do so until the green team builds a new service to give them crucial data. If the green team estimates they will be done in two months and the blue team estimates that it will take them a month to build the feature, then the blue team knows it’s not worthwhile to start today. They can spend at least a month working on some other feature that can be released earlier.
So whenever you’re thinking of asking for an estimate, you should always clarify what decision that estimate is informing. If you can’t find one, or the decision isn’t very significant, then that’s a signal that an estimate is wasteful. When you do find a decision then knowing it focuses the estimate because the decision provides context. It should also clarify the desired precision and accuracy.
Understanding the decision may also lead you to alternative actions that may not involve an estimate. Maybe task A is so much more important than B that you don’t need an estimate to put all your available energies into doing it first. Perhaps there is a way for blue team members to work with the green team to get the service built more quickly.
Similarly, tracking against a plan should also be driven by how it informs decision making. My usual comment here is that a plan acts as a baseline to help assess changes – if we want to add a new feature, how do we fit it into the FivePoundBag? Estimates can help us understand these trade-offs and thus decide how to respond to change. On a larger scale re-estimating a whole release can help us understand if the project as a whole is still the best use of our energy. A few years ago we had a year-long project that was cancelled after a re-estimate a couple of months in. We saw that as a success because the re-estimate suggested the project would take much longer than we had initially expected – early cancellation allowed the client to move resources to a better target.
But remember with tracking against plans that estimates have a limited shelf life. I once remember a gnarly project manager say that plans and estmates were like a lettuce, good for a couple of days, rather wilty after a week, and unrecognizable after a couple of months.
Many teams find that estimation provides a useful forcing function to get team members to talk to each other. Estimation meetings can help get better understanding of various ways to implement upcoming stories, future architectural directions, and design problems in the code base. In this case any output estimation numbers may be unimportant. There are many ways such conversations can happen, but estimation discussions can be introduced if these kinds of conversations aren’t happening. Conversely if you’re thinking of stopping estimation, you need to ensure that any useful conversation during estimation still continues elsewhere.
Source: Martin Fowler
I do agree with Martin Fowler as mentioned above, that estimation are good for the purpose of help in making decision. It is also ultimately worthless as time passes by.
Why do estimation becomes useless ? Because estimation is created when environment are ideal. As the project progresses, a lot of unexpected things happen. Thus, the environment is no longer the same as when the estimation was first created. This disparity is what makes estimation useless as the project continues.
Re-evaluation must be made as the project continues. This is where project milestone becomes useful. At the milestone, new estimate are made about the project.
Good, But Not Ideal: Pick Your Delivery Date; Deliver Every Week from Now Until Then
The “big guys” have a date in mind. In the rare case where they don’t, pick one yourself. Pick it to be soon enough that no one can possibly get impatient waiting for your project to complete. Count your people, multiply by the time available. Guess about what you’ll have by then, with about five major items. If you must, break them down. Keep them vague: you need the room to steer. Voila! You now have a budget, complete with estimates.
Now get yourself a “customer” or “product owner” who can make decisions on what to do next and what to defer. Work in very short cycles. Two weeks. One week. One feature at a time, in two days. Short. Do features from most important to least. Every time a feature is done, or at least every two weeks, build an integrated, tested version of the software. Show it to everyone. If possible, get it to users who need it. If your software is slated to save lives, save some lives with it. Observe what happens. Factor that into what you do next.
You’re shipping a complete product now, every week or two. When the deadline arrives, it’s just another shipment. If everyone is satisfied, and likely they will be, stop. If they want more, you’re all set to do more, every two weeks.
Source: The Pragmatic Bookshelf
Ron Jeffries shares his experience with estimates and a good but not ideal solution is described above. His ideal is to actually create the project without estimating. Just do.
I do shares his concern regarding management tactics of estimating. What management want is a fixed date for completion. For projects that are big and sometime huge, this is indeed impossible to do. However, I am sure by breaking down into smaller components, the project is more manageable. There are of course trade off and a whole lot of priority shifting within the smaller components are going to happen. So, personally I pick his good but not ideal ideas.