We tackle our work in the way that seems right to us. We look ahead at the work on our plate and do our best to get it done. I often say that everyone makes great choices... given their own context and point of view. Unfortunately, that point of view sometimes leads us to a local optimization, where things look efficient until we step back and take a look at the bigger picture. Then we realize our local optimization wasn't nearly as efficient as we thought.
This often takes shape in how we break out our team's work. Some times we break everything down into layers (horizontal slicing) while others slice the work into smaller, but working, bits of functionality (vertical slicing).

Horizontal feels more efficient because it lets different product area specialists (like SQL or UI gurus or server-side code jockeys) work quickly and knock out a lot of stories. It lets your specialists work alone, and doesn't force them to engage with the other team members. This leads to bursts of productivity, with people in the zone, with their heads down and distractions banished.

The result is a large number of "completed" stories, and, of course, correspondingly impressive high velocities. There's lots of UX work done. Lots of db work done. Lots of server work done. But there's nothing to demo yet, because the work hasn't been integrated. Nothing's actually working or done, except for your stories.

You'll notice this happening when you have to add in "integration stories". These are stories for integrating various layers of work. This is when you discover that the db work isn't exactly what the mid-tier team was expecting. Or the UI team didn't quite understand what the server people put in place. Integration hell is the technical term... you end up spending excessive amounts of time doing frustrating work. Nerves are frayed and tensions run high. Fingers are pointed as people's expectations are dashed again and again.

The alternative is work more "slowly" and tackle vertical slices of work. With a verticle slice, we focus on one story, but we make it work end to end. This means that the UI gurus work alongside the server team, who are working with the database gurus, to get one story completely working. No one can be "done" until the story is working.

What's the advantage? On the surface, we're working more slowly. We're pulling people out of their specialties, forcing them to talk to non-specialist team members. It feels more cumbersome and it feels like you're making less progress. But those feelings are deceiving. We're doing three key things that provide enormous productivity gains.

1. We're focusing on smaller amounts of work. The thin slices that we complete force us to break down the big stories, then complete and potentially deploy a story before the business changes their mind about our priorities and changes our direction.
2. We're building a solid team. Forcing conversation and removing and entire category of interpersonal and inter team conflict. Instead of leaving a series of almost working stories, we're discussing those integration points during the iteration and resolving confusion before the code is written. When people do move in different directions, it'll be for a small amount of work instead a series of dozens of stories.
3. We're removing the integration stories by integrating as we go. No story can be marked as "Done" until it's functional. This is a very different approach and it eliminates the need for integration stories or integration sprints. At any point, the code can be deployed.