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.

I wonder if anyone was in a similar situation and can advice as to how manage requirements best. I am responsible for user stories writing. However, I receive requirement in form of traditional specs often very ill formed and ambiguous. I am also getting wireframes together with spec. what I end up doing is converting requirements from the spec into user stories filling out all gaps along the way. by doing so I effectively do backlog definition and grooming at same time which seems to be incorrect. This is because developers don't look into product spec so I have to outline everything in user stories.

any suggestions on how to improve the whole process? one constant in this process at the moment is that I receive all requirements from product and have very little control on what I can redefine.


migration rejected from stackoverflow.com Jun 7 '13 at 12:36

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as not constructive by Jim G., MichaelT, gnat, Martijn Pieters, Yusubov Jun 7 '13 at 12:36

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

ultimately agile methods require some amount of customer buy in, if you don't have that you may need to develop in a non agile way, just make it clear that it will potentially cost your customer more in the long run if their spec is not exactly what they want. –  jk. Jun 5 '13 at 19:31
comments disabled on deleted / locked posts

1 Answer

I think it's very difficult, if not impossible, to translate requirements into user stories. A user story is, yes, a reminder about a conversation that needs to happen, but they don't mix and match. Example:


  • We need to have a database with posts and tags in a many-to-many relationship
  • We need a post page with the following fields: Title, Body, Date a list of tags
  • We need a posts by tag page
  • ...


  • As a user I want to be able to read blog posts so that I can be informed of the news of Contoso, inc.
  • As a user I want to only read posts that pertain to a specific topic so that I only find Contoso news about the product I'm interested in
  • ...

Notice the difference? User stories document a problem (or opportunity), requirements document a possible solution! The whole point of user stories is enabling a conversation. In the example above, only once you have a basic post display page without tags, and you can actually use it, you are going to have the conversation about how to let a user "only read posts that pertain to a specific topic". Is the answer still going to be tags at that point? Are tags that important once you have the basic page? Or maybe a summary page is more important?

In short: stories describe problems or opportunities to create value. It's possible that these opportunities change during the lifetime of a project, but it's quite rare. They often change in priority. Requirements describe solutions. Possible solutions change as opportunities arise, in other words, constantly.

You will have a hard time reverse engineering your stories :-)

I'm a bit disappointed this question has been closed and as a "programmer" this is the kind of question we need to debate. Right now I'm going through a process of converting a "Functional Specification" into user stories and the great thing about this exercise is that it really highlights ambiguities in the spec, providing an opportunity to seek clarification before embarking on the development. –  David Clarke Oct 22 '13 at 0:58
add comment