In continuation from my previous post on user stories, the basic fact about user stories remains established that it is a powerful mechanism to drive a project in a more promising mode. The results are more predictive in this way, quicker, and the whole game is played with a very low risk. Driving a new application development project based on user stories is not only interesting but high result oriented also.
User stories must be strongly depicted to provide low risk clue to declare the timelines. Release of user stories depends varies not more that 3 weeks and less than a week. While the development team starts working on a specific user story, it must be carried out in a most isolated state, with no interference, no other priorities and no alterations in plans. The developers must be very clear about the scope and boundaries of story. If a story is stretching beyond 3 weeks for its release, it needs to be fragmented into smaller pieces so as to arrive arrive within the limit of 1 to 3 weeks.
Similarly if a story is estimated to be released in less than a week's time, it needs to be added to some other stories so as to lengthen the release time but keeping in mind that the combined time should not go beyond 3 weeks. A release plan contains release dates of a number of such user stories. Stories are always business process centric.
http://itknowledgeexchange.techtarget.com/quality-assurance/scope-of-user-stories/
