Putting in Effort in Estimation
08 May 2025Making Effort Estimates
To create my effort estimates, I used the practice WODs as a basis of estimating how much time it would take me to complete a certain task. More specifically, I used the times I got on the WODs to properly assess these estimates. For example, in the second milestone, we converted the mockups we made (that were originally in HTML/CSS) into React-Bootstrap. To make my estimate for this task, I based it around our WODs (like Island-Snow) that involved converting HTML/CSS to React-Bootstrap. For tasks we didn’t really cover through the WODs, my general rule of thumb was to make the estimate around 60 minutes. My thought process behind this was if I didn’t know how to do something, it would probably take me around an hour or more to do. An example of this is in our recent milestone where I linked companies mapped in the browsing page to their respective profiles. A lot of the intuition behind completing this task involved the way ID’s worked in relational databases, which I didn’t really have much experience with. Hence, I estimated it to be sixty minutes. Overall, that is how I estimated my effort.
Is it actually useful?
Despite these estimations not being accurate, I believe that there is a benefit around making these estimations in advance. The primary reason being it sets a standard or expectation on how long a task may take, which contributes to overall coordination within the team. For instance, a certain issue/task may depend on another task. So having these estimates could give others working on the dependencies of a particular task a heads up on how long it would take before they can start working on said dependencies. Moreover, it kind of gives a time-frame or deadline for implementors to work around and improves efficiency with working on the task.
This leads to another question of whether tracking the actual effort was beneficial. In my opinion, it’s definitely useful especially in the context of reflections. Knowing how long you took to implement something based around an estimate can definitely help with how proficient you are as a software developer. Seeing tasks that you took long on could encourage you to practice or do more research on how to efficiently implement something similar in the future. On the other hand, seeing tasks you took little time on really tells you what skills you excel or are proficient at.
Implementing Tracking
To track my actual effort, I just looked at the clock when I started a task and looked at it again when I finished. Because I did not do this separately for coding and non-coding effort (for instance, if I was in the middle of programming but searched something up for help which is non-coding effort), they were combined. So, I solely relied on estimates or intuition in separating the coding and non-coding effort for a task. As a result, while the total time was accurate, the distinction between coding and non-coding time were inaccurate.
In terms of overhead with tracking effort, I believe that it was minimal and didn’t really affect my working time. Since I took such an easy approach of just looking at the time when I started and when I finished, it was simple. Though there definitely was overhead with distinguishing between coding and non-coding because I had to estimate those. Moreover, sometimes I would not track timing at all due to being so focused on the task at hand that I would disregard it so I would sometimes estimate total time on top of the distinguishing. Overall, tracking time was helpful due to the fact that it helps with staying within deadlines for tasks and the overall project.