Effort estimation wasn’t something I had given much structured thought to before ICS 314, but this course made it an intentional part of the development process. Throughout the semester, I learned how effort estimation and tracking can sharpen not only project planning but also personal productivity and time awareness.
Initially, I made effort estimates based mostly on gut feeling. I’d ask myself, “How long would this take on a good day?”—usually ballparking tasks based on previous experiences or how familiar I was with the feature or tool. As we went deeper into the project, I started making more informed estimates by breaking issues down into smaller steps and reflecting on how long similar tasks took in past sprints. I also accounted for external factors—like whether the issue depended on a teammate or if I needed to dive into unfamiliar code. That definitely helped me become more realistic and less optimistic with my estimates.
Even though my estimates were often off (sometimes way off), the process itself was still super helpful. Just thinking about effort in advance made me better at prioritizing. I could set clearer goals for each work session, and it gave the whole team a shared understanding of how complex a task might be. There were a few times when another team member estimated a task at 2 hours and I thought it would be more like 6 — those moments opened up great discussions about our assumptions and approaches. The actual number didn’t matter as much as the conversation it sparked.
Tracking my actual effort also had some real value. It helped me spot where my estimates were drifting from reality and why. Sometimes, I underestimated because I didn’t factor in debugging or learning a new package. Other times, I overestimated because I thought the integration would be messier than it was. Keeping a record helped me identify patterns, like which types of tasks I consistently got wrong. There wasn’t really a downside to tracking — maybe just a little friction at the beginning when I’d forget to log my time. But even then, reflecting and logging it retroactively still gave me useful data.
To track effort, I mostly used GitHub issues and notes. I’d start a timer or write down when I began and ended a task, usually in blocks of focused time. I wasn’t surgically precise, but it was close enough to identify trends. Over time, I got better at staying on top of it, and I think my tracking was decently accurate—definitely enough to see where my workflow could improve.
As for overhead, it honestly wasn’t bad. Logging time took maybe a few seconds here and there, and once it became routine, I didn’t even think about it. In fact, it helped me stay focused—like when you hit “start” on a timer, you’re more likely to stay on task. In the bigger picture, this small habit paid off by giving me a clearer view of how I work and where I can get better.
Overall, effort estimation and tracking gave me more than just numbers—it gave me a structure for planning and reflecting on my work. I definitely see myself applying this practice in future projects, whether software-related or not.