I believe we should consider these points for estimation process. there may be more, pls feel free to add.
1.
Risks,
Scope and complexity of the project
2.
Domain/Functional/Technical
Knowledge for requirements of team
3.
know
strengths and weaknesses of individuals team members for requirement
4.
Know
weaknesses of requirement with analysis meetings with functional expertise
team members, QA, Architects and business analysts.
5.
Process time:
process hours of project (including QA push
process, development label creation, SCRUM meeting and any developer
environment setup (not main environment setup) )
6.
Development
time: real development hours
7.
Unit testing
time: unit testing hours
EXCEPTION Handling:
8. Developer buffer time
a.
waiting period for dependency information
b.
Estimations Can Go Wrong
c.
Unrealistic interpretation of original requirements
d.
Inadequate/unclear requirements
9.
Management
buffer time ( Buffer time as per risks of project)
a.
Availability of All the Resource
b.
System outage
c.
Estimations Can Go Wrong
Few points
1.
Historical data for the previous estimation for
improvement and accuracy
2.
It’s good to include assigned developers in
estimation process after 1st level of estimation (after Architects estimate).
3.
In estimation process, it will be good to give
enough time to developer so he can at least go through limitations of current
system and resource, learning curves of new technology for project.
4.
It will be good, if we get time for proof of
concept depends on project, if project needs proof of concept.
5.
More meetings with business analyst and QA will
help to understand and streamlining the project requirements.
6.
Estimation will be more accurate and efficient
if developer will be included in design phase.
