Issue Driven Project Management Reflection

08 May 2025

I had some background on software development besides this class, so I already knew how long some basic processes could take, so I always overestimated the effort I’d put into each issue. This made it so that my estimations were up in the mid-range 3 digit numbers like 400. The only estimation that I had that I wasn’t very sure of was for AI development as I wasn’t really familiar with that.
My estimates were only off by 2 to 3 hours at most for issues I was already familiar with. A benefit I got from estimation is that I was able to know which tasks to prioritize first. I already somewhat knew which ones I’d do first beforehand, but the efforts helped to give a finer estimate on when I could expect to be done per issue.
It sort of acted as feedback for myself because it shows me whenever I may have procrastinated for a task. I think it also reminded me that I should overestimate effort for big projects.
I used my clock. Whenever I started I wrote down my initial time and whenever I’d take a break or stop working for the day, I kept track of the end time. I determined the number of minutes worked and added that number to Github. I’d track every action done on VSCode, Github, Supabase, or Vercel as coding effort and research, testing, and journaling as non-coding effort. My tracking was pretty accurate because I was very proactive in keeping track of time.
There wasn’t really any overhead when it came to tracking my effort. It was worth whatever minimal cost to track my effort and maintain a healthy pace.