Software the Agile Way....

C ommunication - Most desirable is face–to–face communication where we can talk, respond, gesture and draw on a whiteboard. Less desirable are written documents. XP stresses communication through practices such as pair programming. S implicity - This is a value of XP teams because it keeps their focus on creating a solution to the problem faced today, not the problem anticipated tomorrow.They remain constantly focused on doing the simplest thing that could possibly work. F eedback - XP teams value feedback, and the more immediate the feedback the better. This is achieved by Pair programming, Continuous Integration,Automated Testing and from customers. C ourage - XP teams value courage. For example, they have courage to refactor their code (because they have automated tests to back up that courage).They will use a metaphor and maintain a simple design through refactoring and test driven development.

What is a User Story?  Simply put, written from the context of the user as a simple statement about their feature need. They should generally have this format. "As a -role-, I want -goal/desire- so that -benefit-" How is a User Story different than a Use Case?  While a use case is highly structured and tells a story, the User Story sets the stage by stating the need. A User Story is the prelude to the use case by stating the need before the use case tells the story. How does the User Story fit into the process?   User Stories are great as an activity in collecting and prioritizing the high level features. Getting this initial feedback from the customer is a simple way of trying to get all of their needs identified and prioritized. The User Stories will then morph themselves into the   business requirements   and use cases. USE CASE Template-  Use Case Element Description Use Case Number ID to represent your use case Application Wha...

A tester on an Agile team should not just be doing testing after implementation, but should be actively involved all the way through development.  They can spot testability problems and other gaps from the very beginning, help the developers design the implementation with testability in mind, and define the tests before and during development to help the developers hit the right target.  As this is the case, the tester really needs to understand the whole story, not just the testing aspects. Quality is the responsibility of an Agile team, not any one individual. Offloading quality tasks to Tester people is a handoff that decreases the responsibility as well as the agility of the team.  Offloading will not increase quality in the long run nearly as much has collaborating. These people should be integrated, which means they need to collaborate with the rest of the team on quality tasks as well as collaborate with the team on other tasks (including story pointing). ...

The purpose of velocity is to calibrate the current local value for a story point in order to facilitate planning for the near future.  This allows us to continuously deliver value and steer a project without having to put a lot of time and effort into estimation.  Estimation does not deliver any value, so the less time and effort we can get away devoting to it, the more time and effort is available for actually delivering value.  Just estimating story points and moving on without worrying much about precision is the fastest way to get on with doing the work.  The alternatives that would seem to create more order and precision to estimates never actually produce a sufficiently better outcome to justify the otherwise unnecessary time and effort required to do so.  There is, however, an alternative that even makes the little bit of time and effort required for story pointing and velocity calculation unnecessary. Just always split all stories into the approxim...