13 Facts About Extreme Programming

Extreme Programming is one of the aspect of Agile Processes and probably among the most popular ones.


It has proven and established its success on global front

It is independent of the project size, industry size or industry type.

The topmost priority of Extreme programming is customer.

It focuses on delivering what is actually required by the organization rather than talking about a delivery of big elephant with no clear vision of delivery date.

Instead of committing to produce everything it promises to produce what is the first need of organization. So once this gets delivered the next most important requirement becomes the first.

This way Extreme Programming never takes complete customer requirements in one go. It starts with outer periphery moving inwards.

It has proven its capability in providing a last minute change in the business requirement even during the time of delivery in a swift manner.

It puts a high emphasis on team collaboration and customer engagement in a constant manner.

Its simple mechanism has proved to be highly effective and productive.

It talks about least monitoring and high amount of self organization to produce highly efficient results.

The role of tester begins along with the developer and both go hand in hand.

Above with continuous engagement with customer promises to deliver any suggested changes with quicker implementation.

http://itknowledgeexchange.techtarget.com/quality-assurance/13-facts-about-extreme-programming/

Scope of User Stories

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/

9 Facts About User Stories

source: www.globalnerdy.com

User stories are not same as use cases though they objective and purpose of both is same. 


User stories are crisp, realistic, to the point, directional, practical, purposeful, resulting and have multipurpose.

User stories are a good alternative of business requirement document but are shorter and crispier than the voluminous size of the latter.

User stories have a huge amount of objectivity in terms of declaring or demanding a business feature or function to be fulfilled by the software application.

They are somewhat having a good amount of resemblance with business scenarios.

User stories are created by or with the help of experts in specific business area in a specific format and limited text. User stories form a solid foundation for test cases specially the acceptance tests.

Unlike detailed requirement documents prepared in traditional project management process, user stories are limited to only of length that is sufficient enough to depict the requirement in such a fashion that the overall requirement framework can be understood, and provide  near to perfect timelines for its deployment.

The actual detailed requirement is understood at the time of its development and deployment by developers.

The latter part happens in direct interaction of development team with the business core user or the story creator.

http://itknowledgeexchange.techtarget.com/quality-assurance/9-facts-about-user-stories/