In the agile methodology, developers provide estimates on features. Features must provide business value,be small enough to put into a sprint (or work iteration), and have enough definition to provide an estimation for. If a feature is too big for a sprint, it needs to be broken down further.
I’ve worked with developers that estimate high, and developers that estimate low. I’ve even worked with developers that flat out won’t provide an estimate until it was almost completed.
I’ve learned the following things along the way:
1. Question the estimate. Why does it take twice as long to do X when Y had similar functionality? As a project manager, you aren’t a number pusher. It’s important to understand what’s behind the estimates.
2. Respect their final estimate. By getting the estimate from the developer, you are also giving them a chance to take more ownership in the product. If you decrease their estimate by too much on the project plan, they would feel disregarded and potentially lose motivation. If you increase their estimate by too much on the project plan, then provide reasoning why (extra tests are needed, etc).
3. Start off with a new development group at taking their final estimates at face value. As a project manager, you aren’t sure which ones tend to quote high and which quote low. As you get to know them better, you can refine it as you see fit.
4. Push for an estimate or find out why one can’t be given. If the developer cannot provide an estimate, likely they are uncomfortable with the definition or with the technical skill required to pull it off. Offer to have additional design sessions, and potentially send them to training if a new skill is needed.