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?

  • it will not happen in a day, take easy approach
    – Yusubov
    Jul 1, 2012 at 10:46
  • If you work for a software service provider then the SRS may not be needed to do the implementation but to do the "blaming game" when customer wants to reduce the cost or serviceprovider arguments that more money is needed or both are going to court.
    – k3b
    Jul 29, 2015 at 11:41

4 Answers 4


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.

  • 2
    @PhD: You're right. It's almost primal. And that's why you won't win this battle with any kind of logic, only with evidence. Baby steps.
    – pdr
    Jun 30, 2012 at 23:23
  • 2
    I have worked for managers that confronted change with baby steps it was their code word for "do only enough to fail so I can say I was right" this is not a path to success because it show a fundamental lack of comprehension of the new methodology and a lack of complete buy in by management which is crucial to successful change. This sounds good in theory, but in practice it is an excuse to not change and claim victory that the new way doesn't work and the old way does. Thus the SRS was get reenforced and the stories will get labeled as extra work and you will be back to where you were.
    – user7519
    Jul 1, 2012 at 14:19
  • 2
    My experience isn't singular, it is over my 22+ years in the industry, most of which was consulting. So I have worked with many more managers and decision makers than most people in the same amount of time. My point is this baby steps approach is a failure approach, only upper management commitment to the change and the philosophy behind the change is going to lead to successful implementation. If his colleagues aren't convinced, letting them continue to do what they want won't convince them, it just feeds the we still need the old way and the new way is a waste of time argument.
    – user7519
    Jul 1, 2012 at 17:03
  • 1
    @JarrodRoberson I just want to add that my experiences more closely reflect yours. There are two types of people, and thus two types of managers, conservatives and risk-takers. Conservatives are naturally averse to change and risk. When they find a model that works, even poorly, they stick with it. When change is forced or pressed on them they subconsciously sabotage it by trying to take baby steps. This is why the only time I have ever seen true Agile adoption work is when it is being led by risk takers.
    – maple_shaft
    Jul 1, 2012 at 18:14
  • 2
    @maple_shaft: The trick is to keep moving forward. If an incremental change doesn't work, don't necessarily take the same step back again, consider why it didn't work ... like maybe you're spending too much time still, writing a now-pointless document. Now I will concede that it takes a good manager to think that way, and that most will run back to their comfort zone. But, by exactly the same rationale, that doesn't mean that the only other option is drastic change. A bad manager will screw it up wither way.
    – pdr
    Jul 1, 2012 at 19:49

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.


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.

  • you'll be quite surprised, the user stories ARE managed by a tool that can (and does) export it as requirements. However, the concern seems to be of 'translating' the user-stories into the SRS language of "the system shall..." etc. and NOT leave it as user stories.
    – PhD
    Jun 30, 2012 at 21:16
  • 1
    Well if the hang up is the "shall/must/may" termanology you are probably spitting into the wind with those people. User Stories tell WHO / WHAT and most importantly WHY something needs to be done, much more useful than those static use cases, which are more wrong that correct in most cases.
    – user7519
    Jun 30, 2012 at 21:27
  • 2
    -1: Not disagreeing at all with most of the answer, however stating that and SRS is "A requirements specification is an temporal artifact document anyway, it isn't a living document," is so wrong is shows a disturbing lack of understanding what an SRS is for, or how it's used when done properly - usually only in legacy waterfall model software houses today.
    – mattnz
    Jul 1, 2012 at 0:09
  • 5
    A SRS is a dead document as soon as it is published. I have written them since 1990. They are like a war plan, they never survive first contact. And they never keep up with actual implementation, unless you have a dedicated team of writers constantly editing the thing and even then is is wrong because of the disconnect from the constant change and developers that are always ahead of the document, and don't always tell the document owner what is going on. Companies spend 1000's of hours writing stuff like that, and the documents get put on a shelf and rot while the development starts.
    – user7519
    Jul 1, 2012 at 2:18
  • 3
    @JarrodRoberson +1 for you. Indeed mattnz is right as well that the SRS is supposed to be a living document, but then you take a couple of critical production issues that the customer demands be changed, while working on one or more branched releases of the code base, misinterpreted requirements by the business analysts, the developers, and QA... what you are left over with is a document which is not a true reflection of the system right now, but also not a true reflection of the user needs. User stories are truly adopted by companies that are more concerned with the client than the system.
    – maple_shaft
    Jul 1, 2012 at 18:20

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.

  • 5
    Be very careful. Will only work if your co-workers are very secure & you have a good relationship with them. Many people get upset if you use humour to tell them they are wrong & hidebound.
    – MarkJ
    Jul 1, 2012 at 6:29

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.

  • 1
    Sorry, that is not much of an answer. You say 'show statistics' and do not even provide links.
    – Jan Doggen
    Jul 28, 2015 at 19:36
  • and do write complete words and sentences...
    – jwenting
    Jul 29, 2015 at 8:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.