Skip to main content

User Stories (Agile) vs BRDs (Waterfall)

Last post 11:08 am July 23, 2015 by Renars Zivers
6 replies
07:05 am July 21, 2015

Hello all..

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


09:35 am July 21, 2015

Renaers,

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.


10:21 am July 21, 2015

Hi Renars,
For transaction data, the data flow could be included in a user story.
For example:
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.


11:22 am July 21, 2015

Hi Christiaan,

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.


01:34 pm July 22, 2015

Here is a link to a YouTube presentation by Mike Cohn.

It contains definitions & examples of User Stories I have found very helpful.

https://www.youtube.com/watch?v=6q5-cVeNjCE


09:56 pm July 22, 2015

Hi Renars,

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
https://www.mountaingoatsoftware.com/blog/non-functional-requirements-a…


11:08 am July 23, 2015

Hi Christiaan / Ching-Pei

Thank you both for your input.. have checked the links and will read as well, I guess

Thanks
Renars


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.