Scrum is an Agile framework for software project management. Scrum defines a set of roles, artifacts, and practices.

Roles

• ScrumMaster: Responsible for facilitating the Scrum process. Directs meetings, enforces rules, keeps team focused, manages artifacts.
• Product Owner: Represents the stakeholders and the business. Articulates their needs.
• Team: Responsible for delivering the product. A cross-functional group that does the analysis, design, coding, testing, communication and documentation.

Artifacts

• User Story: A description of a feature to be implemented, and the acceptance testing criteria for that feature. Typically written by the Product Owner.
• Technical Story: A description of technical work that must to done to support the product. Typically written by the Team.
• Product Backlog: The collection of all stories that have not been completed.
• Sprint Backlog: The collection of stories to be completed in the current Sprint.
• Burndown: A chart that displays remaining work to be done versus time. It is intended to give everyone insight into the progress of the project.

Practices

• Sprint: The period of development, typically lasting 2 to 4 weeks. Scrum uses the term “Sprint” for the Agile concept of “iteration”.
• Sprint Planning Meeting: Prior to the start of the Sprint, this meeting is held to determine which stories from the Product Backlog will be entered into the Sprint Backlog. The Product Owner will prioritize the stories, and the Team will plan the Sprint.
• Daily Scrum: A 15-minute daily meeting for the Team, where each team member describes: what they did yesterday, what they are doing today, and any roadblocks encountered.
• Scrum of Scrums: Used when teams are not co-located. A representative from each team will attend this meeting that occurs after the Daily Scrum.
• Sprint Review Meeting: Review the work that was completed and not completed. Present (demo) the completed work to the stakeholders; incomplete work is not presented.
• Sprint Retrospective: Reflect on the last Sprint, in order to improve the process. Questions to ask: What what well in the last Sprint? What could be done better in the next Sprint?

The Agile Model of Software Development evolved to address the problems that were encountered with teams using the Waterfall Method. The primary problem with Waterfall is that it makes the assumption that every requirement and function can be captured on paper at the beginning of the project. Changes to the software requirements specification after sign-off are costly, especially if the project is well into the development phase. Anyone familiar with the phrase “I’ll Know It When I See It” can understand that a customer is likely to want to change how the software looks or functions after they have had a chance to interact with the software. The Agile solution to this problem is Iterative and Incremental Development (IID).

IID breaks down the development process into short iterations, where each iteration touches all the phases of the software development process: requirements are gathered, architecture and design decisions are made, code and tests are written. At the end of the iteration the customer is able to interact with functional code. By allowing the customer to prioritize the work that is done in each iteration, small increments of functional code are produced according to the customer’s business needs. Iterations are thus able to accelerate the delivery of initial business value; through continuous planning and feedback, that value can be maximized throughout the development process. In a typical Agile project the iterations will last from 2 to 4 weeks, and the number of iterations will be the project length divided by the iteration length.

Although incremental software development methods had been in use for years, Agile became formally described in early 2001 in the Manifesto for Agile Software Development Link. The Manifesto reads:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The following Principles Link underlie the Agile Manifesto.

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Agile is a conceptual framework for lightweight software development. While there are a number of software development methodologies that use Agile methods, two of the most popular are Scrum and Extreme Programming (XP).