In David Allen's "Getting Things Done" [1], tasks are organized in terms of Next Actions. A next action is the absolute next thing you need to do to advance towards a particular goal.
For example, a goal might be to organize your finances. The next action might be to balance your checkbook.
As you complete each next action, you figure out what comes next, and add it to your list. You organize your next actions in terms of the context in which they will be done. This might seem counter-intuitive, but it make sense when you think about it. If you have a big requirements meeting coming up, wouldn't you rather have a list of issues to discuss in the meeting in one place? Other forms of organization, like chronological or topical, fall apart, because there is no guarantee that the timing will work out the way you expect or that you will be able to remember the topics that you created from one day to the next.
In Test Driven Development [2], you constantly cycle between writing tests and implementing the functionality that they test. I find that I sometimes lose my place, and over implement a class, writing code that will never really be needed.
So I started maintaining a "test to-do list". Whenever I encounter a situation where I think I am going to need another test, I just add it to the list. This keeps me focussed on getting tests to pass. When I eventually get back to the to-do list, I sometimes find that I did not need that functionality at all.
Like GTD's Next Actions, I store my to-do list with the test suite itself, so whenever I turn my attention back to that suite, I have a list of outstanding issues.
[1] http://www.davidco.com/
[2] http://c2.com/cgi/wiki?TestDrivenDevelopment
