Hi:
One key question is this: When you are partitioniing your system (i.e., dividing it up on a given level of your decompostion), what is guiding you to ensure you have flushed out all essential processes/tasks? What, in your technique, actually tells you that you are done?
Business systems tend to be complex requiring a litmus test of completedness, else, soon alot get missed. Only data flow diagrams offer a litmus test of completedness. With them, when data flows come from nowhere or go to nowhere, or when there is a process or task (same as a story) that has the wrong inputs or outputs, it glaringly sticks out, and is a strong red flag that something is amiss - that you are missing stuff.
DFD's offer such even when used in a very Agile fashion (remember, Agile is not only about minimal documentation, it is about quality documentation.)
And, by the way, once you have a quality decomposition down to the necessary level of detail level, you will find that tracking progress to the larger plan is straight forward.
Conversly, Stories offer no such litmus test of completedness.
Then there is the whole matter that stories offer only a forced, artificial partitioning, more comonly referred to as "sledge hammer partitioning". (You can partition an entity with a sledge hammer, but, the result is not very easy to deal with.)
The moral of the story is this, and it is something that, for some reason, the experts and guidebooks will not tell you: Don't try to use a weak technique when strength is required.
Tony