tag:blogger.com,1999:blog-13831777.post-21128472936366931872008-02-13T20:17:00.000-05:002008-02-13T20:17:00.000-05:00Hi Oscar,<BR/><BR/>At the end of the day, you can do whatever you want in software development, and most projects do! There are actually quite a few commonly agreed on software development best practices, but there is no name for this collection. Hmm, I think I've just stumbled on a new blog post. Anyway, with regards to your question, beyond this common set, no two groups do the same thing.<BR/><BR/>I would say that the quick answer to your question is that up to the part about user stories, you are on the right track, but that user stories do replace requirements documents and are not just for estimation.<BR/><BR/>There are of course two parts to requirements/user stories. The first part is gathering information from users as you have described. Then there is the recording of those requirements. XP tends towards fairly light recording, for instance via tests. However, many people use user stories.<BR/><BR/>Personally, I believe there is a lot to be learned from Requirements Engineering, but mostly on the elicitation of requirements, not on the documentation of those requirements. That is, finding out what users really need at a high level so that you can produce a product which meets their needs with high usability.<BR/><BR/>Two good resources on these subjects are:<BR/><BR/>Extreme Programming Explained – First and Second Edition, Kent Beck<BR/><BR/>User Stories Applied - Mike CohnDamon Poolehttp://www.blogger.com/profile/16561311551267979837noreply@blogger.com