Recently I was in charge of a feature for the first time - that is scoping, estimating and breaking it down. It didn't go great. I estimated 2.5 sprints, but the work took 5 sprints, including some weekend work. To avoid this happening again to future me, here are a few observations about what went wrong:

Work estimates are not deadlines

When the feature was officially marked as 'behind' I was quite surprised. I had only spent 1 sprint on the feature, with the next sprint handling incidents, onboarding and such. My assumption was that since nobody was working on the feature, it wouldn't count as time spent on the feature. But this was wrong. To management, the number I gave was a deadline, not a work estimate, even if they used those terms interchangeably. So next time, clarify what your number is for and if it's a deadline, increase your estimate to account for the time the task stays on the sprint board, not just the time spent working on the feature.

Account for feedback loops

Even though the individual code changes for PRs were small, they took a long time. This was due to the length of the feedback loops. Tests took 10 minutes to run after each code change (and got longer as more tests were added) and PRs could take 2-3 days before they were approved. Not only had I not considered these factors, but they were absolutely fatal to my productivity,

• Waiting 10 minutes between code changes immediately destroys any possibility of a flow state. I would often find myself watching a YouTube video whilst waiting and completely lose my train of thought
• Working on multiple PRs on top of each other, due to their slow approvals causes a lot of pain. One comment can have a change that echoes among all these PRs, causing a lot of duplicated work. Worse, the tests have to pass again, causing a double whammy of long feedback loops.

So next time, figure out not just the size of the code changes, but the time it takes to iterate on those code changes, or in other words - Don't underestimate the time spent waiting.

That about sums up the main issues with my estimations for this project. My main takeaway is underestimating the size of the work, mostly from not accounting for the time spent not coding. I guess there's a good reason that the rule of thumb that goes (your genuine estimate) * 2. Next time, I'd also like to consider uncertainty over time and providing ranges, and see if that leads to a better outcome.