Throughout this project, effort estimation played an important role in how I planned, prioritized, and evaluated my work. My initial estimates were created by breaking tasks into smaller components and comparing them to similar work I had completed in previous assignments and projects. For example, when estimating the effort required for for the navbar, I referenced a similar task from an earlier project that took approximately 1 hour. Based on the added complexity and uncertainty of this project, I adjusted that estimate upward and included extra buffer time to account for debugging, integration, and unexpected issues.

Although many of my estimates turned out to be inaccurate, estimating in advance still provided meaningful benefits. Creating estimates forced me to think critically about task scope, dependencies, and risk before starting implementation. One clear example was the edit/delete recipes, which I estimated at 2 hours but ultimately required about 5 hours to complete. While the estimate was off, the process helped me identify early on that this task involved unfamiliar tools or edge cases, which allowed me to start earlier and avoid last-minute pressure. Without an initial estimate, these risks may not have been recognized until much later in the project timeline.

Tracking actual effort proved to be especially useful once the project was underway. By logging the real amount of time spent on tasks, I was able to identify patterns in where my estimates consistently fell short. In particular, I noticed that debugging, testing, and integration work took significantly longer than anticipated. For instance, delete/edit recipes debugging consumed more time than the initial development itself. This insight helped me adjust future estimates by explicitly accounting for verification and refinement rather than assuming they would be minimal.

I tracked my actual effort using just using my head and a clock. My process involved recording start and end times for each focused work session and categorizing the effort by task. Overall, I believe my tracking was fairly accurate because I logged time consistently, though it was not perfect due to interruptions, context switching, and occasional delays in stopping timers. Despite these minor inaccuracies, the data was sufficient to reveal trends and inform better estimates.

Reflecting on this experience, there are several changes I would make in future projects. I would break tasks down even further to reduce ambiguity, apply larger buffers to high-risk or unfamiliar work, and revisit estimates mid-project using actual effort data rather than relying solely on initial plans. Treating estimation as an iterative feedback loop—estimate, measure, and recalibrate—would lead to more realistic planning and improved time management.

AI Use: YES. AI tools were used for estimation or tracking, they included Claude 4.5. Approximately 20 minutes were spent on prompt creation, 5 minutes on generation, and about an hour on verification and manual edits. AI-generated responses were used primarily for debugging assistance, while final estimates and decisions were manually reviewed and adjusted to match project constraints and personal judgment.