This question already has an answer here:
- How to answer “When will it be done?” 9 answers
I'm working as a developer / architect on a software project. The project manager decided not to follow the Agile principles, but to rather have an Excel sheet with all the feature requests and their estimated (remaining) effort. I'm required to update the estimated remaining time of each feature that I'm implementing weekly.
The problem is: with bugs and requirement changes constantly incoming, the remaining effort doesn't change as fast as the manager expects. Say, it was "12 days remaining" about 2 months ago, and today it's still "7 days remaining". The manager is rightfully getting nervous about this, because he can't give a release date for the potential customers and the marketing department this way. What is the best way to solve this problem? I think the main goal would be to be able to give a release date that makes sense. How could one achieve this?
Now, my suggestion at the beginning was to:
Set priorities for all the features. This didn't work out well, since about 70% of the features got priority 1, all the others got priority 2. And the verdict was: all features must be included in the first release.
Reduce the number of features, or reduce the complexity of the features which are the most difficult to implement or unnecessarily complex (meaning: no user will ever understand how it works). This also didn't bring much, all features must be implemented as they are, and even more features were added.
Add bug fixing & feature change estimations as they come. This is what we normally do in another project at this company. The result is, that sometimes the work remaining goes up between weeks instead of going down. This also wouldn't solve the main problem (release date?).
I'm running out of ideas... The manager has told me that he thought my estimations mean the time required to write bug-free code... No comments on that remark. He also said he expected me to include the estimation of bug fixing in the initial estimation. Yes, to include the effort to solve a bug which we don't even know if it exists...
His other suggestion was that I write my tests so that they cover every possible case. It would make sense, but having such complex features and a very large and complex background service we are calling from this application, it would take forever to cover every scenario with integration tests. I don't think we can ever achieve 100% coverage.
Edit: The questions How to answer "When will it be done?" and What can I do to get better at estimating how long projects are going to take? might appear similar, but are not relevant to my situation. I have already given an effort estimation. My question is related to the progress of the development, and changing estimations / deadline.