This approach makes sense for a procedure you know exactly how to do. In the case of a procedure I do not know, I break them down into simpler and simpler pieces. Until I get to one I can do, then come back up the graph. Maybe akin to a depth first graph
example story: as a user I would like a form page that take an address I enter and renders a google map of it
`In my younger and more vulnerable years my father gave me some advice that I’ve been turning over in my mind ever since.
“Whenever you feel like criticizing any one,” he told me, “just remember that all the people in this world haven’t had the advantages that you’ve had.”` - The Great Gatsby
I would inject into your list of what really matters something Linus said: communication. Having each member of the team (1000 contributors to the kernel by Linus's estimation) in a different corner of the world is a huge consideration.
This article can be summed up by point 1 of George Leonard's keys to Mastery, or Getting Good at Anything. All 5 major points are as follows:
1. Find good instruction. (Read good code, find a good programmer)
2. Love to practice. (Write code.)
3. Have the beginner's mindset. (Don't get cocky, observe with new eyes.)
4. Have a vision / goal. (You want to be an architect? Graphics guru? AI master?)
5. Push the boundaries. (Code beyond your perceived "abilities".)
A more succint and general version of that quote is by TS Elliot: Talent copies; genius steals!
example story: as a user I would like a form page that take an address I enter and renders a google map of it
http://i.imgur.com/38pXuJT.png