> Your system makes two assumptions that have been thoroughly, repeatedly proven wrong: - It's possible to know what tasks are required to complete a project at

> Your system makes two assumptions that have been thoroughly, repeatedly proven wrong: - It's possible to know what tasks are required to complete a project at the outset of a project. At some point though, once you've decided what tasks to work on, how much they cost (in time, dollars, risk, etc.) is a very important question. The answers will always be guesses, but tracking what actually happens over time helps to improve future guesses. > - It's possible to estimate how long those tasks will take to complete. One cannot eliminate all uncertainty, but it is possible to decrease it over time. A way to do this that I found works well is to look for past tasks that are sufficiently similar in size and complexity to the one being estimated and use the tracked data to anchor the new guess. You track as you go in order to build this log. I should emphasize that I think this data should be there to help developers improve their estimating abilities, and not for the management to judge developer performance. > Furthermore, "if it can't be measured, it can't be managed" is true to a degree, but over-reliance on metrics can result in tunnel vision towards those metrics, resulting in accumulation of technical debt, quality issues, less team cohesion and a host of other problems as your teams myopically focus on hitting their numbers above all else. Very true. However, never measuring or logging anything out of a desire to avoid the things you've enumerated can deprive a team of valuable information and lead to missed learning opportunities. The trick is to find the right balance.