To make our effort estimates, I looked back at previous WODs that we did throughout the semester. These involved similar tasks like creating or refactoring websites using HTML, Bootstrap, React, and Next.js, so they gave me a good frame of reference for how long certain parts of the project might take. I used those experiences to gauge how long it would take to complete new issues that were similar in scope-for example, implementing a landing page layout or adding a form component. I also considered the complexity of the task, who was assigned to it, and how comfortable we were with the tools involved.
Even when our estimates turned out to be off, sometimes way off, there were definitely benefits to making them ahead of time. Estimating the effort gave us a clearer roadmap of what to expect and helped us break down the project into manageable chunks. It also encouraged us to think critically about each issue before starting, which helped with planning and prioritizing as a team. Since we’re a 5-person group working on a website, it was especially helpful for coordinating who should tackle what and when, so that no one was overloaded or blocked by someone else’s unfinished task. Even when we got the time estimates wrong, just having them in place helped us stay organized and accountable.
Tracking the actual effort spent on each issue was useful, especially for reflection. It helped us compare our expectations with reality and understand where we tend to underestimate or overestimate our time. For me personally, it was a good way to “lock in” mentally and focus once I had a timer running. That said, there were some downsides too. Knowing that our effort was being tracked added a little bit of pressure, and at times that stress made it harder to focus or made the work feel more high-stakes than it needed to be. Still, the benefits of staying on task and being more conscious of how I spend time outweighed the downsides overall.
For coding-related tasks, I used the WakaTime extension in VSCode. It automatically logs how much time is spent in each file, which made it easy to track my actual coding time without any manual effort. For non-coding work: like team planning, debugging discussions, and writing documentation, I used a stopwatch to log the time manually. I’d say the tracking was pretty accurate, especially for coding since it was automated. Manual tracking wasn’t perfect, but as long as I remembered to start and stop the timer, it gave a decent approximation of the time I spent outside the editor.
The overhead for tracking effort was minimal. WakaTime handled most of the heavy lifting for coding, and manually tracking non-coding time didn’t take more than a few seconds to start or stop a timer. It didn’t feel like it got in the way of working on the project, and after a while it became second nature. In fact, having effort tracking in place through IDPM made it easier to stay focused and aware of how long tasks were taking, which helped us stay on track and meet our deadlines more reliably.