User Stories (Agile) vs BRDs (Waterfall)
1st of all, I'm new here, so I hope this question belong here.. 2nd of all, if this has been asked and discussed before in here, please point me accordingly and apologies in advance (although I did try searching beforehand)
I've been learning more n more about Agile (mainly 'cause of my job search and with so many roles now requiring or mentioning Agile). As a ProdMan/BA, I've been doing Waterfall for the past 10 years... I've watched tons on videos and presentations on YouTube re Agile (sprints, backlogs, user stories, daily stand-ups etc)... it all makes sense, my only issue/concern is User Stories which in Agile replace BRDs you have in Waterfall. Again, I read what they should contain, how the should be phrased etc (i.e. WHAT and not HOW etc), still.. I'm slightly confused in terms how SIMPLE they appear to be compared to DETAILED specs in BRD/Waterfall
I guess it's better to give some example of my recent specs/BRDs I did (in Waterfall)... it was about the online verification process (+ new UX/UI) that captured certain customer bio/address details, sent them to a 3rd for online verification, then log the details to be used for different MI purposes... so, first I had a nice Visio flowchart explaining the whole new workflow (front-end/UX + back-end) for the devs and stakeholders to better understand the whole picture, then all the new wireframes/mock-ups of the new forms, what details should be captured, validated, error handling + messaging, and sent to a 3rd party, then logged in Table X or Y, then mentioning that report X should be enhanced, then that changes to the .INI file handling this should be catered for etc..
- with Agile, does that mean that "data should be logged in Table X" is one User Story, "changes to the INI file" another User Story and so on? What about mock-ups...dont PM do them in Agile, and leave it to devs?
- how to you handle "As a .... " when writing a UserStory when there is no actor/user, but it's something that the system should do? E.g. log data in a specific table
quote: “- how to you handle "As a .... " when writing a UserStory when there is no actor/user, but it's something that the system should do? E.g. log data in a specific table “
You don’t. A user story is not supposed to be detailed in technical implementation. It is supposed to be precise in how a user receives value from using / interaction with the system.
A User Story is a reminder to communicate with the user. I you detail system implementation in a User Story, you are water falling.
For transaction data, the data flow could be included in a user story.
As a manager, I want the date Y been saved to Table X, so that I could read the data report.
For error message or trace log, they could be included in the definition of done or implemented a cross-cutting design.
Just for your reference.
Thanks for your reply/input - but if you don't (specify), doesn't it mean it's left to assumptions for the devs and might be overlooked? With the back-end/db process requirements in my BRD, I do/did not so much mean to tell devs how to implement it (they know it better!), it's more to make sure that future business needs are covered, basically, I want all my bases covered (given some prior incidents) and avoid comments from devs like "we didn't do X, Y or Z because you didn't explicitly request it, we're not mind readers". (well, I guess comments "they are bad devs then" are not applicable her as it can happen, I'm reading, both in Agile and Waterfall, no?)
If I had it my BRD, I could go back to them and say "see, in section 2.3. we were asking about the reporting or audit trail requirements"... To paraphrase it then, if my BRD contains, say, roughly 15 items that can be considered as requirements (both functional and non-functional) would that roughly equate to 15 User Stories number-wise, is there this co-relation? I think I just want to get into Agile mindset but still keeping some cross-reference to Waterfall.
Here is a link to a YouTube presentation by Mike Cohn.
It contains definitions & examples of User Stories I have found very helpful.
I prefer to think of non-functional requirements as “constraints” of the system requirements.
There are 2 practices of my teams:
1. Add the contraints to the Definition of Done.
2. Add the contraints to the architecture design, sometimes it should be a cross-cutting design
For non-functional requirements as user stories, the article of Mike Cohn may help you
Hi Christiaan / Ching-Pei
Thank you both for your input.. have checked the links and will read as well, I guess