In the world of software development, time is both your most valuable resource and your biggest enemy. You think you can knock out a feature in an hour, only to find yourself debugging at 3 AM. That’s where effort estimation comes in—not as a crystal ball, but as a planning tool that helps you manage your project without burning out.
For my ICS 314 final project, Tithr, I dove into issue-driven project management (IDPM) effort estimation. It wasn’t about predicting the future perfectly; it was about creating a framework to track progress, adjust plans, and learn from mistakes. Here’s how that unfolded.
Before writing a single line of code, I set up my GitHub project board with custom fields: Estimated Effort (hours), Estimator, Coding Effort (hours), and Non-Coding Effort (hours). Each issue got an initial estimate based on my best guess. For example, “Set up user authentication” might get 4 hours because I’d done similar work before and knew it involved research, implementation, and testing.
I used a simple stopwatch—first a Google tab timer, then switched to my phone’s app after a few crashes. It tracked coding time precisely, and for non-coding tasks like requirement analysis or documentation, I’d note start and stop times in issue comments.
Even when my estimates were way off (and they often were), the act of estimating provided real value. It forced me to think through the task: “What steps are involved? How long did similar issues take?” This mental exercise helped me clear my schedule. If I estimated 3 hours for a feature, I’d block out that time, knowing I’d usually have more than enough buffer.
For instance, I underestimated “Implement budget categories” by about 50%. It took 6 hours instead of 4, but because I’d planned for it, I didn’t scramble at the last minute. The estimate gave me a baseline to measure against and adjust my workflow.
Tracking actual effort was incredibly useful. It turned vague feelings of “this is taking forever” into concrete data. After each session, I’d update the GitHub fields with real numbers. Coding effort came from the stopwatch, while non-coding (like researching Bible APIs or designing the UI) was logged manually.
This data informed future estimates. If “Add transaction logging” took 2 hours of coding and 1 hour of research, I’d use that as a reference for similar issues. It also highlighted bottlenecks—turns out, I spent more time on UI tweaks than I thought, so I adjusted my planning to allocate more time for design.
The tracking was very accurate because the stopwatch ran continuously during focused work. No “best guesses” here; it was all logged in real-time.
Next time, I’d stick with my phone’s stopwatch app. The Google tab was convenient but fragile—PC crashes or WiFi drops killed it, forcing me to restart and lose precision. Maybe I’d explore dedicated tools like Toggl for better integration.
Overall, effort estimation transformed my project management. It wasn’t about perfection; it was about awareness. By tracking honestly, I learned to plan better, avoid overcommitment, and celebrate small wins. Tithr shipped on time because I had a clear picture of my effort, not just my code.
In software, as in life, you can’t control time—but you can measure it, learn from it, and use it wisely.
Small print on AI usage: I did not use AI tools for effort estimation or tracking. All planning, estimation, and reflection were done manually.