

The Problem with User Stories - danielharan
http://jamesgolick.com/2010/1/4/the-problem-with-user-stories.html

======
joshwa
Starting with the UI _is_ a good idea, but completely ignores the functional
requirements that aren't embodied in any UI elements - business rules,
automated processes, workflow, behavior related to integration with other
systems, etc.

User stories are great for fleshing out (and flushing out) many of the
business requirements, but for applications of any complexity, a more complete
requirements gathering and review process is required.

~~~
danielharan
Last night I spent 1 hour going over an old system's functionality for a dance
studio, in preparation for a rewrite.

The most surprising thing was the reservation sub-system. "Oh, we don't use
that anymore; we've got Google Calendar".

That was listed as a "nice to have" in the original docs, but was disposable.
With a traditional workflow, we would have spent a days or weeks building
something.

We can iterate business requirements too - and only build those business rules
necessary for the UI we've sketched out.

------
mattmcknight
I vaguely get the point here that user stories aren't enough, you need
pictures too. Maybe the bigger problem working this way is that you end up
wasting a lot of time creating stories for the whole project, when you should
use more of a just in time approach and only thoroughly define and then design
those things that you are about to work on, with consideration of the eventual
overall conceptual design in mind.

------
AndrewDucker
Of course User Stories are incomplete by themselves.

User Stories are the starting point for conversations with users. From those
conversations you build quick mockups or sketches, and get continuous
feedback.

If you're taking user stories away and building directly from them then you're
not agile - you're building mini-waterfall projects.

