Project Management – Explaining Time Estimation Challenges

From The Pragmatic Programmer: From Journeyman to Master:

What to Say When Asked for an Estimate

You say "I'll get back to you."

You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section. Estimates given at the coffee machine will (like the coffee) come back to haunt you.

In the section, the authors recommend the following process:

• Determine the accuracy that you need. Based on the duration, you can quote the estimate in different precision. Saying "5 to 6 months" is different than saying "150 days". If you slip a little into the 7th month, you're still pretty accurate. But if you slip into the 180th or 210th day, not so much.
• Make sure you understand what is being asked. Determine the scope of the problem.
• Model the system. A model might be a mental model, diagrams, or existing data records. Decompose this model and build estimates from the components. Assign values and error ranges (+/-) to each value.
• Calculate the estimate based on your model.
• Track your estimates. Record information about the problem you are estimating, your estimate, and the actual values.
• Other things to include in your estimate are developing and documenting requirements or changes to requirements specifications, creating or updating design documents and specifications, testing (unit, integration, and acceptance), creating or updating user's manuals or READMEs with the changes. If 2 or more people working together, there's overhead of communication (phone calls, emails, meetings) and merging source code. If it's a long task, account for things like other work, time off (holidays, vacation, sick time), meetings, and other overhead tasks when picking a delivery date.

Although quite heavyweight, whenever I have had to document a software design I usually went for the MIL-STD-498. I'm not saying you should produce (at least one of) each of the 22 document types it consists of, but rather to just choose one or two that make sense and then use the layout as a general guideline.

The one you might need is the Software Design Description (SSD). The nice thing about this approach is that you more or less dodge a discussion about whether your document will contain at least the required parts (it's one of the good things about using a standard that people tend to assume it's good for what it's for).

The documents tend to cross-reference heavily, but instead of writing all the other documents you can just define these things in-place in the document.