Effort and Tracking

10 May 2025

Effort Estimation Reflection Essay

Effort estimation played a crucial role in planning and executing the tasks throughout our project milestones. This spreadsheet data reveals how team members tracked their coding and non-coding efforts using a variety of methods, including VSCode extensions, Wakatime, Stopwatch, and Code Time. While the approaches varied, most relied on educated estimates to assess both coding and non-coding workloads.

Coding Effort

Across all three milestones, coding time tracking was relatively consistent. Many team members used automated tools such as Wakatime and VSCode timer extensions, providing reliable timestamps for their programming sessions. For example, Elias Thompson and Gordon Sheen used these tools extensively, showing consistent hours logged, with Gordon accumulating over 6 hours on multiple issues using the VSCode timer extension. Shaylon Mizukami and Ethan Ibanez often relied on stopwatch tracking or educated estimates, which although practical, may have introduced slight inaccuracies compared to automated tools.

In terms of time spent, most tasks averaged between 1.5 to 6 hours, with some exceptions extending beyond that. Milestone 3 featured the highest coding duration logged, with Yong recording 8 hours and 37 minutes on Issue #20 and Gordon recording nearly 7 hours on Issue #36.

Non-Coding Effort

Non-coding effort was harder to quantify and was mostly tracked through educated estimates or simply not tracked at all (noted as “0”). A few team members, such as Shaylon Mizukami and Gordon Sheen, tried to distinguish time spent in planning, debugging, or reviewing using “Time Worked – Code Time” or stopwatch methods. Despite this, non-coding contributions were underrepresented, often logged as 0 or less than 1 hour, even for tasks that presumably required communication or documentation.

Accuracy of Estimations

The estimated hours were typically close to the actual time logged via tools, especially for coding tasks. However, discrepancies appeared when both coding and non-coding time were added together. This is likely due to the subjective nature of estimating non-coding tasks, which often involved switching contexts or multitasking—factors not easily captured with simple time-tracking tools.

Lessons Learned

From this experience, several insights emerged:

Automated tools yield better accuracy: Wakatime and VSCode extensions provided a more consistent and objective measure of coding effort.
Non-coding work needs better tracking: Future efforts should include clearer definitions and methods (e.g., dedicated planning or meeting timers) to capture non-coding tasks.
Estimation improves over time: As the project progressed from Milestone 1 to Milestone 3, team members appeared to better align estimated and actual effort, indicating an improvement in planning and self-assessment.
Documentation is valuable: Recording not just time but also the method of tracking gave more transparency to the estimates and helped in comparing across tasks and team members.

Conclusion

Effort estimation is as much a reflective skill as it is a planning one. Our experience shows that while coding tasks can be reliably tracked with tools, non-coding work requires better systems to ensure fair workload evaluation. Going forward, we will aim to incorporate more structured tracking for all types of effort, helping us to plan better and collaborate more efficiently.

Acknowledgement: Chatgpt and other online sources were utilized to provide information and insight, to improve grammar, vocabulary, and punctuation.