Basic rules for estimation

basic_rules_of_estimation.md

##Basic Rules of estimation

• There are no fixed set of rules for estimation, but still there can be some based on what we have experienced so far in "Agile" projects. The so called "Waterfall" project execution model is obsolet and rarely used because now the products are constantly evolving and features are removed/added very quickly based on business dicisions ( :'( We all hate this! But its truth! )

• Understand the requirements first, in detail

• You should avoid estimating what you can count. And if you can't get a count, you should at least try to compute the estimate from a related count.

• Identify use cases and clarify each and every step for them. This will give more insights about the requirements, and clarifies whole flow.

  • Like, What user will do here, when he clicks what happens, when he enters wrong/no data, what if file is bigger

• Design first, and in detail

  • Identify diff. areas of implementation, try to define database structure, think of converting user-actions/use-cases into code and research what needs to be done for that and how.
  • Design means - system flow, classes, pages, APIs, utilities/re-usable components etc.

• Break down to small tasks, think of each one separately

  • As a rule of thumb, each task should be from 2 to 16 hours. If you have a 40 hour (one week) task on your schedule, you're not breaking it down enough. These numbers exist because the OP is the target customer for this sort of information: they're asking for useful specific guidelines. A two hour estimate minimum is useful because it forces you to think about your work day in terms of beginning, middle and end (and epilogue if you managed to fit in another two hour task). Any less than that is likely too fine-grained: if you're trying to decide whether a task will take 15 minutes vs. 20 minutes, you're just going to become frustrated and annoyed. 16 hours is a nice number also because it forces you to say, "if there's a task that's going to take me more than two days, it's really more than one task that I need to break into component parts."

• Consider testcases, integration time, debugging time, testing time, deployment time.

• Implement a prototype/Demo/POC if you think that without it, it is worthless to give an estimate. Such research is needed in some API integration cases.

• More developers != quick development

  • When more people are added in team, it will increase the complexity exponentially. More people means more parallel work going on, more collaboration, merging, code reviews, discussions will go on. If everyone is not able to contribute his/her share, then it will ultimately waste time of other responsible team mates OR the team lead and this will burn more hours then we have assumed.

• What if scope changes?

  • This is something we can't do anything about, except that we cleanup the old implementation completely if its of no use and estimate the new change. Any new change in functionality needs to be estimated as a new feature.

• People are naturally hesitant to provide wide ranges – even when the confidence level requires a wide range to be accurate – because they feel that narrow estimates are a sign of a better estimate.