Stories, tasks, and iterations in practice. What am I actually looking at?

[Rob Whittaker]

I've been reading Extreme Programming Installed this month. The book describes a clear hierarchy:

• Stories are what the customer wants
• Tasks are how developers deliver them
• Iterations bundle tasks into short cycles
• Releases ship value

In practice, our cards may not match any of those.

We use Trello with one-week iterations. Our cards are granular. One per branch in a Rails controller action. A card for the success path, a card for the failure path. Most cards take 2-3 days to complete.

By the book's definitions, these feel like tasks. But we don't have anything above them. No parent story says, "As a user, I can do X." A customer request lands in a backlog. We discuss it in planning. Cards appear on the board. Time pressure means we skip the breakdown the book describes.

So my questions:

1. In the book, stories get broken into tasks during iteration planning. If our cards are already at the task level, what are we missing by not having the story layer above them?
2. A 2-3 day card in a 1-week iteration means we complete 2-3 cards per person per week. Is that a sign the cards are too big for tasks, or too small for stories?
3. How has this hierarchy changed in 25 years? The book assumes rare releases and a formal planning game. We deploy on every merge and plan as we go. Does the story/task distinction still matter, or has it collapsed?