How long will it take?
How we estimate.
Estimation is one of the most difficult practices in Software Engineering. Since every software product is created in a project, the effects of effort with respect to time and cost cannot be overemphasised. Estimation is how agile teams tell the amount of effort a chunk of work would require. Some may measure this in terms of how long it would take to build out a feature; some measure it in terms of complexity. Estimation is difficult because it is far from being objective. Factors like ranging from developer proficiency, down to “what side of the bed did the developer wake up on” can have an effect on the estimate. Having a discussion about estimation, I am reminded of @HowWeLearn’s methods towards estimation; circa familiarity.
I prioritise developer autonomy. Team members should be sovereign in the domain of their work [and play]. It is in this sovereignty that innovation is born and born strong. It’s best not to hamper this sovereignty by imposing stringent timelines. It is my job as a project manager to foresee these timelines long before they become urgent. With this foresight, I prioritise upcoming work.
When estimating…
If you know the solution of the task you are about to estimate…
- If you estimate using points, keep the point you used in estimating this.
- If you estimate using hours, multiply the original estimation by 1.1
If you are aware of the domain of the task but have to do some research…
- If you estimate using points, bump your original point estimation by a whole point in your scale.
- If you estimate using hours, multiply your original estimation by 1.3
If you have to research on how to solve the task at hand…
- If you estimate using points, bump your original point estimation by two whole points on your scale.
- If you estimate using hours, multiply your original estimation by 1.5
Estimation in #SoftwareEngineering is still a very hard challenge. There is no shotgun solution to solve this across teams. Adopting @HowWeLearn’s ideologies around estimation has increased alignment between development teams and business needs for me thus far. With time and experience in a team, as a software development team matures, the team would form its own methodologies around estimations.
