A question that comes up quite a bit is how to do proper estimating. It’s not an easy thing to quantify as much of involves gut feeling at times. It’s why I feel that estimating is an art, not a science. The hard thing about estimating is that it takes experience to know if you’re doing it right or not.
My first bit of advice is start using a tool to track your time. If you can’t do it by specific task, as least do it by overall project. Once the project is done you can then see if your estimate matches reality. It won’t at first but that’s why you track your time so you can make adjustments on the next project. After looking at several projects I came up with the idea of the times three for estimates.
When you look at part of a project, say a form, your estimate tends to be something like this: if I know everything up front and there are no major surprises this is what is how many hours it will take to complete the programming and testing of this form. However, we rarely know what those major surprises are up front so at best this is my guess and multiply it times three to come up with a more realistic estimate.
After a while I started to realize that some forms just aren’t going to take that long. An About Window just won’t take more than fifteen, twenty minutes – ever – so why do the multiplier on that? It makes no sense.
What makes one form harder to develop and test than an other? Complexity. A simple List form and an Add/Edit form might take an hour each (if that) to complete but busier versions of both might take three to four hours each.
What brings in the complexity? Well, that depends on a number of factors. Number of controls on the forms is a good start. The business logic is another. If how things work depend on what the user is doing in the controls you can rest assured that programming and testing of it is going to take longer than you expect.
Another part of complexity is the number of unknowns. If you have to do a complex calculation that involves a bunch of math (especially if you’ve never done said math before) it should up the complexity. Doing some programming concept in Xojo that you’ve never done before should up the complexity as well. In both cases you should expect some research time, maybe even time to do a small example project, and a restart or two since you’re learning as you go.
In my initial guess I still do the ‘if I know everything up front and there are no surprises’ estimate. And then my multiplier is my feeling of the complexity of that part of the project. The complexity factor is now my multiplier. So an About Window has a complexity of one. A simple list form has a complexity of one and half, but a form with several page panels or containers that do different things based on user input might be a complexity factor of three or four (or more).
I tend to break projects down to several parts. The first is overall project design. There are certain number of hours just to set up the project and create the classes I need. There’s usually some database design and implementation. Do I need to make any special classes or subclasses for functionality that I already know about?
When it comes to the UI I often take the database design as the guide. Each database table is (probably) going to need a List form and a way to edit it. Figure that a list table is only going to need a few of the fields for listing but the Add/Edit form is going to use all of them. Are they all text fields or is it a mix of lookup fields with foreign keys? Each of these adds to the complexity of the forms in question.
Coming up with an estimate is sometimes an art. It takes experience (and failing a few times) to get the hang of it which is why you need to track your time. Using the complexity as a multiplier might be a good way for you to start getting more accurate estimates.
Let me know if you do something different for estimating. How do you track your time?