How do I convince my team that a requirements specification is unnecessary if we adopt user-stories?

Question

We are planning to adopt user-stories to capture stakeholder 'intent' in a lightweight fashion rather than a heavy SRS (software requirements specifications). However, it seems that though they understand the value of stories, there is still a desire to 'convert' the stories into an SRS-like language with all the attributes, priorities, input, outputs, source, destination etc.

User-stories 'eliminate' the need for a formal SRS like artifact to begin with so what's the point in having an SRS? How should I convince my team (who are all very qualified CS folks by the way - both by education and practice) that the SRS would be 'eliminated' if we adopted user-stories for capturing the functional requirements of the system? (NFRs etc can be captured too, but that's not the intent of the question).

So here's my 'work-flow' argument: Capture initial requirements as user-stories and later elaborate them to use-cases (which are required to be documented at a low level i.e. describing interactions with the UI prototypes/mockups and are a deliverable post deployment). Thus going from user-stories to use-cases rather than user-stories to SRS to use-cases.

How are you all currently capturing user-stories at your workplace (if at all) and how do you suggest I 'make a case' for absence of SRS in presence of user-stories?

score 14 · Accepted Answer · answered Jun 30 '12 at 20:53

Baby steps. Continue to write the SRS for a while. Then call a meeting and discuss whether they still serve a purpose. Does anyone still read them? Is the time spent on them justified? Is there another intermediate step that would be more lightweight?

You never know, you might find that you're wrong. Remember the Agile manifesto, we find more value in "Working software over comprehensive documentation," but there is still value in the latter.

My guess though is that you'll quickly discover that the desire to continue to write heavy documents falls away when they see how closely use cases and user stories relate.

score 6 · Answer 2 · edited Oct 15 '14 at 20:14

Epics are Placeholders

In just about any Agile methodology the concept of Epics would be as much as you should need for a Requirements Specification, place holders is what you need at that level. Those entries will be prioritized constantly, any more detail is wasted effort if the requirement gets low priority for a long time, or never even gets implemented. Documenting it and managing the documentation around it would be a complete waste of time. YAGNI extends to requirements activities as well as coding activities.

Tools are your friend!

If you use a proper tool to collect and manage the user stories, then you can generate the Requirements Specification from them. A requirements specification is an temporal artifact document anyway, it isn't a living document, it is a snapshot of requirements in time. And is never in sync with reality.

Automatically Generate Artifacts

User stories that can be exported from a proper tool are way more valuable than any static artifact document anytime. Personally I prefer Pivotal Tracker to track User Stories, I even wrote a suite of MoinMoin plugins in Python to publish all the various Stories and their states in the Wiki ( which contained detailed developer notes and the like about the stories ), live data is always better than static data.

The Wiki became a live document of all the stores/requirements and their state of completion and priority with details and comments and other meta data.

Way better than a huge Word document in Sharepoint that just gets emailed around constantly and never updated, guaranteeing that everyone has a different version and is out of sync with everyone else!

User Stories are Richer than Use Cases

The Use Story is much more valuable than a Use Case because they say WHY.

The User Story format: As a [ROLE] I [ACTIVITY] so that [WHY] is much more expressive than Use Cases that are like The System [shall/shall not/may/must] perform [action] ( where action is a flow chart ).

With a User Story, you have WHO wants to do something, you have WHAT they want to do ( which can point to a more detailed diagram/document for complex tasks ) and you have the most important part WHY they want to do this activity.

If you have the first, the second is completely redundant, and just noise at best. A traditional formal requirements specification from a Waterfall methodology has no place in an Agile environment.

In the End

If your management isn't committed to change you aren't going to be successful with a new methodology. I have worked for a 100+ billion dollar a year company, they didn't take baby steps in moving to Agile/SCRUM, they just said, the entire company is moving to this, here is the new way of doing things, here is when your training on the new way is going to start, here are the new tools we are going to use, here is the date we start doing things this way. It worked for them in less than a year. I have worked on implementing this in smaller companies with the same success.

Commitment

baby steps implementations, regardless of what the change is, is a recipe for failure. It is a code word for management that they quietly don't agree and are passively aggressively setting you up for failure. They are saying I don't believe in this enough to commit to it, so I will let you do just enough to fail/not succeed, that way they can say they tried and it didn't work and they way they were managing worked just fine all along. Partial commitment ultimately leads to failure.

In your case, they probably quietly don't believe in the User Stories, and after a while of doing both they will start to claim it is the User Stories that are useless and not the SRS, and will push to stop writing the User Stories, which will just lead you backwards not forwards.

score 0 · Answer 3 · answered Jun 30 '12 at 22:02

I would try and use humor.

Start with the http://www.halfarsedagilemanifesto.org/

Talk about this for a while (diversion)
and talk about what the conflicts in it really mean (open discussion),
then after a while turn to your organization (pivot)
and examine SRS and whether it makes sense with the new project set-up.

Then I would conclude (or maybe in another meeting) with a discussion about the change in the approach re: SRS and see if you have more consensus.

At the end of the day you are also constrained by budget and serving the business folks so there may be a point where you are a bit firmer in just what gets used, but this really depends on the industry, company size, organizational factors and many other such factors.

score -1 · Answer 4 · answered Jul 28 '15 at 18:50

Convincing mgmt to get away from the SRS and to start using user stories is essentially the same thing as convincing mgmt to adopt Agile. There are compelling statistics out there on the productivity benefits of Agile. One example is the presentation VersionOne gave at a 2013 conference. Show mgmt this industry data and if they are the listening type, you have a chance.