Agile Network India | Meetup | Software estimation for developers | Sachin Divekar
- 1. Software Estimation - Sachin Divekar - MTS, - Merce Technologies
- 3. Estimates, targets and commitments
- 4. Estimate: Prediction of how long a project will take Target: Statement of a desirable business objective Commitment: Promise to deliver a feature with given specifications
- 5. Estimates and plan Estimates Unbiased and analytical Plans Biased and goal-seeking
- 6. Estimate as a probability statement
- 7. Estimate as a probability statement
- 8. Estimate as a probability statement
- 9. Importance of an accurate estimate ● Project control ● Improved status visibility ● Higher quality ● Better coordination with non-software functions ● Better budgeting ● Early risk information
- 10. Estimation Errors Cone of uncertainty
- 11. Functional and non-functional omissions Functional ● Setup/installation ● Data conversion utility ● Glue code needed to use third party or open source software library Non-functional ● Maintainability ● Performance ● Portability ● Responsiveness ● Reusability ● Security ● Reliability
- 12. Commonly missing software and non-software development activities Software development activities ● Ramp-up time for new team members ● Mentoring of new team members (for team leads) ● Demonstrating software to customer/management ● Installation ● Requirements clarification ● Creation of test data ● Managing and supporting deployments in various environments ● Code reviews ● Learning new development tools ● Coordination with testers (for developers) ● Coordination with developers (for testers) ● Documentation Non-software-development activities ● Vacations ● Sick days ● Holidays ● Weekends ● Company meetings ● Other events in the company ● Troubleshooting hardware and software problems ● Setting up new workstation
- 13. Other sources of errors ● Unfounded optimism ● Subjectivity and bias ● Off the cuff estimate ● Unfamiliar business area ● Unfamiliar technology
- 15. Tips
- 16. ● Distinguish between estimates, targets, and commitments. ● When you’re asked to provide an estimate, determine whether you’re supposed to be estimating or figuring out how to hit a target. ● Don’t intentionally underestimate. The penalty for underestimation is more severe than the penalty for overestimation.
- 17. ● Include all necessary software-development activities in your estimates, not just coding and testing. ● Don’t give off-the-cuff estimates. Even a 15- minute thinking will be more accurate. ● Don’t assume that effort scales up linearly as project size does. Effort scales up exponentially. ● Count if at all possible. Compute when you can’t count. Use judgment alone only as a last resort.
- 18. ● Look for something you can count that is a meaningful measure of the scope of work in your environment. ● Avoid using expert judgment to tweak an estimate that has been derived through computation. Such “expert judgment” usually degrades the estimate’s accuracy. ● To create the task-level estimates, have the people who will actually do the work create the estimates.
- 19. ● Decompose large estimates into small pieces so that you can take advantage of the Law of Large Numbers: the errors on the high side and the errors on the low side cancel each other out to some degree.
- 20. ● Don’t debate the output of an estimate. Take the output as a given. Change the output only by changing the inputs and recomputing. ● Understand that executives are assertive by nature and by job description, and plan your estimation discussions accordingly. ● You can negotiate the commitment, but don’t negotiate the estimate.
- 21. ● Treat estimation discussions as problem solving, not negotiation. Recognize that all project stakeholders are on the same side of the table. Everyone wins, or everyone loses. ● Generate as many planning options as you can to support your organization’s goals. ● Resolve discussion deadlocks by returning to the question of, “What will be best for our organization?”
- 22. Thanks!