This reflection is based on my work on Club Oven Lovin’, a team-based software project that began on November 14 2025 and ended on December 13 2025. I served as both a team member and, at times, a team lead, contributing to planning, implementation, debugging, and coordination tasks throughout the project lifecycle.
I made effort estimates using a combination of structured planning and informal judgment. The primary method was task breakdown, where features and requirements were divided into smaller tasks using GitHub Issues and a project backlog. Each issue represented a discrete unit of work such as implementing a component, fixing a bug, or integrating a feature.
In addition to task breakdown, I relied on gut feeling and intuition, especially when tasks were exploratory or involved debugging. I also compared tasks to past assignments and projects, particularly earlier issues from this same assignment. By reviewing how long similar issues had taken previously, I was able to form rough estimates for new tasks. This historical data helped ground my estimates, even though the exact complexity of tasks often varied.
Although my estimates were often off—sometimes too low and sometimes too high—estimating in advance still provided meaningful benefits.
First, it helped catch scope creep. When new features or changes were suggested, comparing them against initial estimates made it clear when the scope was expanding beyond what was originally planned. Second, estimation supported feature prioritization, allowing the team to focus on high-impact or required features first when time became limited. Third, the process of estimating often revealed when a task was larger than expected, prompting earlier discussions about simplifying solutions or adjusting expectations. Finally, estimates made it easier to adjust deadlines or personal workload expectations, even if the original numbers were imperfect.
Overall, estimating forced deliberate thinking about effort and complexity before starting work, which was valuable regardless of accuracy.
Tracking actual effort was useful primarily as a reflective tool rather than a decision-making one. While it did not directly influence later project decisions, it helped me understand where time was actually being spent. Particularly how much effort went into debugging compared to initial implementation.
Seeing the difference between estimated and actual time highlighted patterns, such as consistently underestimating debugging and integration work. This awareness will be useful for future projects, even though it did not significantly change decisions within this project’s timeline.
I tracked my actual effort using a combination of methods:
Tracking was done per task, which provided moderate granularity. I believe the tracking was moderately accurate. While the timer app helped, I occasionally forgot to start or stop the timer, and some effort had to be reconstructed from memory. As a result, the data is directionally useful but not precise.
If I were to repeat this project, I would change several aspects of my estimation and tracking process. I would break tasks down into smaller, more granular units, especially for complex features that involve multiple steps such as design, implementation, and debugging. I would also provide more frequent updates to estimates and tracked time instead of waiting until tasks were completed. These changes would improve both accuracy and usefulness of the data.
While my effort estimates for Club Oven Lovin’ were imperfect, the process of estimating and tracking effort provided meaningful structure, awareness, and reflection. Estimation helped manage scope and priorities, while tracking revealed patterns in how time was actually spent. Combined with selective and responsible use of AI tools for problem-solving support, this experience highlighted clear improvements I can make in future projects—particularly in task granularity and tracking consistency.
Disclaimer: AI was used to help me write this effort estimation essay.