In recent days, I have been working closely with Craig larman to bring out a new domain modal based on scrum for Valtech cockpit. During the discussion with Craig, he talked about how stakeholders ask for % completion of the project and, how our PMs give them a %(percentage) !! It all looks idiotic if you read the rest of the following section.
The core reason for introducing agile methods in software is to manage the changes, adapt accordingly and be open to get changes. As per the statistics, change requests increases as the project size increases. If we are getting more changes obviously it would add more effort to existing estimated effort and this becomes a moving target. How can anybody estimate how much % of project has completed in this scenario? It is as good as telling not the truth, if I tell my stakeholder that we have finished 50% project !! (Unless you add a clause saying "as of today")
So, instead of using "% Complete" as the measurement, one can use the "estimated effort" remaining to complete the project
1 comment:
One of the most difficult aspects of software development (agile or not) is scope management, that is handling change requests during the development process. This may be difficult if the stakeholders don't understand how software development works, but it can also be difficult if the project team does not or cannot push back when change requests come pouring in.
Stakeholders requesting a "% Complete" usually don't understand software development, but at the same time, as developers you should always have an idea of "how much work is left?" I strongly endorse the idea that you mention of tracking and reporting "Estimated Hours Remaining" or "Estimated Effort Remaining", and try to use those numbers to come up with a reasonable and descriptive status for your stakeholders. It's all about visibility.
Post a Comment