Requirements model vs User Stories in scrum tool

[EA9000]

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).

[Robert Sheridan]

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.

[qwerty]

.. user stories only exist for the life of the project ...

That really sounds like production for the waste bin  

q.

[Robert Sheridan]

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.

[Geert Bellekens]

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

• As instructions for the developer
• As documentation of our system.

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!

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

[qwerty]

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

Definitely not. I am one and telling the same. But that's not grumpiness. It is the essence of a long experience.

q.

[Robert Sheridan]

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.

[Sunshine]

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

[Stoppy]

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.  

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   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  

[qwerty]

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.

[Marc Vanstraelen]

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:

• Individuals and interactions over processes and tools
  
• Working software over comprehensive documentation
  

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!

[qwerty]

If you take "Working software over comprehensive documentation" serious, you are on the wrong party here.

q.

[Glassboy]

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".

[Paolo F Cantoni]

Echoing what Glassboy has said,

There's a (possibly) apocryphal story that a bunch of "real" architects  (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

[PeterHeintz]

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.