Last weekend I took my son to an indoor climbing gym for the first time. He's small, the wall is enormous, and the whole thing was his idea right up until we got there.

He got his harness on. He got his shoes on. He walked up to the wall, put one hand on a hold, looked up at the ceiling twenty feet above him, and froze.

"It's too high."

I asked him if he wanted to come down. He didn't want to come down. He also didn't want to go up. He just stood there with his hand on the wall, staring at the top, which from his angle probably looked like it was somewhere in the next postcode.

Then I noticed something about the wall. Every few holds, there was a letter bolted into the plastic. A, B, C, D, all the way up in some order I couldn't quite figure out. He'd been learning his letters, so I crouched down next to him and asked, "Can you see the letter W from here?"

He scanned the wall. "Yeah."

"How about this. Forget the top. Let's just climb to the W. Think you can do that?"

He looked at the W. It was maybe four holds up. Nothing, really. He thought about it for a second, and then he started climbing.

When he got to the W he looked down at me, a little surprised at himself. I pointed at an L a few holds higher. He went for it. When he reached the L, he paused again, then picked the next letter on his own. Then another. The letters stopped being a plan and started being a rhythm: reach, check in, pick the next one, reach again.

He made it to the top.

What I noticed, watching him, is that the letters weren't just goals. They were checkpoints. Every time he tagged one, he learned something: which holds felt good, which moves worked for his size, when to trust his feet. By the time he was halfway up, he was climbing better than he was at the bottom, because he'd had a dozen tiny chances to find out what worked.

The wall is too high

I think about this story a lot when I'm looking at a Jira board.

There's a particular kind of ticket I've learned to be scared of. It's the one with a title like "Migrate authentication service" or "Rebuild the reporting pipeline." The body is three paragraphs long. The acceptance criteria has seven bullet points. The estimate is, vaguely, "a couple of sprints."

What happens to these tickets is predictable. They get picked up. Someone works on them for a week. Then another week. The standups start to sound the same: "still working on the migration." Nobody really knows how far along it is, including the person doing the work. The ticket sits in "In Progress" like it lives there. Because, functionally, it does.

This is the climbing wall from my son's point of view. The goal is real, but it's so far away that looking at it doesn't give you information about what to do next. It gives you dread. And worse, there's no signal along the way. No moment where the world tells you whether what you're doing is actually working.

The letter W

The fix on the wall wasn't a motivational speech. It wasn't telling him the top wasn't really that high, or that he was brave, or any of that. It was picking a closer thing to aim at.

Tickets are the same. When I talk about "small tickets," I'm not really talking about size for its own sake. I'm talking about the distance from where you are to the next moment where you get to say "done." And, more importantly, the next moment where reality gets to tell you whether you were right.

My rough rule is that a ticket should be something you can finish in about 48 hours. Not because there's anything magic about two days, but because that's roughly the horizon where:

• You can hold the whole thing in your head at once.
• You can tell at any moment whether you're on track or stuck.
• If you are stuck, you haven't been stuck for so long that asking for help feels like an admission.
• The review that comes after is small enough that someone will actually read it.
• You get a real piece of feedback within days instead of weeks, whether from a test, a teammate, a user, or production.

If a ticket can't fit in that window, it isn't a ticket yet. It's a goal. And goals need to be broken down into the next letter up the wall before anyone starts climbing.

The feedback loop is the point

Here's the thing I didn't understand about small tickets for a long time: the size isn't really the point. The feedback loop is the point. The size is just how you make the feedback loop short.

Every small ticket you finish is a checkpoint. You merge it, you deploy it, you show it to someone, you run it against real data, and you find out something you didn't know before. Maybe the approach works and you keep going. Maybe it doesn't and you pivot. Maybe the requirement turns out to be wrong and the whole branch gets pruned. All of that is information you couldn't get by thinking harder. You could only get it by shipping.

Big tickets hide this feedback from you. You build for two weeks on a plan you made on day one, and by the time anyone sees it, you've baked in assumptions nobody can cheaply challenge. Small tickets surface the feedback early, when it's still cheap to act on. You learn what works before you've committed to it at scale.

The difference shows up in how wrong you're allowed to be. On a two-day ticket, being wrong costs two days. On a two-month ticket, being wrong costs two months, and people avoid admitting it for exactly that reason.

What you get when tickets are small

Momentum. Shipping something, even something small, feels different from not shipping. My son wasn't brave because he reached the top. He reached the top because hitting the W made him feel, for a second, like someone who climbs walls. The L was easier to commit to than the W had been.

Fast feedback. Every finished ticket is a question answered. Is this the right abstraction? Does the API behave the way I thought? Is the user going to use this at all? You can't answer those by thinking; you can only answer them by shipping something small and watching.

Honest status. "I finished three tickets this week" is a real sentence. "I'm 60% done with the migration" is a wish. Small tickets turn progress into something you can count instead of something you have to estimate.

Cheap course correction. When the work is small, changing direction is cheap. You finish the thing, you learn something, and you pick the next thing based on what you just learned. When the work is big, you commit to an entire plan up front, and by the time you find out it was wrong, you've already built half of it.

Reviewable pull requests. A small ticket tends to produce a small PR. A small PR tends to get read. A read PR tends to get useful feedback. A big PR tends to get a thumbs up from someone who scrolled to the bottom.

Less fear. This is the part the climbing wall taught me. A big ticket isn't just hard to finish; it's hard to start. You sit down, you look at it, and the size of it makes you go get a coffee instead. A small ticket is something you can just begin.

How to find the W

When I'm staring at a ticket that feels too big, I ask myself: what's the smallest thing I could ship that would teach me something, or move someone else's work forward, or remove one specific risk?

Not the smallest thing that "makes sense as a deliverable." Not a milestone. The smallest thing that is useful on its own, can be finished by Thursday, and will give me a piece of feedback I don't already have.

Sometimes that's a spike. Sometimes that's wiring up one endpoint behind a feature flag. Sometimes it's just deleting something that shouldn't be there anymore. The point is that when it's done, it's done: merged, closed, off the board. And the next thing is a fresh decision, informed by what you just learned.

My son didn't climb the wall. He climbed to W, then to L, then to the next letter, and the one after that, and eventually he ran out of wall. The top was never the plan. The top was what happened when he kept picking the next letter and learning as he went.

Do that with your tickets. Pick the W. Climb to it. See what you learned. Then look up and pick the next one.