The Problem with User Stories

jamesgolick.com

17 points·danielharan··4 comments

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.

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.

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.

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.

Reply on news.ycombinator.com