Ways to Follow Through with Effort Tracking
10 May 2024
Project effort estimation tracking is an essential process in all project oriented spaces. Under the context of programming projects I found it incredibly helpful to maximize everyone’s productivity and longevity. In the case of our project Manoa Mentoring this meant recording estimations of how long a given issue would take to complete, the amount of coding hours actually utilized to complete it and the amount of non-coding (thinking) hours to complete it. For us it was a roadmap that we followed for time allocation, skillset matching, and scheduling. It proved to be a crucial tool in our development process and overtime we started learning realistic deadlines, ways to anticipate challenges, and assign ourselves where we fit best.
Our efforts were recorded with Githubs issues tool. In which we would meet up either online or in-person and discuss any issues we’d like to add to the project before starting the actual development. Github has a very neat table UI that we utilized often. It featured parameters for the name of the issue, the assignee(s), estimator for expected time, actual coding time, and actual non-coding time. Typically we’d allow oursleves to do our own estimations for our assigned issues. Aside from that we utilized this table 3 times throughout the duration of our development over 3 project titles. Essentially it’s just our development stages broken up into 3 sections.
For me my estimations were made based on whatever the closest experience I’ve had to the issue was. For example I had an issue assigned related to tweaking some of the fields of the account sign up page. I felt confident because it’s a very similar task to one I completed in class. So I gave a relatively short estimation. While that specific instance turned out fine, I have learned that it is better to estimate more time needed than less. That’s a trend I started to uphold further down the development phase we got.
Generating effort estimates in advance can be a huge gamechanger for pacing yourself and your team. For Manoa Mentoring, the guidelines were pretty adoment about each member assigning themselves at least 2 issues. To contest that I’d say that it is nearly impossible for 2 issues to be identical in difficulty and required time to complete. Estimating effort provides a basis to the team of how much time is needed for that issue to be completed, and if that issue requires more than one person. For example during a brainstorming phase with your team, you guys create an issue and assign it to one person. Unfortunately that issue is way more than one person can handle and now a bunch of time and resources has been wasted because one person was attempting to do the job of two. With effort estimation you could at least predict to assign that job to two people or separate it into smaller jobs.
It was beneficial coming from a novice programmer to actually see how much time went into specific issues. It was very humbling to realize that a lot of our estimations were off drastically and that the actual time required to complete our tasks was typically longer than we expected. Being able to actually see that correlation allowed me to start making more accurate estimations. From this I could properly pace my development and schedule.
For keeping track of coding time I simply used a stopwatch app during the duration of my coding sessions. If broken up into more than one session then I logged that time in another document and generated a total once my issue was completed. Non-coding time was done similarly but was challenging to determine what fell into that. I utilized a stop watch again when doing planning and researched and more often then not led to totalling my times since non-coding usually took more than one session. I’d like to believe that my tracking was overall accurate but I do worry about the non-coding tracking because it was sometimes hard to decide what constituted as non-coding project work. Regardless, I tried my best to diligently track it.