Sparx Systems Forum

Discussion => Uml Process => Topic started by: EA9000 on February 02, 2015, 06:39:32 am

Title: Requirements model vs User Stories in scrum tool
Post by: EA9000 on February 02, 2015, 06:39:32 am
For some time now, we use Sparx Enterprise Architect for our business analyses.
We have divided our EA project into 2 insights:

•      An insight “concepts”. We mainly use 2 models for this insight:
o      A domain model
o      A requirements model. Used for describing business rules (or validations) and other server side requirements
o      Sometimes an activity diagram

•      An insight “User interface”. This contains:
o      A requirement model containing user interface requirements (=behavior of the UI client)
o      UI mockups (copy pasted from our mockup drawing tool).
[ch61607]      We also link to the domain model and the requirements from the “concept” insight.

For a new project we have been asked to follow a more agile approach. The epics and user stories must be described into a scrum tool, so they could be linked to the sources and builds. However, it feels a bit strange considering our “requirements” in EA. The more detailed an user story is into our scrum tool, the more it looks like a requirement in EA -> duplicated work.  

I’m interested how you guys have equipped your EA project, especially in interaction with a scrum tool (user stories).
Title: Re: Requirements model vs User Stories in scrum to
Post by: Robert Sheridan on February 07, 2015, 01:19:34 am
We have the same challenge at the moment.  The agile coach has said that user stories only exist for the life of the project but because the EA model we are building is at an architectural level it is valuable accelerator for agile projects as they will not be starting from scratch but from an 'As Is' which will be refreshed as the project delivers.
Title: Re: Requirements model vs User Stories in scrum to
Post by: qwerty on February 07, 2015, 01:54:29 am
Quote
.. user stories only exist for the life of the project ...
That really sounds like production for the waste bin  ;D

q.
Title: Re: Requirements model vs User Stories in scrum to
Post by: Robert Sheridan on February 07, 2015, 02:00:13 am
Could not possibly comment, it is a very different way of working.  For us the key thing is ensuring that the architectural model is updated at the end to reflect the changes the project made and we hope that we will be able to point to the output of the project as collateral.
Title: Re: Requirements model vs User Stories in scrum to
Post by: Geert Bellekens on February 09, 2015, 06:38:23 pm
We use an agile Scrum-like approach in our development process, but we still swear by use cases.
You shouldn't throw away valuable proven methods just because they don't fit in the latest fashionable trend.

Our use cases, and the rest of your analysis model, serve two purposes
When your user stories only last during the project stage then they only serve as instructions for the developer.

That is all good when you are in project phase, and your only focus is to deliver. But it will come back and bite you in the ass when you are in maintenance.
Then suddenly you have to change certain functionality and you have no clue where to start.

But by then the fancy "Agile" consultants are already long gone, probably hyping the latest fashion (Micro-Services anyone?)

Tjee, I'm starting to sound like a grumpy old man! :o

Anyway, what I want to say is: shop around. Pick the good things from the different methods/fashions/religions and use your common sense

Geert
Title: Re: Requirements model vs User Stories in scrum to
Post by: qwerty on February 09, 2015, 07:36:11 pm
Quote
Tjee, I'm starting to sound like a grumpy old man! :o
Definitely not. I am one and telling the same. But that's not grumpiness. It is the essence of a long experience.

q.
Title: Re: Requirements model vs User Stories in scrum to
Post by: Robert Sheridan on February 09, 2015, 11:36:50 pm
No arguement here, I have found use cases, if well written, provide test scripts, end user documentation and training material as well as instruction for the developer.  We are aiming to maintain the catalogue of use cases we already have with that it mind.
Title: Re: Requirements model vs User Stories in scrum to
Post by: Sunshine on February 11, 2015, 07:11:46 am
You could think of user stories as an orchestration of use cases for certain personas. However it depends on the granularity of user stories. IMHO I think User Stories and Use Cases are good ideas but often misused by people lacking full lifecycle experience. By throwing them away at the end of a project you loose context and it may not be a good idea. I'd keep them myself.
My 2 cents worth :)
Title: Re: Requirements model vs User Stories in scrum to
Post by: Stoppy on February 11, 2015, 09:53:31 pm
Hi EA9000,

First off, Geert if your a grumpy old man, then I must be a grumpier old man, but I have to agree with qwerty.  ;D

Anyhow I started writing a long winded response but lost it with a BSOD, so cut it down to this from my perspective:

1. User Stories are great method of engaging the customer and capturing real requirements such as business rules, acceptance criteria and core process flow needs in a whiteboard workshop.
2. Use Cases are great method for giving the required details to the technical resource or developer, when I give a use case to the customer they just glaze over.

With regards to your Project needs you should probably promote stopping the project and rethink and reassess your framework and remove duplication as there might be a revolt from your BA's  ;D Sometime we are so fixed on delivering that project we never stop to refine and improve things on the way!

I would like to highlight there is some great integration with EA into TFS into MS Project Server for managing agile projects which provides the following:
1. Business Analyst writes process maps, gui's, requirements in EA
2. Developer estimate and assign task against requirements from EA in TFS
3. Project Manager drives project schedule from TFS estimates
4. Scrum master drives sprints from the TFS in dashboard.

The thing to remember with agile, is most people will try and perfect documentation, but the whole idea of agile is create conversation, trust and quick visibility and delivery to the customer.

Also as the requirements are light weight, it would be assumed and expected the documentation would expand and be refined as the capability matures from future releases.

Final note, it is quiet interesting how many BA's I have seen who are so keen to fill out the Use Case template, rather then white boarding and having a conversation with a customer.

Hope that helps!

Stoppy  ;)
Title: Re: Requirements model vs User Stories in scrum to
Post by: qwerty on February 12, 2015, 12:18:03 am
I see the whole process as reflection. The customer has an idea how the system should work. I reflect those thoughts in use cases until an agreement is reached. The use cases are now reflected to developers trying to build a system. It will eventually turn out that use cases need to be modified. Reflection to customer / developer / etc. The system design phase is a similar reflection which involves architects, developers and the machine.

It is not primarily the methodology that must be followed. It's the reflection process which keeps things running. Methodologies just help in this process. So from experience it helps to walk along the lines that methodologies paint but sometimes you're better off taking some new paths - always keeping in mind that it's dangerous in the dark forest.

q.
Title: Re: Requirements model vs User Stories in scrum tool
Post by: Marc Vanstraelen on July 01, 2016, 11:19:30 pm
I'm resurecting this thread, as I'm currently facing the same challenge. Our organisation's new CIO has mandated that we're going to use Scrum for the majority of our projects from now on, whereas we used to have a strong waterfall approach. I'm having to make a proposal on how our analysis method has to evolve to support this approach.

User stories are already being put in Jira, so I need to find out how this can balance with the use of EA for requirements, use cases, information models etc.

The agile manifesto says:
I take this to mean that the items on the left are more important than those on the right, not that processes, tools and documentation are to be thrown away. But there is always a risk that some people are a bit more radical in their interpretation. So one of my challenges as I see it will be to propose an acceptable level of process and documentation in line with the "just enough" philosophy of Agile (it's true that some of what we used to produce in a waterfall approach is pure overkill when you collaborate in an agile mindset).

So any insights, pointers, real life experience are more than welcome!
Title: Re: Requirements model vs User Stories in scrum tool
Post by: qwerty on July 02, 2016, 12:09:35 am
If you take "Working software over comprehensive documentation" serious, you are on the wrong party here.

q.
Title: Re: Requirements model vs User Stories in scrum tool
Post by: Glassboy on July 04, 2016, 08:08:05 am
So any insights, pointers, real life experience are more than welcome!

I think it is very simple.  User stories shape the design.  Requirements are for testing against.

Over the last decade technical projects have come to be almost wholly dominated by project managers, business analysts and change control specialists.  I came across a project the other day that had been started and stopped three times and had burnt a couple of years worth of funding without ever having anyone on it that could actually do the job of building the solution to the business problem.

This is the pain that is causing the desire for Agile - even if Agile isn't the solution to the problem.

In your situation I'd just turn things on their head.

So take from whatever you used to do in your Waterfall methodology for requirements (and use cases) only that which the testing team can test against.

For the rest of it, have an honest conversation with your Architects et al about what they just used to ignore.  There's probably quite a lot that wasn't a useful input for anyone.

BUT don't skimp on your information models.  Understanding your concept domains will help you avoid stupid conversations about things like "bounded context".

Title: Re: Requirements model vs User Stories in scrum tool
Post by: Paolo F Cantoni on July 04, 2016, 09:43:53 am
Echoing what Glassboy has said,

There's a (possibly) apocryphal story that a bunch of "real" architects  :-X (you know, the likes of Mies van de Rohe, Renzo Piano etc.) and they were asked "What is Architecture"?.  The only thing they could agree on (hence the collective noun for architects: "an argument of architects"  ;)) was that Architecture was:  "KNOWING WHAT IS IMPORTANT".

Also, as GB says, get your information model right.  As Jean -Raymond Abrial (a somewhat obscure infromatician) said:  "The sole purpose of an information system is to allow the user to ask the same question of the system and reality; AND GET THE SAME ANSWER!" (my emphasis).

The Information model is the closest you get to understanding the semantics of the world in which the system needs to exist (short of a formal ontological model).

Paolo
Title: Re: Requirements model vs User Stories in scrum tool
Post by: PeterHeintz on July 04, 2016, 07:10:44 pm
Don’t be dogmatic!
Engineering happens in the brain. And if several brains are involved, you need to connect these brains and this is done nowadays by communication. Whatever you need for suitable communication (meetings, documents, models, sketches or little slips of paper pinned on the wall) you have to do.

If you can create something good, just by interaction of individuals without processes and tools, that is fine but typically very unrealistic.

If you can create something good what can be maintained in future without documentation, it is a good thing as well, but as well often very unrealistic.

You have to consider, that agile manifesto people saw projects, where people lost the focus be writing vast quantity of useless information following a mindset “development is dogmatic executing a documentation process”.

Nowadays to me, it seem that maybe the same people switched to the mindset “development is hacking and called agile”.

If Scrum is good for you project, just do it, but keep in mind that Scrum is a kind of project management stuff, telling almost nothing about technical things. Not telling anything about technical thing does not mean there is no need to care about that.
Title: Re: Requirements model vs User Stories in scrum to
Post by: Steven Bos on July 06, 2016, 06:08:38 pm
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.
Title: Re: Requirements model vs User Stories in scrum tool
Post by: bockfu on August 28, 2016, 06:24:54 am
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. 
Title: Re: Requirements model vs User Stories in scrum tool
Post by: only4thefish on September 22, 2016, 04:19:28 am
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 (http://alistair.cockburn.us) and search for it there if you care, or maybe www.usecases.org (http://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 
Title: Re: Requirements model vs User Stories in scrum tool
Post by: qwerty on September 22, 2016, 04:48:12 am
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.
Title: Re: Requirements model vs User Stories in scrum tool
Post by: PeterHeintz on September 22, 2016, 06:53:18 pm
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.
Title: Re: Requirements model vs User Stories in scrum tool
Post by: qwerty on September 22, 2016, 08:00:12 pm
@Peter: I don't get it. Whom are you referring to?

q.
Title: Re: Requirements model vs User Stories in scrum tool
Post by: PeterHeintz on September 22, 2016, 10:41:49 pm
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.
Title: Re: Requirements model vs User Stories in scrum tool
Post by: qwerty on September 22, 2016, 11:28:27 pm
That makes sense :-)

q.
Title: Re: Requirements model vs User Stories in scrum tool
Post by: Oliver F. on May 04, 2017, 11:36:17 pm
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  8)

Oliver