http://agilemanifesto.org/principles.html

Principles behind the Agile Manifesto

We follow these principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

http://www.mountaingoatsoftware.com/topics/scrum

What is Scrum?

Scrum is an agile approach to software development. Rather than a full process or methodology, it is a framework. So instead of providing complete, detailed descriptions of how everything is to be done on the project, much is left up to the team. This is done because the team will know best how to solve its problem. This is why, for example, a sprint planning meeting is described in terms of the desired outcome (a commitment to set of features to be developed in the next sprint) instead of a set of Entry criteria, Task definitions, Validation criteria, and Exit criteria (ETVX) as would be provided in most methodologies.

Scrum relies on a self-organizing, cross-functional team. The scrum team is self-organizing in that there is no overall team leader who decides which person will do which task or how a problem will be solved. Those are issues that are decided by the team as a whole. The team is cross-functional so that everyone necessary to take a feature from idea to implementation is involved. These teams are supported by two specific individuals: a ScrumMaster and a product owner. The ScrumMaster can be thought of as a coach for the team, helping team members use the Scrum framework to perform at their highest level. The product owner represents the business, customers or users and guides the team toward building the right product.

Scrum projects make progress in a series of sprints, which are timeboxed iterations no more than a month long. At the start of a sprint, team members commit to delivering some number of features that were listed on the project’s product backlog. At the end of the sprint, these features are done--they are coded, tested, and integrated into the evolving product or system. At the end of the sprint a sprint review is conducted during which the team demonstrates the new functionality to the product owner and other interested stakeholders who provide feedback that could influence the next sprint.

What are the main activities in Scrum?

The sprint itself is the main activity of a Scrum project. Scrum is an iterative and incremental process and so the project is split into a series of consecutive sprints. Each is timeboxed, usually to between one week and a calendar month. A recent survey found that the most common sprint length is two weeks. During this time the team does everything to take a small set of features from idea to coded and tested functionality.

The first activity of each sprint is a sprint planning meeting. During this meeting the product owner and team talk about the highest-priority items on the product backlog. Team members figure out how many items they can commit to and then create a sprint backlog, which is a list of the tasks to perform during the sprint.

On each day of the sprint, a daily scrum meeting is attended by all team members, including the ScrumMaster and the product owner. This meeting is timeboxed to no more than fifteen minutes. During that time, team members share what they worked on the prior day, will work on today, and identify any impediments to progress. Daily scrums serve to synchronize the work of team members as they discuss the work of the sprint.

At the end of a sprint, the teams conducts a sprint review. During the sprint review, the team demonstrates the functionality added during the sprint. The goal of this meeting is to get feedback from the product owner or any users or other stakeholders who have been invited to the review. This feedback may result in changes to the freshly delivered functionality. But it may just as likely result in revising or adding items to the product backlog.

Another activity performed at the end of each sprint is the sprint retrospective. The whole team participates in this meeting, including the ScrumMaster and product owner. The meeting is an opportunity to reflect on the sprint that is ending and identify opportunities to improve in the new sprint.

What are the main artifacts of a Scrum project?

The primary artifact of a Scrum project is, of course, the product itself. The team is expected to bring the product or system to a potentially shippable state at the end of each sprint.

The product backlog is a complete list of the functionality that remains to be added to the product. The product backlog is prioritized by the product owner so that the team always works on the most valuable features first. The most popular and successful way to create a product backlog is to populate it with user stories, which are short descriptions of functionality described from the perspective of a user or customer.

On the first day of a sprint and during the sprint planning meeting, team members create the sprint backlog. The sprint backlog can be thought of as the team’s to-do list for the sprint. Whereas a product backlog is a list of features to be built (often written in the form of user stories), the sprint backlog is the list of tasks the team needs to perform in order to deliver the functionality they committed to deliver during the sprint.

Two other primary artifacts are the sprint burndown chart and release burndown chart. Burndown charts show the amount of work remaining either in a sprint or a release. They are a very effective tool for determining at a glance whether a sprint or release is on schedule to have all planned work finished by the desired date.

What are the main roles on a Scrum team?

Even if you are new to Scrum, you may have heard of a role called ScrumMaster. The ScrumMaster is the team’s coach and helps team members achieve their highest level of performance. A ScrumMaster differs from a project manager in many key ways, including that the ScrumMaster does not provide day-to-day direction to the team and does not assign tasks to individuals. A good ScrumMaster shelters the team from outside distractions, allowing team members to focus maniacally during the sprint on the goal they have selected.

While the ScrumMaster focuses on helping the team be the best that it can be, the product owner works to direct the team at the right goal. The product owner does this by creating a compelling vision of the product and then conveying that vision to the team through the product backlog.

The product owner is responsible for ensuring that the product backlog remains prioritized as more is learned about the system being built, its users, the team, and so on.

The third and final role on a Scrum project is the team itself. Although individuals on a Scrum team may come to that team with various job titles, while on the team those titles are insignificant. Each person contributes in whatever ways they best can to complete the work of each sprint. This does not mean that a tester will be expected to rearchitect the system; individuals will spend most (and sometimes all) of their time working in whatever discipline they worked before adopting Scrum. But on a Scrum team, individuals are expected to work beyond their preferred disciplines whenever doing so would be for the good of the team.

One convenient way to think of the interlocking nature of these three roles is as a race car. The team is the car itself, ready to speed along in whatever direction it is pointed. The product owner is the driver, making sure that the car is always going in the right direction. The ScrumMaster is the chief mechanic, keeping the car well-tuned and performing at its best.

http://xprogramming.com/xpmag/whatisxp

Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.

In Extreme Programming, every contributor to the project is an integral part of the “Whole Team“. The team forms around a business representative called “the Customer”, who sits with the team and works with them daily.

• Core Practices: Whole Team

Extreme Programming teams use a simple form of planning and tracking to decide what should be done next and to predict when the project will be done. Focused on business value, the team produces the software in a series of small fully-integrated releases that pass all the tests the Customer has defined.

• Core Practices: Planning Game, Small Releases, Customer Tests

Extreme Programmers work together in pairs and as a group, with simple design and obsessively tested code, improving the design continually to keep it always just right for the current needs.

• Core Practices: Simple Design, Pair Programming, Test-Driven Development, Design Improvement

The Extreme Programming team keeps the system integrated and running all the time. The programmers write all production code in pairs, and all work together all the time. They code in a consistent style so that everyone can understand and improve all the code as needed.

• Core Practices: Continuous Integration, Collective Code Ownership, Coding Standard

The Extreme Programming team shares a common and simple picture of what the system looks like. Everyone works at a pace that can be sustained indefinitely.

• Core Practices: Metaphor, Sustainable Pace

Chapter2 New Management Responsibilities

ScrumMaster

The ScrumMaster fills the position normally occupied by the project manager. I’ve taken the liberty of redefining this role. While the traditional project manager is responsible for defining and managing the work, the ScrumMaster is responsible for managing the Scrum process. To put it simply, ScrumMasters make Scrum work.

The Scrum process defines practices, meetings, artifacts, and terminology. The ScrumMaster is responsible for knowing these and knowing how to apply them correctly. Scrum can be applied incorrectly, as we will see. But because the ScrumMaster has a clear understanding of how Scrum works and has experience applying Scrum, the ScrumMaster knows how to guide a Scrum project through the shoals of complexity.

Like sheep in an open field, individuals in a project tend to stray. The ScrumMaster’s job is to keep the flock together. In fact, I often compare a ScrumMaster to a sheepdog, responsible for keeping the flock together and the wolves away.

Product Owner

The Product Owner’s focus is return on investment (ROI). The Product Backlog provides the Product Owner with a powerful tool for directing the project, Sprint by Sprint, to provide the greatest value and ROI to the organization. The Product Owner uses the Product Backlog to give the highest priority to the requirements that are of highest value to the business, to insert nonfunctional requirements that lead to opportunistic releases and implementations of functionality, and to constantly adjust the product in response to changing business conditions, including new competitive offerings.

Team

In a huge reversal of ordinary management practices, Scrum makes the team responsible for managing development activities. Traditionally, the project manager tells the team what to do and manages its work. In Scrum, however, the team selects the work that it will do during each Sprint. After that initial selection is made, it is up to the team to figure out how to do the work at hand. The team decides how to turn the selected requirements into an increment of potentially shippable product functionality. The team devises its own tasks and figures out who will do them.

The pressure inherent in a 30-day Sprint, the commitment the team members make to each other to accomplish something, and the principles of self- organization and cross-functional responsibilities all help the team successfully fulfill this responsibility. The team unfailingly rises to the occasion and manages itself. When anyone outside the team tries to tell the team what to do, more damage than good usually results. I don’t know why Scrum’s self-organization works so well, but that hardly matters. After all, I know of hundreds of successful Scrum projects encompassing thousands of successful Sprints.

Chapter 1:

There are three legs that hold up every implementation of empirical process control: visibility, inspection, and adaptation.

I've limited my enumeration of complexity in software development to the three most significant dimensions: requirements, technology, and people.

The skeleton operates this way: At the start of an iteration, the team reviews what it must do. It then selects what it believes it can turn into an increment of potentially shippable functionality by the end of the iteration. The team is then left alone to make its best effort for the rest of the iteration. At the end of the iteration, the team presents the increment of functionality it built so that the stakeholders can inspect the functionality and timely adaptations to the project can be made.

The heart of Scrum lies in the iteration. The team takes a look at the requirements, considers the available technology, and evaluates its own skills and capabilities. It then collectively determines how to build the functionality, modifying its approach daily as it encounters new complexities, difficulties, and surprises. The team figures out what needs to be done and selects the best way to do it. This creative process is the heart of the Scrum's productivity.

There are only three Scrum roles: the Product Owner, the Team, and the ScrumMaster.           "Ham and Eggs!"

1. Monthly Sprint planning meeting
2. Daily Scrum meeting
3. monthly Sprint review meeting
4. Sprint retrospective meeting

Tasks should be divided so that each takes roughly 4 to 16 hours to finish. Tasks longer than 4 to 16 hours are considered mere placeholders for tasks that haven't yet been appropriately defined.