Session Title : Software estimation for developers Session Overview: Software developers don’t like to give estimates. They like to write code and think that is their only job. As a result, if they give some estimate it is given without paying much thought to it. In this talk, I will try to explain why software estimation is important for any developer and how they can go about it. Key Takeaways * Importance of estimation * Estimation approaches * Things developers should not miss while estimating * Tips and tricks

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

14. Overestimation and underestimation

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!