My First Missed Sprint Because of Untested Groovy Code

Complete code is not the same as shippable code

The setup

So that week I only had 2 working days. The rest was holiday. And the card assigned to me was pretty big one, not impossible for 2 days, but not comfortable either. I thought I could make it work if I just stay focused and not getting distracted.

The implementation itself went fine actually. By 1PM on the last day of sprint, the code was done. Feature working, logic correct, ready to merge. In my head I was thinking “I still have the whole afternoon, plenty of time to wrap everything up.”

I was feeling pretty confident at that point.

Where it went wrong

Then came the unit tests. The code I was modifying had no existing unit test. Zero. And it was written in Groovy, a language I have never worked with before. So now I was trying to write unit tests for previously untested code, in a language I was learning on the spot, under deadline. Not exactly the best situation right?

I spent the next 2 hours fighting with the test setup. Some function was hard to test and I could not tell if that was because of bad testability in the existing code or because I simply did not know Groovy well enough. I was trying different approach, mocking frameworks, but nothing was working cleanly. The clock was ticking and I’m starting to feel the pressure building up.

At 3PM I decided to just merge what I had to the dev branch. But then the CI pipeline took almost 1 hour to finish deploying. It was the last day of sprint, so everyone else was deploying too. The shared pipeline was crawling. I was just sitting there watching the pipeline running and there’s nothing I can do about it.

By the time it was deployed to dev, QA had no time left to test it within their working hours. I did not want to force them to stay late just because I was cutting it close. So I went to my tech lead and asked if it was okay to miss the sprint commitment this week.

“Is it okay if this one carry over to next sprint? I don’t want to push QA to test after hours because of my planning.”

That was basically what I said.

How the team handled it

My tech lead treated it as learning moment, not as something to blame me for. We discussed what went wrong and what could be different next time, and then moved on. No drama. I’m honestly grateful for that because I was expecting worse reaction.

The fact that I chose to not push QA to test after hours, I still think that was the right call. A missed sprint is annoying but recoverable. Burning out your QA team’s trust by making them work late because of your planning failure is not something you can easily fix.

What I learned

The biggest lesson from this: complete code is not the same as shippable code. The implementation being done at 1PM meant nothing if testing, pipeline, and QA review are still ahead. All of those is part of the deliverable. I was wrong to think “code done” means “work done.”

There’s few thing I now keep in my mind after this experience:

When estimating work on legacy codebase with no tests, I should budget extra 30 to 50 percent for writing test from scratch. Especially in unfamiliar language, tinkering around with new language syntax while under deadline is not fun haha.
Pipeline slowness on the last day of sprint is systemic risk, not a surprise. I should plan for it instead of hoping it would be fast.
If the existing code has no tests and the language is unfamiliar, raise the flag early. I was discovering this on the last day and at that point there’s not much I can do about it.
Respecting QA’s working hours is non-negotiable. This one I will not compromise on.

This was my first missed sprint commitment and it was not fun. But honestly I think I learn more from this one failure than from many successful sprint before it.