Maybe I need some better perspective, but I can't imagine breaking down all of my programming tasks into 15 minute increments. That is, to be able to commit new, tested, working code to a codebase on such a short timeframe seems like it's introducing a lot of overhead in context switching and that it would be very difficult to break down a complex piece in such a manner.
As I mention in the article, you don't need to break down the whole task into 15 minute increments - just the next chunk.
Think of it as a kind of extreme-agile approach. Don't plan the whole task ahead of time (well, do plan roughly where you want to go), but before working, do break off a small chunk of the task ahead that you can do in a short time.
I've conducted all sorts of coding tasks in that way, from building new functionality (easy - just make sure you don't break old stuff while building new stuff, until the new stuff is ready and tested, and work in small increments) to major, multi-day refactorings (always do one tiny bit of the refactoring at a time, and commit as soon as it's done).
It doesn't need to be "tested and working" unless it's visible (or non-trivial to hide). If it can be hidden easily and doesn't impact other existing functionality, then it's easy to maintain in a closed state.
With SCM's like Git, you can do that committing into a separate branch so that you even have a "meta" roll-back ability, in case you find out halfway through that actually you were going in the wrong direction.
PS: Also, 15 minutes is just my ideal time length for each sprint. Adjust that for yourself - the key concept is to close tasks regularly, not to worship an egg timer :-)
