Mastering the Art of Estimation in Programming Projects
Written on
Understanding the Estimation Challenge
When tasked with programming, a common question arises: “How long will it take to complete?” In more demanding environments, it may be phrased as, “What’s the delivery date?” This is a standard inquiry.
To tackle this, I rely on my past experiences, breaking down the project into manageable tasks. However, I often find myself feeling uncertain about my estimates. Many others share this sentiment, grappling with the anxiety that accompanies making estimations.
In this article, I aim to share insights from my experiences and provide guidance for those seeking to improve their estimating skills—something my boss frequently inquires about.
The term "estimate" can have multiple interpretations. Here, I will focus on estimating the timeline for product releases and the duration needed to complete specific features.
Why Is Estimation Important?
Making estimates is crucial for several reasons. Firstly, it informs investment decisions. Understanding the timeline helps calculate the financial implications of developing a product or feature, determining whether the investment is justified. Saying, “I don’t know how long it will take; it’ll be done when it’s done,” is not sufficient.
Knowing the estimated timeframe also aids in planning marketing strategies and resource allocation. Without clear estimates, it becomes challenging to make other plans.
What Makes Estimation Difficult?
The primary challenge lies in the numerous uncertainties involved. For instance:
- The time required for unfamiliar tasks is unpredictable.
- Unexpected challenges can arise.
- The learning curve for new frameworks and technologies is often unclear.
- Bugs can appear unexpectedly, and their resolution time is uncertain.
- In collaborative environments, the pace of team members can vary, complicating the process further.
Given these uncertainties, it’s rare to fully grasp the scope of a project initially. Although the necessity of making estimates persists, many hesitate to provide them due to the inherent unpredictability.
The Complexity of Estimation
The high level of uncertainty complicates the estimating process. Nevertheless, by breaking down tasks, leveraging previous knowledge, and making realistic assumptions, we can still create estimates.
Another layer of difficulty arises when the deadline is tied to the estimate. If I tell my boss, “I expect to finish in a week,” I must meet that expectation, even if it means putting in extra hours. Thus, even when I estimate a week, I can't confidently assert that it will indeed be completed in that timeframe.
I often think of my estimates as having a variance of 50–200%, acknowledging that the reality may differ significantly from my initial calculations.
Methods for Estimation
While uncertainty poses challenges to estimation, it is crucial to adopt a sincere approach when faced with these hurdles. One effective method used in agile development is estimating through “story points and velocity.”
Story Points
Due to uncertainty, assigning absolute values to tasks is challenging. Story points enable relative evaluation instead. For example:
- If Task A is rated at 5 points, and Task B is expected to take twice as long, it may be assigned 10 points.
- If Task C is less time-consuming than Task B but more complex than Task A, it might be rated at 7 points.
This relative approach allows for more accurate assessments, as humans tend to be better at relative evaluations than absolute measurements.
Velocity
However, story points alone do not provide actionable insights. To convert these points into timeframes, we measure how long it takes to complete each point. For instance, if a feature development is estimated at 80 story points and it takes one day to finish an 8-point task, we can anticipate the feature's completion in 10 days.
Burndown Chart
A burndown chart visually represents “total story points,” “completed story points,” and “remaining story points” over time. If the project proceeds smoothly, the remaining story points will follow a downward trajectory, indicating progress toward the project’s completion date.
Communicating Estimates Effectively
The pressure of deadlines can lead to inflated estimates, as we often add unnecessary buffers to our projections. Instead of saying, “It will be done in two weeks,” a more transparent approach might be, “We estimate that it will take between 4 to 10 days. We aim to achieve this within the first three days.” This method fosters clearer communication and acknowledges the inherent uncertainties of the estimating process.
Revising Estimates
When a task that was estimated to take two days extends to three, I often reflect on the reasons behind the discrepancy. The pressure to meet schedules can lead to rushed, unmaintainable code and overlooked bugs.
Instead of hastily adjusting future estimates, it's more beneficial to analyze the miscalculation and revise estimates accordingly. For instance, if a task takes 1.5 times longer than expected, I would adjust the story points to reflect this reality, refining the accuracy of future estimates.
Conclusion
In this discussion, I shared my thoughts on the complexities of estimating within programming, particularly through story points used in agile methodologies. Each reader’s context may differ, and not every method will be universally applicable. I hope these insights prove helpful.
For more content, visit PlainEnglish.io. Sign up for our free weekly newsletter, and follow us on Twitter, LinkedIn, YouTube, and Discord.
This video discusses whether programmers are truly at fault for inaccurate estimates, offering valuable insights into the estimation process.
In this video, learn how to determine if your manager is trustworthy, which can impact your project estimations and overall work environment.