The effort estimation draws on a team project called Rainbow Reclamation, a lost-and-found application, but I took responsibility for estimating and tracking my own work progress. I made my effort estimate by carefully reviewing the requirements for each assigned issue given to me and identifying the specific tasks involved in the issue, such as implementation, planning, debugging, and testing code. When I have a similar functionality in an issue that goes hand in hand with another issue, I would delete the posted issue and recalculate the amount of time both issues would take in that one branch. For tasks involving unfamiliar logic or libraries, I would increase the estimated time to take into account learning how to solve the issue. Breaking larger features into smaller subtasks has helped me better understand the scope of work to help produce a more realistic estimate.
Although my estimates were often inaccurate due to guessing the amount of time needed to complete the task, getting a rough estimate of how much time it would take and needed has helped me understand the benefits throughout the team project. The estimation process has forced me to think critically about what needs to be done first before implementing it into the code, instead of immediately writing code and having no idea of what issues need to be addressed. It improved mt time management skills by helping me decide which issues I could realistically complete within a milestone. The estimation also encouraged me to break down complex features into smaller and more manageable tasks. In several cases throughout the project, estimating effort has helped my team and me to reduce scope creep by keeping us focused on the core functionality of the application, rather than unnecessary refinements. Overall, I think that estimation has brought structure and clarity to my workflow within the team project.
Getting to track actual effort was useful due to revealing the gap between my expectations and the reality of building Rainbow Reclamation. I noticed that tasks involving missing knowledge, unexpected edge cases, or small implementation errors would significantly take longer to complete and fix than expected. This insight helped me understand how to adjust future estimates and make better choices about prioritization in later milestones. Tracking effort also made it easier to communicate progress with my teammates and help identify which part of the application was taking the time to complete. Over time, this process helped me better understand my own strengths and limitations of working under time pressure.
I tracked my coding effort in this project by noting the approximate start and end times of my code sessions, and I often checked the clock before and after working on an issue. In most cases, when precise tracking was difficult, I would record a reasonable estimate of the time spent on completing the issue. Coding effort included time spent implementing features, debugging, and integrating new changes into Rainbow Reclamation, as well as time spent reviewing code and correcting any AI-generated skeleton code.
For non-coding efforts such as planning and team communication, I followed a similar approach by estimating time based on when I started and stopped these activities. For team communication, my team and I used notes to track the time spent collaborating and discussing ideas or issues in the project. All effort tracking details were added in GitHub milestone issues, either in comments or board updates of issue progress. While this method was not precise, I believe it provided an honest and reasonable account of my effort because I recorded the time when I completed issues and avoided taking breaks while working on the issue.
If I were to repeat this process, I would spend more time early on to plan out the requirements before creating estimates. Also, I would break down larger issues into subtasks to complete in future milestones to help reduce uncertainty and improve estimation accuracy. Additionally, I would like to use a consistent method for tracking non-coding and coding effort from the start to the end of the project to help improve data quality. Most importantly, I would focus on identifying knowledge gaps earlier, which could help avoid underestimating the time it would take to complete an issue. I think these changes would help lead to more reliable estimates and smoother project execution in future projects.
In this project, I used AI tools like ChatGPT or Claude to help with understanding requirements and generating example code snippets for the project. The prompts developed during this project included,“Explain how to implement this feature in React” or “Help debug this error message.” Time spent on these prompts for reviewing generated code, debugging, and integrating outputs was counted towards coding effort. The majority of the responses required minimal edits or corrections to the current codebase. These AI tools were also used for non-coding tasks such as learning new concepts or clarifying documentation, which I tracked separately as non-coding effort. While I think AI improved productivity, I think careful verification to accurately track effort remained essential.
Overall, I think effort estimation and tracking played an important role in how I approached the development of Rainbow Reclamation. The process helped me think more critically about task requirements before actual implementation, effective time usage, and understand how my skills and limitations affected the overall time to develop this project. Tracking effort made progress easier to follow and supported better decisions throughout the project. Even when my estimates were inaccurate, the experience I gained provided a valuable insight into future project planning and reinforced the importance of honest effort data.