When I first started estimating effort for software tasks, it felt like pure guesswork. Picking a number of hours for an issue seemed arbitrary, and I assumed the estimate would be wrong anyway. Through the Issue-Driven Project Management (IDPM) experience in ICS 314, my perspective on effort estimation and tracking changed significantly. While my estimates were often inaccurate, the process itself became one of the most valuable tools I used to manage my work throughout the project.
My effort estimates were based on task similarity, prior experience, and perceived complexity. When creating an issue, I considered whether the work involved frontend UI, backend logic, database changes, authentication, or integration across components. These categories consistently required different levels of effort, and recognizing that helped shape my estimates.
I frequently referenced previously completed issues. For example, if a similar feature or page had taken about two hours, I used that as a baseline and adjusted the estimate depending on additional requirements such as validation logic, styling, or unfamiliar libraries. Rather than aiming for accuracy, I focused on making honest estimates grounded in my understanding at the time the issue was created.
Even though many of my estimates were wrong, estimating effort in advance provided clear benefits. Most importantly, it forced me to think through the full scope of an issue before starting implementation. This often revealed hidden work such as testing, debugging, or refactoring that I might not have otherwise considered.
Several issues initially appeared to be simple changes but expanded once implementation began. While my original estimates underestimated the final effort, the estimation process itself helped me plan milestones more realistically and avoid overloading a single sprint with large tasks.
Tracking actual effort turned out to be more valuable than estimating. By recording how much time I actually spent on each issue, I started to see patterns in my development process. Tasks involving authentication, debugging, or data validation consistently took longer than expected, while straightforward layout or styling tasks were closer to my original estimates.
This information directly influenced project decisions. When actual effort exceeded expectations in certain areas, I adjusted priorities and deferred lower-impact features to later milestones. Effort tracking helped ensure that core functionality was completed on time.
Coding effort was primarily tracked using WakaTime integrated with VSCode. This captured time spent actively writing code, debugging, refactoring, and integrating features into the codebase. I made sure this data reflected active development time and did not include breaks or unrelated activity.
Non-coding effort was tracked manually using issue comments and personal notes. This included time spent on requirements analysis, design planning, researching documentation, writing documentation, and coordinating with teammates. While manual tracking is less precise than automated tools, it provided a reasonable and honest accounting of non-coding effort.
If I were to repeat this process, I would break issues into smaller, more granular tasks earlier in the project. Smaller issues are easier to estimate and track accurately. I would also begin tracking non-coding effort more consistently from the start rather than reconstructing some of it later.
Additionally, I would make greater use of historical averages when estimating new issues, such as maintaining a running average for UI tasks versus backend or integration work. This would likely improve future estimates.
AI tools were used as part of my development workflow and were explicitly accounted for during effort tracking.
Tool: ChatGPT (OpenAI, web interface)
AI assistance was used for generating example code patterns, clarifying framework behavior, debugging errors, and drafting technical explanations. Time spent prompt engineering, reviewing outputs, debugging AI-generated code, and integrating it into the project was counted as coding effort when the output resulted in code.
When AI was used for non-coding tasks such as design discussion, documentation drafting, or conceptual clarification, that time was recorded as non-coding effort. AI-generated outputs were rarely accepted as-is and typically required manual edits or refactoring to meet project requirements and coding standards.
Overall, effort estimation and tracking transformed how I approached project management. While my estimates were frequently inaccurate, the combination of upfront estimation and honest tracking improved my awareness of task scope, informed better planning decisions, and highlighted areas for improvement. This experience demonstrated that effort estimation is less about being correct and more about building insight, accountability, and better decision-making over time.