Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
it will not happen in a day, take easy approach –  Yusubov Jul 1 '12 at 10:46

3 Answers 3

up vote 10 down vote accepted

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.

share|improve this answer
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
1  
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. –  Jarrod Roberson Jul 1 '12 at 14:19
1  
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. –  Jarrod Roberson Jul 1 '12 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 '12 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 '12 at 19:49

Epics are Placeholders

In just about an 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.

share|improve this answer
    
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
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. –  Jarrod Roberson Jun 30 '12 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 '12 at 0:09
3  
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. –  Jarrod Roberson Jul 1 '12 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 '12 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.

share|improve this answer
4  
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 '12 at 6:29

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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