Apologies that I won't every be able to make these discussions, my 8-5 job will 
prevent me from doing so.

I think you're on the right track, the user story should be very focused on 
that specific story. Unless the user story is for someone forking the snowdrift 
website, then libs and databases are probably not appropriate in the story. 
When I begin yo craft marketing and/or help information based on the user 
story, I won't care that the database is postgres or how the tables are laid 
out. In fact, those details would actually slow me down in doing my work.

Taking a more agile approach and working on what is directly in front of you 
seems like it'd be a good idea here, but I may be wrong.

I also agree with focus on the MVP.


On February 26, 2016 1:29:29 PM PST, Bryan Richter <br...@snowdrift.coop> wrote:
>Yesterday while fleshing out user stories, the question came up of
>whether or not user stories can capture everything, or whether some
>information should be deferred to specs.
>In my opinion, separate specifications are needed because user stories
>only capture features. It is not a user story that users have unique
>ids in the database, to name a trivial example. Perhaps I should list
>a more interesting example: It is not a user story that a single,
>reusable library handles all alerts for the system. Stories will talk
>about *specific* alerts, or even possibly about features of alerts in
>aggregate, but they will never say "alerts are handled by src/Alert.hs
>which exports the following symbols: ..."
>If I'm just arguing semantics let me know.
>It's certainly possible that all *site features* can be captured in
>stories alone.
>Discuss mailing list
Discuss mailing list

Reply via email to