Requirements model vs User Stories in scrum tool

[Steven Bos]

We have the same challenge at the moment.  The agile coach has said that user stories only exist for the life of the project

I would just ignore that coach and just notify him that we will preserve the user-stories till the end of dawn.

We still have some architect requirements requirement and users stories we have documented as features/requirements. So a user story has a dependency with an architectural requirement for us. For now it works but it might evolve in something else if needed. Remember - it is SCRUM - something that migth work for one SCRUM-squad might not work for the others. It is a framework so use whatever works best for your team. But it helps if all the teams have a general standard way of using Sparx so it is easier to share information.

[bockfu]

From my experience, not everyone understands or applies use cases, requirements or user stories the same way.  The slice of the corporation I work for is using an agile framework called SAFe.  One of  the the things I appreciate about it is a set of available resources and concepts to help facilitate these these types of conversations..

For example, a solution intent aspect is referenced and cites MBSE.  http://www.scaledagileframework.com/solution-intent/ 

But I think the essence of the question was about how do the requirements bring value to the developer.   Naturally it is about the interactions but in practice I have used requirements as acceptance criteria when asked to provide direction to an agile team.   I also think it's prudent to cite an aspect of the solution intent in the "as a user I want...." Part of the user story.  For example "as a user I want foo to comply with req2344 so it can interface with bar"

The other aspect a scaled approach helps is to have a way to balance the vision with self organized agile teams.   So having a feature as something bigger the a user story provides a place to communicate the constrains (requirements) and cite the single source of truth.   

In my role today, I want to have conversations with agile teams but avoid being in the user story space.  The solution intent needs to be defined at an appropriate level of quality and completeness.  And the testing needs to be in place to fail early and fast. 

[only4thefish]

Just FYI...
With so many organizations going to user stories and epics, I decided to see if there was anything on user stories vs. use cases.  Ultimately I ended up on Alistair Cockburn's (author of the classic "Writing Effective Use Cases", 2001) website where he had an article discussing it.  I can't access it from here (blocked due to website classification of "none"), but try alistair.cockburn.us and search for it there if you care, or maybe www.usecases.org as an alternative.  Essentially, as I remember it, user stories are really more for scoping and estimating the amount of work required (hence why it goes away with each project), but that use cases ferret out the required functionality, hence functional requirements, of the system.  And those requirements models can obviously remain, if they are created. HTH 

[qwerty]

That being said I like to throw in my pound too. While Cockburn (to me) seems still to ride the requirements-horse, Bittner/Spence focus on added value in use cases. I think this aspect is one that is neglected by most of the other use case authors. And (pun intended) it adds value to the use cases.

q.

[PeterHeintz]

Defining without concrete knowledge of the concrete piece, that it should be thrown away is some kind of arrogance.

If you have something, you are sure you do not need in future, throw it away.

Do not let decide a person having no idea what the concrete thing is, to throw it away even it this person is having the most accepted reputation regarding your principle stuff on this globe.

[qwerty]

@Peter: I don't get it. Whom are you referring to?

q.

[PeterHeintz]

Hi querty!
My message I want to state is: That following some methods, guidelines and approaches is good when it helps. But the follower should never come to the point to follow those methods, guidelines and approaches as a machine.

So if e.g. a methods, guidelines and approaches tell me I should create user stories and  throw those away, I do not just throw away, but I switch on my brain and start thinking whether it is good  or bad to follow this methods, guidelines and approaches in my concrete scenario.

[qwerty]

That makes sense :-)

q.

[Oliver F.]

Late answer in an old thread but better late than never 

Basically what we are talking about here is how to name the same child. From my point of view this misses the point- the discussion should not be whether we should go with use case or user stories but what is the content of the required artefact. Or in other words: Which information is required upfront for which stakeholder and how does this information evolve in a way which makes it possible to develop/describe a solution suitable for all stakeholders now and in the future? (Note - talking about stakeholders involves customers, developers, architects, testers, maintenance staff, sales, etc.).

Having that said there is a certain ambiguity between requirements, user stories and use cases which often confuses development departments which then leads to the (often failed) attempt to simplify that by using only one of these.

Separating the problem into development phase domains (eg. by saying a requirement is an analysis artefact only) is not helpful either- you will face the problem that in dynamic environments requirements are appearing at any stage of development and stating that user stories are candidates for the dumpster creates a lot of redundant work to be done.

Now if we think about use cases it is a good approach (aka best practice) to look at them as a formal template which, if completely filled, contains the maximum amount of information required to describe a certain functionality to the maximum extent: Basic path, alternative path, exception path (often disregarded and ignored), constraints, preconditions, etc.
This is valuable stakeholder information- eg. testers can create their test cases, developers know how the system handles specific situations, engeneering can evaluate the capabilities of the system, maintenance personal can create their verification cases to check for failures, even sales can get an idea about the capabilities of the product they want to sell. Such a use case can also act as a contract to the stakeholders to enable commitment.
Remember what I stated above: This is the (desirable) maximum and can be customized to your needs.

However such an extent is not available when the first discussions with the stakeholders or customers start. In fact a compact user story is more likely to be created which is much more comprehensive and built much quicker. A user story today is often more like a rough sketch of user ideas than real development input.

So having a gap here between that sketch and the full information picture a best practice approach (at least from my experience) is to start with user stories with the customer/stakeholders to enter a further and ongoing discussion with them so that in the end all required information from the aforementioned template is complete and documented (while collecting further requirements in parallel). Whether we call it user story or use case in the end is a wording issue.
Long story, short sense: Seeing user stories as a lightweight variant of a use case which evolves over time is the key to prevent confusion.

Sorry for being late here, I have been absent for a while and just catching up 

Oliver