Before working on the Run-and-Route Hub project, I didn’t think much about effort estimation. I usually just worked on tasks until they were done. But throughout the milestones, I learned that estimating and tracking effort is actually an important part of managing a project. It helps with planning, reduces stress, and gives a better idea of how long different kinds of work really take. This essay explains how I approached estimation, what I learned, and what I would change for next time.
I made my estimates by breaking each issue into smaller tasks and comparing them to similar work from earlier milestones. UI tasks were easier to estimate because they reused patterns I already understood from previous React work. Backend tasks, especially anything involving Prisma or the database, were harder to predict, so I estimated more conservatively.
Separating coding effort from non-coding effort also helped. Thinking about planning, documentation, and debugging as their own time investments made my estimates more realistic.
Even when my estimates weren’t perfect, the process still helped. Estimating forced me to think ahead about what a feature needed and what steps were involved. Some tasks that looked simple on the surface ended up requiring more planning or refactoring.
Estimating also helped with prioritization. Tasks with higher estimated effort were started earlier, which prevented last-minute stress. Overall, estimation added structure to my workflow, even when the actual time didn’t match the estimate exactly.
Tracking actual effort showed me where my time was really going. I realized that a lot of work happened outside of writing code—reading documentation, debugging odd errors, and discussing changes with teammates. Non-coding work ended up being a much bigger portion of the project than I expected.
Comparing estimated effort with actual effort helped me get better at predicting backend tasks and database work.
I tracked my effort manually by noting when I started and stopped working on an issue. Coding effort included writing, testing, and debugging code. Non-coding effort included planning features, documenting decisions, discussing tasks with teammates, and reading documentation.
This method wasn’t perfectly precise, but it was consistent enough for me to see patterns and understand where my time was going.
For future projects, I would break issues into smaller and more specific tasks before estimating. Some issues took longer because they contained multiple hidden steps. I would also give myself more buffer time for anything involving databases or authentication because those tasks often introduced unexpected complexity.
To improve accuracy, I might use a lightweight timing tool instead of manual tracking.
I used AI tools like ChatGPT to help brainstorm ideas, understand errors, and generate initial drafts for certain features. When AI contributed to a piece of code, I counted that as coding effort because it still required reviewing, testing, debugging, and adjusting the output to fit the project.
Time spent prompting, reading responses, and integrating the code was also included in my effort tracking.
Estimating and tracking effort helped me understand how I work on software projects. Even though my estimates were not always accurate, the process encouraged better planning and reflection. Tracking actual effort showed me how important non-coding tasks are, and I would continue using a similar approach in future projects to stay organized and reduce stress.