I was reading "Growing Object-Oriented Software, Guided by Tests" lately.
Authors of this book sugested to always start developing a feature with an end-to-end acceptance test (before starting TDD cycle) to not loose a track of progress and to make sure that you're still on the same page while unit-testing.
Ok, so I've start writing a veeeery simple application in python+django just to try this approach out. I want User to be able to ask a question via contact-form, the question should be then stored in a db, and a signal after completion should be send to notify mailer which will send follow-up message.
Question is - how you'd approach this first end-to-end test in this case? Do you have contain all possibilities in this first test, or maybe I'm misunderstanding this whole technique. 
Any examples would be most welcome.
This use-case leads to several test-cases (every tests a dedicated possible path of execution). 
When writing tests focus on one possible outcome, after a while test-suite grows. The first tests then also give you safety net as regression tests to not break anything which you already implemented successfully.
My first tests would be:

Happy path 1st part frontend-form + controller layer: User passes correct data, controller take the form and log to console/stdout    
Happy path 2nd part: Instead of logging to stdout, things get stored to database
Happy path 3rd part: Follow-up mail gets sent and received by User
Validation error handling (user fills form out incorrectly, e.g. misses mandatory fields, wrong email-pattern)
...

Fill out the rest ;) Depends on the more detailed requirements...
Remember to implement above as simple as possible. When all tests are in place, refactor ruthlessly to make "internal quality" nice.
"Zero Iteration" - end to end acceptance test in simple contact-form feature