Ship something every sprint - not for the team, for yourself.

Some sprints I ship nothing meaningful.

I do my work. I close my tickets. The board looks clean. But when the sprint ends, I have this hollow feeling, like I moved cards across a board but didn’t move anyone’s life forward.

It bothers me more than it should.

This last sprint was different. I remembered a wish from our customers, something small, something nobody had planned. Drag and drop. A feature that would save them minutes of tedious work every single day.

So I built it. Not instead of the sprint goal, on top of it. And when I finished, I felt something that had been missing for a while.

I felt like I actually mattered.

Two Sprints, Two Feelings

Here’s what I’ve learned after years of sprints: the difference between a good sprint and a forgettable one is rarely about how much code you wrote.

It’s about whether you can point at something and say: this made someone’s work easier today.

That sounds obvious. It’s not. Because most of us, especially senior devs, spend entire sprints buried in infrastructure, refactoring, internal tooling, migration scripts. Important work. Necessary work. But work where the human at the end of the chain is invisible.

And when the human is invisible, the meaning disappears with them.

Code Was Everything, Until It Wasn’t

Earlier in my career, I measured myself by code. Clean abstractions. Elegant solutions. Clever patterns.

That mattered to me. It still does.

But somewhere along the way, I started asking a different question. Not “is this code good?” but “will someone’s Tuesday be easier because of what I shipped?”

That shift changed everything. Not what I build, but why it feels worth building.

The Sprint Goal Comes First. Always. I need to be honest about the tension here.

You can’t ignore the sprint goal. You committed to it. Your team depends on it. Going rogue because you had a “better idea” is not what I’m describing.

The sprint goal comes first. Always.

But here’s what I’ve noticed: most sprints, if you’re focused and intentional, there is space. Not a lot. Maybe a few hours. And the question is, what do you do with that space?

Do you gold-plate something that’s already done? Do you start scrolling? Or do you ask yourself: what’s one small thing I could ship that would make someone’s day?

I don’t always find that space. Some sprints are packed. That’s real. But when I do find it and waste it, I feel it at the end.

The Visualization Test

Here’s what I’d challenge you to try in your next sprint.

Before the sprint starts, close your eyes. Visualize the end of the sprint. Imagine you’re showing your work to the people who use it. What are you showing them?

If you feel excitement, genuine excitement, not obligation, you’re on the right track. Your sprint goal is already user-centric. Run with it.

But if you feel nothing, if the demo in your head is just “we refactored the service layer,” ask yourself one more question: what’s one low-hanging fruit, aligned with the sprint goal, that would make people care?

Not a side project. Not scope creep. One small thing that connects your work to the human on the other side.

Why I Do This

I know my customers. I know how hard they work. I know that sometimes their tools make a hard job harder, and they don’t complain about it, they just push through.

I think about that. Probably more than I should.

And when I can ship something, even something small, even drag and drop, that takes one frustration off their plate, it reminds me why I became a developer in the first place.

Not to write code. To make someone’s work a little more human.

That feeling doesn’t come from closing tickets. It comes from knowing that someone, somewhere, had a slightly better day because of what you shipped.

Ship something every sprint. Not for the team. For them.