Original article:Effort estimation

Can you do this by Friday?

• Looks doable, I will try

What's wrong with this conversation, and other factors that can wreck your estimation:

Ambigous/Incomplete Requirements

The this word above...

Ambigous inputs will cause problems all the way down the production

One way to handle this is by capturing use cases. (describing how the user will use the software and explore all the scenarios).

Using assumptions/gut feeling

Don't think if you have already done something similar before, it will take the same time

Large scale

Find and identify you threshold (e.g. 3 days or 3 hours) above which your estimates will not be precise/reliable.

Single point estimates

E.g. if something has to work perfectly the first time, but if it doesn't? In this case, single point estimates are very bad. Adding some extra padding just hides the problem is not a real solution.

You need more discovery work, ask questions to clarify with the customer what options they need exactly in the software.

They are giving a range estimate for different options, then the stakeholders can decide which one they want.

One way to gain time when asked for a single point estimate is to ask them to create a proof of concept. This will reveal the risk points.

Bad work practices

Estimates the usual suspects

Reference: Software Estimation, demistifying the Black Art – Steve McConnel

• ramp up time for new team members
• mentoring of new team members
• deployment
• data conversion
• installation
• requirements clarifications
• maintaining the revision control system
• supporting the build
• creation of test data
• participation of beta test program
• processing change requests
• attendance at change-control/triage meetings
• coordinating with subcontractors
• technical support of existing systems during the project
• maintenance work on previous systems during the project
• defect-correction work
• performance tuning
• learning new development tools
• administrative work related to defect tracking
• coordination with test
• coordination with developers
• answering questions from quality assurance
• input to user documentation and review of user documentation
• demoing software to customers or users
• interacting with clients or end users; supporting beta installations at client locations
• reviewing plans, estimates, architecture, detailed designs, stage plans, code, test cases and so on

Precision = Unintended confidence

Make sure you are still rounding up your numbers even if you broke down your estimate into lots of small chunks. This gives you a false confidence that the total number must be precise, but it's not true. So if you have 30 tasks and the total number is 90 hours, still round up to at least 100, the same way you don't say you arrive at 14:58, but say 15:00. 15:00 implies usually between 14:45 and 15:15, but 14:58 implies between 14:56 and 15:00 so you have much less of a margin of error.