Dog-Sized Tickets: A Better Way to Estimate Work
Story points are abstract and meaningless. Dog breeds are intuitive, visual, and everyone on the team immediately knows what a Chihuahua versus a Great Dane means.
Story points don’t work. Everyone knows this. Your team spends 20 minutes arguing whether a ticket is a 3 or a 5, the Fibonacci sequence somehow becomes a proxy for time even though you swore it wouldn’t, and by the end of sprint planning everyone’s dead inside. A “5-point story” means something different to every person in the room, and six months from now it’ll mean something different again.
The problem isn’t estimation itself. The problem is that the units are meaningless. A number on an arbitrary scale conveys no intuition. You can’t picture a 5. You can’t feel the weight of a 13.
You can picture a dog.
The Scale
Dog-sized estimation replaces abstract numbers with breeds. Everyone has seen these dogs. Everyone has an immediate, visceral sense of how much space they take up, how much energy they require, and how much chaos they can cause. That’s the point.
Here’s the scale, from smallest to largest:
Teacup Yorkie. Zero technical complexity. One file, one change, no unknowns. A copy update. A config flag flip. Changing a button color in a design token. The system boundary doesn’t move, no new logic is introduced, and you don’t need to understand anything beyond the line you’re editing. If a Teacup Yorkie requires a PR review longer than 30 seconds, something is wrong with your review process, not the ticket.
Chihuahua. Low complexity, but with a bite radius that surprises you. The code change is small — maybe a single function or component — but it touches something with implicit contracts. A form validation update where three other components depend on the error shape. A dependency bump that shouldn’t break anything, except the transitive dependency tree has opinions. The technical risk isn’t in the size of the change. It’s in the surface area of what that change touches. Chihuahuas teach junior devs that lines-of-code is a terrible proxy for complexity.
Beagle. Moderate complexity, but fully understood. You know the architecture you’re working in, the patterns are established, and there are no open questions about approach. Adding a new REST endpoint that follows the same controller-service-repository pattern as the last ten. Writing a migration for a new column with a known data type. Building a React component that’s a variation on an existing one. One layer of the stack, maybe two. No new abstractions needed. Beagles are the tickets where experience compounds — the tenth one takes a quarter of the time the first one did.
Labrador. This is where real technical complexity enters the picture. A Lab crosses architectural boundaries. Frontend and backend. API and database. Maybe a queue or a cache layer. You’re not just writing code — you’re making decisions about data flow, error handling across service boundaries, and state management. You’ll touch 4-8 files across 2-3 layers of the stack. The individual pieces aren’t hard, but they have to fit together correctly, and you need to hold the whole interaction model in your head while you work. Labs are the workhorse of the sprint — the standard unit of meaningful engineering.
German Shepherd. High complexity. Multiple services, integration points that require coordination, and at least one technical unknown you’ll need to resolve before you can finish. This is the ticket where you’re adding a new webhook consumer that has to handle idempotency, retry logic, and a failure mode that doesn’t exist in the current system. Or building a feature that requires a new database index and you need to verify it won’t blow up the query planner in production. German Shepherds demand respect because the debugging surface area is wide — when something breaks, the root cause could be in any of three services. You don’t take on more than one at a time.
Great Dane. Architectural complexity. This ticket doesn’t just cross boundaries — it moves them. You’re introducing a new data model, changing how services communicate, or adding a capability the system wasn’t designed to support. A Great Dane might mean a new event-driven workflow where everything was previously synchronous. Or a multi-tenant isolation layer that touches auth, data access, and the API surface simultaneously. The technical risk is high because you’re making decisions that constrain future work, and the blast radius of a mistake extends well beyond the ticket itself. Three to five days, and the whole team knows about it because the architecture review alone takes an afternoon.
Saint Bernard. If you see one of these in your backlog, it’s not a ticket — it’s a technical program. The complexity isn’t just high, it’s unknown. A Saint Bernard is “rebuild the auth system” or “migrate from REST to GraphQL” or “move the monolith to event sourcing.” There are multiple architectural decisions that haven’t been made yet, cross-team dependencies that haven’t been mapped, and failure modes that won’t be discovered until you’re three weeks in. The correct response to a Saint Bernard is to decompose it into Beagles and Labs — and to accept that the decomposition itself is a German Shepherd. You do not put a Saint Bernard in a sprint. You put a leash on it and walk it to the roadmap.
Complexity Is the Breed, Not the Weight
The key insight is that the breed isn’t just a proxy for time. It’s a proxy for technical complexity — and those are different things.
A ticket could take two days because the work is straightforward but voluminous — lots of Beagle-level changes across many files. That’s still a Beagle, you just have several of them. A ticket could take two hours but require you to understand the interaction between three microservices and a race condition in the message queue. That’s a German Shepherd in a Chihuahua’s time estimate.
Story points collapse these dimensions into a single number. Dog breeds keep them separate because the breed carries character, not just magnitude. When someone says “German Shepherd,” the team hears coordination, integration risk, and unknowns. When someone says “Beagle,” the team hears known patterns and predictable scope. The breed name encodes the type of work, not just the amount.
This matters most when things go wrong. A Beagle that takes longer than expected is a scheduling miss — you just underestimated the volume. A Chihuahua that turns into a German Shepherd is a complexity miss — you didn’t see the hidden dependencies. Those are fundamentally different retrospective conversations, and the dog metaphor forces you to have the right one.
Why This Works
Three things make dog-sizing better than points.
Shared mental model. When someone says “this is a Lab,” everyone in the room pictures the same thing. Not just the size — the character. Labs are friendly and familiar. That’s a ticket in known territory with a clear path. When someone says “this is a Chihuahua,” everyone knows it’s small but irritable. That’s information a “2” doesn’t carry.
Natural resistance to false precision. Story points invite negotiation. “Is it a 5 or an 8?” There’s no meaningful difference, but teams burn time debating it. Nobody argues about whether a ticket is a Beagle or a slightly-larger Beagle. The breeds are discrete enough to be useful and coarse enough to prevent pointless haggling.
Immediate red flags. When a Great Dane shows up in sprint planning, the metaphor does the work for you. “That’s too big for one sprint” is a conversation everyone has had. “That’s too many points” is a conversation that devolves into math. The visual metaphor triggers the right instinct: break it down, or give it dedicated focus.
In Practice
Run sprint planning the way you normally would, but replace the pointing with breeds. The ticket comes up, someone reads the acceptance criteria, and instead of holding up a card with a number, everyone says a breed.
If three people say Lab and one person says Great Dane, you have a useful conversation. The person who said Great Dane knows something the others don’t — maybe a hidden dependency, maybe they got burned by that module last quarter. That’s the conversation you actually want to have. Points obscure it. Dogs surface it.
Track velocity in dogs if you want. Count Labs per sprint. It’ll be just as accurate as story points, which is to say: rough, directional, and fine. The dirty secret of velocity tracking is that the unit doesn’t matter. Consistency of the unit matters. Dogs are as consistent as Fibonacci numbers, which aren’t consistent at all, which is the whole point.
The Leaderboard Nobody Asked For
If your team is competitive — and every team is, whether they admit it or not — dog-sizing gives you a natural language for sprint recaps.
“We shipped two Great Danes and a litter of Beagles this sprint.”
“Jenkins was down for a day, so we only got through the Chihuahuas.”
“That thing we thought was a Lab turned out to be a Saint Bernard in a Lab costume.”
That last one is the most important sentence in estimation. Every team has tickets that reveal hidden complexity mid-sprint. Points give you “the estimate was wrong.” Dogs give you “it was wearing a disguise.” One of those is a blame statement. The other is a story the team will remember and learn from.
Adopt, Don’t Shop
You don’t need to buy a tool for this. You don’t need a Jira plugin. You don’t need a consultant to certify your team in Canine Agile. Put a dog breed in the ticket title or a custom field. Agree on the scale in your team wiki. Start using it next sprint.
The whole point of estimation is to create a shared understanding of the size and shape of upcoming work. Story points tried to do this with abstraction. Dog breeds do it with something everyone already understands — the difference between carrying a Chihuahua and walking a Great Dane.
One fits in your bag. The other walks you.