What's up with the community's definition of User Stories

I thought I had a good understanding of Agile User Stories - a high level description of some functionality in the form of "As a <certain type of user>, I can <do something> so that I can <achieve some business value>" which can be implemented in one Iteration/Sprint. Now, I keep hearing and reading people who I respect saying things which go against this definition.

A few examples: A couple weeks ago, I heard someone say "The stories weren't detailed enough for the development team.." I thought, Wha? Stories are meant to be high level and if you use acceptance criteria this comes after the team starts looking at them, doesn't it? It sounded like the person felt that Stories had to be "fleshed out" somehow before development could get started. Sounds like BDUF to me.

I just came across an essay from 2010 by Mary Poppendieck where she talks about "detailed stories" and seems to equate "Stories" with "Requirements" or detailed design specs (http://www.leanessays.com/2010/12/product-owner-problem.html). She sounds like she's counseling against Stories. If that's what Stories mean to her, I agree with her.

Also, I've recently seen talk of how stories should be small enough to code in a day or two (I'd call that a task) and another reference to "codable stories." None of this sounds right to me. It sounds like a large number of Agilists are seeing stories as part of the design pre-development.

Has the definition of Story shifted on me?

Thoughts?

Tom
Shared publiclyView activity