Agile Development Methodologies

Agile Development Methodologies

What is Agile Development

Agile methodologies are an alternative to waterfall or traditional software development practices. Agile methodologies usually have the following characteristics in common: they are iterative, collaborative, and they are built around self organizing teams.

The Agile Manifesto

In February 2001, seventeen software developers met at the Snowbird resort in Utah to discuss lightweight development methods. They published the Manifesto for Agile Software Development:

“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 10 Principles of the Agile Manifesto

The Agile Manifesto is based on ten principles[1]:

  1. Customer satisfaction by early and continuous delivery of valuable software.
  2. Welcome changing requirements, even in late development.
  3. Working software is delivered frequently (weeks rather than months).
  4. Close, daily cooperation between business people and developers.
  5. Projects are built around motivated individuals, who should be trusted.
  6. Face-to-face conversation is the best form of communication (co-location).
  7. Working software is the principal measure of progress.
  8. Sustainable development, able to maintain a constant pace.
  9. Continuous attention to technical excellence and good design.
  10. Simplicity—the art of maximizing the amount of work not done—is essential.

Read entire article at

Scrum Terminology

Scrum Glossary of Terms


an iterative and incremental agile software development methodology for managing product development.

Scrum Roles

There are three main roles in any scrum project:

  1. Product Owner
  2. ScrumMaster
  3. Team Member

User stories

Something a user wants, and is a self contained unit of work. Stories are the building blocks of a sprint. They are short, simple descriptions of a feature told from the perspective of the person who desires the new functionality.

user story template:

As a <type of user> I <want/can/am able to/ need to,etc.> so that <some reason>

User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.

Epic – Big user story. Usually need to be broken down into separate user stories.

Theme – A collection of user stories that fall under the same category.


An iteration of work during certain product functionality is implemented based on the sprint backlog. Sprints usually last 4 weeks, but can be adjusted depending on the situation.

The sprint starts with a one-day sprint planning meeting. Many daily Scrum meetings (15 minute / stand up) occur during the sprint (one per day). A sprint review meeting is held at the end of the sprint  followed by a sprint retrospective meeting.

During the sprint, the team must not be interrupted with additional requests. Guaranteeing the team won’t be interrupted allows it to make real commitments it can be expected to keep.

Out of practical necessity, some teams choose to bend this rule by declaring some team members 80 percent available at the outset so they still have some cycles left for “Priority One” bugs and emergencies.

Sprint Backlog

The sprint backlog a list of tasks identified by the Scrum team to be completed during the sprint. They are usually in the form of user stories and they are chosen from the product backlog item.

Contents of the sprint backlog:

1. tasks (decomposed from user stories that were accepted by the team for the current sprint).

2. Story points or time estimates for individual tasks.

3. Refinements or “definition of done” as it relates to a specific story or task.

4. In-sprint stories or goals added by the team to support the current sprint goal.


Product Backlog

The product backlog (or “backlog”) is the requirements for a system, expressed as a prioritized list of product backlog Items composed of user stories. The product backlog is managed and prioritized by the product owner.

During a Sprint planning meeting, backlog items are moved from the product backlog into a sprint, based on the product owner’s priorities.

The product backlog is usually composed of the following kinds of items:
1. features
2. bugs
3. technical work
4. knowledge acquisition

A product backlog item  is a unit of work small enough to be completed by a team in one Sprint iteration. Backlog items are decomposed into one or more tasks.

Daily Scrum Meeting

A fifteen-minute daily meeting for each team member to answer three questions:

  1. “What have I done since the last Scrum meeting? (i.e. yesterday)”
  2. “What will I do before the next Scrum meeting? (i.e. today)”
  3. “What prevents me from performing my work as efficiently as possible?”

The ScrumMaster ensures that participants call sidebar meetings for any discussions that go too far outside these constraints.

– See more at:

Burndown Charts

Burndown charts show the remaining work over time. Work remaining is the Y axis and time is the X axis.

sprint burndown chart is where you look at daily progress and the product burndown chart is where you look for monthly (per sprint) progress.

Scrum Reference