Vertical: the Agile Approach to feature break-downs in a cross-functional team

Its vertical, not horizontal

Very often, the way that requirements - usually described as stories or features - are broken into tasks is along a horizontal paradigm.  But in an agile context, this is the wrong way to promote flexibility, efficiency and teamwork  - in short, agility.

by horizontal, I mean in the sense of layers of an application, an architecture that works in separating the presentation, business logic and data handling parts of applications.  But should you create a breakdown of a story into tasks along these layers?
For example, a story "as a customer, I want to register on the website to gain access to personalized services"  registration data might include name, address, phone numbers, email address, passwords, marketing preferences, etc. Breaking the story horizontally would get the following:

1. write page HTML
2. write JavaScript form validation
3. write business level logic
4. write database queries
5. Write test cases
6. execute tests

 The problem is, we have just broken this down in accordance with waterfall.  You cant start working on the validation, before the HTML, and you cant finish the business layer until the database work is complete.  But worse,   you must complete the first four tasks before doing any testing.  So by breaking this along layers we have introduced a mini waterfall.  If each story is treated in the same way, this will lead to terrible issues with dependencies, throughput and team "silos"
This is a situation that can often happen, because it "seems natural" to do it, and is what developers and testers can easily identify with.  However, this is a trap.

Instead, stories should be broken down vertically!

A vertical breakdown is where tasks include all necessary layers of the application to complete a tiny peice of functionality, including testing (and any other phase).These tiny pieces are worked on and delivered by several members of the team at once - i.e. when the designer is building the html, the developer can also code the business logic, and the tester can write test cases.  So a vertical breakdown might look like this:

1. register name
2. lookup address
3. validate email address and password
4. save marketing data

here are the advantages:

• The team can really start working together, rather than just working on bits of the same thing - no more silos
• The team can now start on the first tasks together - designer, coder, tester. 
• These tasks are small, short-lived so they can soon be into the test phase, shortening the build-test cycle.
• if delays in the sprint happen (i.e. due to underestimation, sickness, priorities) work can stop on the story after any of these tasks and the work done until now is still deliverable.

 It can be a difficult change to a team's way-of-working, as they may have to go against years of training and thinkng in this way, but not doing so will doom the team to stay at a low level of agility and efficiency. But it ca also be a sig of a team;s maturity that they can start working together on the verticals.