Agile Software Development Training

I recently attended a 2 days training on Agile methodologies for software development. Following are some of the salient points that i took a note of (may not be in order):

• Agile software development emphasizes on more frequent releases (at least once per month). At the end of every sprint the product should be in releasable quality.
• In order to keep the software in a release-ready state we need to build automated test suites and run the tests upon every check-in (continuous integration).
• Plan only for short term (at max 2 sprint worth of duration) so that we can always re-prioritize the requirements (grooming the backlog) to accommodate any changes to the requirements.
• We need to focus on driving down the fixed cost of development (like the cost to run the regression tests by running the regression tests through automated test suites) as much as possible.
• Break down the dependencies on the hardware device by employing simulation tools or mock testing whenever cost to do so is acceptable.
• To start with test automation, build a safety net of unit/acceptance tests around the legacy code.
• TDD - Test driven development - emphasizes more rigorous unit testing (tests written prior to coding) - which makes it easy to catch regression issues from occurring going forward
• Separate GUI event handler logic from the actionPerformed() method into a separate wrapper method which can be tested without invoking GUI.
• Validations should be done on both client and server side preferably in common code being invoked from both client and server
• SCRUM - is an agile project management process as represented with the screenshot below:

• Product Owner (not shown) - same as product management team
• Product backlog - requirements gathered from customers or partners. It is comprised of Epics (a big story) or stories. A story is a requirement adding value by itself. 
• A story can be split into one or more stories during the "User Story Workshop" meetings (similar to functional specification review meetings where development team, product management and testers meet to understand the requirements more clearly and the outcome of this meeting is: more new stories which can fed back to product backlog, acceptance tests document which is written to test all possible use cases and shared understanding between participants)
• The length of a story should typically be small (roughly 2 days worth or so)
• Multiple stories are then taken up in a sprint (roughly about a month long) phase in which those stories are implemented 
• The progress of sprint is measured using a burndown chart (which is a chart of the work remaining to be done against time)
• Size of team = 1 to 14 people
• The team can be comprised of some developers who will write code and automated unit tests, testers who will create the acceptance test document and automate those acceptance tests and also do some exploratory testing towards the end of the sprint
• A nice video of Ken Schwaber on SCRUM @ Google.
• Tools:
• Continuous integration : Hudson/ Cruise Control
• Unit test: TestNG
• Acceptance test: Squish/ QFTest

The above notes is mostly what i could glean from the training i attended though it may not still summarize the details well enough or may have captured some details inaccurately.