What is working software?
A tester is delivered supposedly-finished code that has nothing ready to test:
Half the functionality of a new feature has been introduced - the other half has not yet been completed. However the developers say this is working software because what was handed over works. But it’s no use to a beta customer site - can’t really show it to a user - can’t really test it as there is no flow. It’s a bit like saying a car ‘works’ when it has no back axle but please test away anyway because the front wheels are fine. Is there a definition of ‘working software’ anywhere?
I answer:
My definition: a feature is working if some person somewhere would be willing to pay more for the software with the feature than she would for the software without it.
Another way of putting it: at the end of every iteration, you should be able to sell the software for more money than you could at the beginning.
Sounds like your feature isn’t working.
As Chet Hendrickson pointed out in the thread, the trick is getting good at breaking Grand Ideas down into bite-sized chunks that can be implemented quickly but still do something useful. That can be hard to learn, but I’ve been impressed when I see it done well—impressed enough that I’ve come to the working assumption that it’s always possible. If you can’t see how to do it, that just means you don’t have enough experience and haven’t learned enough tricks of the trade.
Steve Gordon added:
If stories are split architecturally (horizontally), then the “working software” is quite like what you describe. If stories are sliced vertically (i.e., it does work end-to-end, but only for a few scenarios), then it is more useful for testing, feedback, and validating the architecture. Vertical slicing is what is recommended, but developers tend to think in components, so it is much easier for them to split stories into one for each component instead of figuring out which scenario (sometimes, a trivial one) they could actually do end-to-end through all the components within a single iteration.
In my experience, defining small stories is one of the toughest things for the product director to learn. Building an architecturally coherent system in small slices is one of the toughest things for programmers to learn.
As Jeff Patton has pointed out, there are dangers to small slices: it can be tricky to make everything hang together into a coherent, usable system. (See his span planning, for example.) Perhaps incorrectly, I emphasize getting good enough to be dangerous.