9

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?

PhD
  • 2,531
  • 2
  • 18
  • 32
  • it will not happen in a day, take easy approach – Yusubov Jul 01 '12 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 '15 at 11:41

4 Answers4

14

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.

pdr
  • 53,387
  • 14
  • 137
  • 224
  • We did that and thus the transition to user-stories. But although the *burden* of the SRS is understood there seems to be a primal instinct to continue to use *that language* which seems to defeat the purpose. Not to mention, being ironical – PhD Jun 30 '12 at 21:30
  • 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 '12 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. –  Jul 01 '12 at 14:19
  • @JarrodRoberson: I'll be honest, I fail to see the relevance. Just because you've worked for bad managers, doesn't mean that this is bad advice to someone who isn't a manager and is trying to convince his colleagues. – pdr Jul 01 '12 at 15:27
  • 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. –  Jul 01 '12 at 17:03
  • @JarrodRoberson: I have had a fair amount of success with incremental improvement and very little with drastic change, with pretty much the same amount of experience you've had. So we'll have to agree to disagree. – pdr Jul 01 '12 at 17:55
  • 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 01 '12 at 18:14
  • 1
    @maple_shaft thanks, you articulated my meaning very well, *baby steps* in my experience is always form of sabotage, mostly subconsciously as you say. But sabotage in the end and nothing but justification for a case of staying with status quo. pdr thinks it implies incremental change, in practice the term *baby steps* semantically implies resistance to change, and no **commitment** to success in a passive agressive manner, *"I will let you do enough to fail just a little bit and prove me correct"* –  Jul 01 '12 at 18:28
  • 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 01 '12 at 19:49
  • sounds a lot like https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ – Nick Keighley Jan 06 '17 at 14:27
6

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.

kmote
  • 3,322
  • 6
  • 24
  • 33
  • 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 '12 at 21:16
  • The user-story capture tool is 'live' but there seems to be a need for adding the same attributes to them as in the SRS which seems a bit too much too soon. – PhD Jun 30 '12 at 21:17
  • 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. –  Jun 30 '12 at 21:27
  • The *funny* part, ***I*** concur :) – PhD Jun 30 '12 at 21:27
  • PS: It's not only the *shall* translation but also having all the additional data like inputs, outputs, sources, destinations be a part of the definition!! – PhD Jun 30 '12 at 21:28
  • 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 01 '12 at 00: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. –  Jul 01 '12 at 02: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 01 '12 at 18:20
  • I'm surprised by the dissing of the Use Case. Can't Story and Use Case coexist? One gives the big picture and reasons, the other can be helpful to define more precisely how things are meant to happen, including exceptions outside the main path. Isn't that useful for complex situations with precise rules? Or would you create stories for every rule? – leokhorn Jul 27 '17 at 07:08
0

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.

Michael Durrant
  • 13,101
  • 5
  • 34
  • 60
  • 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 01 '12 at 06:29
-1

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.

Joe
  • 1