Agile methodology

The Agile model was primarily designed to help a project to adapt to change requests quickly. So, the main aim of the Agile model is to facilitate quick project completion. To accomplish this task agility is required. Agility is achieved by fitting the process to the project, and removing activities that may not be essential for a specific project. Also, anything that is waste of time and effort is avoided. 

Actually Agile model refers to a group of development processes. These processes share some basic characteristics but do have certain subtle differences among themselves. A few Agile SDLC models are given below: 

  • Crystal
  • Atern
  • Feature-driven development
  • Scrum
  • Extreme programming (XP)
  • Lean development
  • Unified process

In the Agile model, the requirements are decomposed into many small parts that can be incrementally developed. The Agile model adopts Iterative development. Each incremental part is developed over an iteration. Each iteration is intended to be small and easily manageable and can be completed within a couple of weeks only. At a time one iteration is planned, developed, and deployed to the customers. Long-term plans are not made. 

Agile model is the combination of iterative and incremental process models. The steps involve in agile SDLC models are: 

  • Requirement gathering
  • Requirement Analysis
  • Design
  • Coding
  • Unit testing
  • Acceptance testing

The time to complete an iteration is known as a Time Box. Time-box refers to the maximum amount of time needed to deliver an iteration to customers. So, the end date for an iteration does not change. Though the development team can decide to reduce the delivered functionality during a Time-box if necessary to deliver it on time. The central principle of the Agile model is the delivery of an increment to the customer after each Time-box. 

Principles of Agile model: 

  • To establish close contact with the customer during development and to gain a clear understanding of various requirements, each Agile project usually includes a customer representative on the team. At the end of each iteration stakeholders and the customer representative review, the progress made and re-evaluate the requirements.
  • Agile model relies on working software deployment rather than comprehensive documentation.
  • Frequent delivery of incremental versions of the software to the customer representative in intervals of a few weeks.
  • Requirement change requests from the customer are encouraged and efficiently incorporated.
  • It emphasizes having efficient team members and enhancing communication among them is given more importance. It is realized that enhanced communication among the development team members can be achieved through face-to-face communication rather than through the exchange of formal documents.
  • It is recommended that the development team size should be kept small (5 to 9 people) to help the team members meaningfully engage in face-to-face communication and have a collaborative work environment.
  • Agile development process usually deploys Pair Programming. In Pair programming, two programmers work together at one work-station. One does coding while the other reviews the code as it is typed in. The two programmers switch their roles every hour or so.


  • Working through Pair programming produce well written compact programs which have fewer errors as compared to programmers working alone.
  • It reduces total development time of the whole project.
  • Customer representatives get the idea of updated software products after each iteration. So, it is easy for him to change any requirement if needed.


  • Due to lack of formal documents, it creates confusion and important decisions taken during different phases can be misinterpreted at any time by different team members.
  • Due to the absence of proper documentation, when the project completes and the developers are assigned to another project, maintenance of the developed project can become a problem.

Agile Tools and Techniques

Using agile tools and techniques can help to:

  • Self-organize and plan
  • Communicate (within the team and with the rest of your organization)
  • Continuously improve the way you work
  • Get support from management

Agile teams may also adopt unique combinations of techniques to support their framework and methodology. Examples:

  • Collocation
  • Dedicated teams
  • Relative estimating
  • User stories
  • Velocity
  • Burndown charts
  • Definition of done

A few techniques typically used on agile projects that directly contribute to accelerating the time to delivery and the increased quality of the product being delivered include:

  • Frequent inspection of the product and adaptation to the changes and input during the project
  • Aligning development with customer needs and organizational goals
  • Colocation of resources to the same workspace
  • Self-organization and accountability
  • Becoming a team player
  • Elimination of “waste” and “ceremony”
  • Empirical demonstration of results
  • Customer is always present
  • Focus on key planning events: product planning, release/feature planning, iteration planning, sprint review, and stand-ups

1. Scrum

Scrum is an empirical exposure model, in that knowledge is gained from real-life experience, and decisions are made based on that experience. Through transparency, inspection and adaptation, using Scrum is a a good way to demonstrate whether your project is generating the intended results.

When following Scrum, teams focus on what can be done ‘today’ and break future work into manageable pieces. There is more immediate feedback as to how well your development methodology is working, and when issues arise, Scrum allows for immediate action by making adjustments with clarity and speed. Scrum works to:

  • Clearly define roles
  • Organize your work in actionable chunks
  • Enable effective prioritizing
  • Allow for efficiencies in completing work

2. Artifacts

 Three key sprints artifacts are the product backlog, sprint backlog, and the shippable product implement

Product Backlog

The product backlog is the master to-do list for a project. It is an ordered list, prioritized by business value and risk. It is a dynamic artifact and changes as the Scrum team gains additional knowledge regarding the requirements and solutions they are developing. 

Sprint Backlog

The sprint backlog is also created at the beginning of each sprint and is the to-do list of tasks necessary to achieve the sprint goal. The sprint backlog generally includes a sprint goal and the sprint end date, a prioritized list of requirements, estimated effort for each item, tasks required for each requirement, estimated hours for each task, and a burndown chart displaying the status of work being performed throughout the sprint. 

Shippable Product Increment

At the end of every sprint, the development team delivers working, tested, and integrated functionality to stakeholders and customers to review. The development team reviews each requirement with the product owner as soon as it is completed, and the requirements that comprise the increment are only considered complete if the product owner accepts them. The product increment is what the development team demonstrates to stakeholders in the sprint review.

3. Events

Agile development cycles are iterative, and are often referred to as ‘iterations’. A sprint is a time-boxed iteration. The length of a sprint or iteration can vary by Scrum team, and project, however the shorter the sprint, the more frequently a Scrum team receives feedback to inspect and adapt both their product and processes. Each Sprint contains four key events:

  • Spring Planning
  • Daily Scrum or Standup
  • Spring Review
  • Sprint Retrospective

Sprint Planning

Sprint planning meetings are a feature of Scrum and should be held at the start of each sprint. At a sprint planning meeting, the team decides what to work on next and how they will do it. The length of the meeting will depend on how long your sprint is. Sprint planning is the process of establishing a sprint goal and selecting product backlog items supporting the sprint goal that can be completed within the designated sprint timeframe.

Daily Scrum or Standup

The daily scrum or standup should be scheduled for the same time each day and be relatively brief. Depending on the scale of the project a 15 or 30 minute duration can suffice. It is recommended that the meeting occurs in front of your team wall.

Meeting together once a day to discuss what each team member is working on and whether they have any problems or dependencies that need to be resolved is helpful to keep the project moving forward smoothly. Additionally, this meeting should be used to coordinate how to accomplish the work for that single day, or if a team member needs help from someone else.

Sprint Review

Each sprint closes with a sprint review. This allows the product owner to verify that the Scrum team is developing what the customer wants. The product owner presents the sprint goal and status to the stakeholders.

The development team members then demonstrate working functionality and the product owner collects feedback from the stakeholders. The product owner then updates the product backlog, based on this feedback and cross-references the current state of the project with the overall roadmap, and communicates what is planned for the next sprint.

4. Retrospective Meetings

The sprint retrospective, sometimes also referred to as a ‘retro,’ provides the Scrum team with the opportunity to inspect and adapt its processes, environment, tools, communications, and impediments in order to make improvements.

Scrum teams typically utilize this time to validate what is working well in addition to identifying any practices that may not be working. Concerns are addressed, and the Scrum team identifies any changes that should be implemented as a result. Action plans for adopting those changes are developed and added to the product backlog to be implemented in a future sprint.

Retrospectives should have an open atmosphere where every member of the team can speak honestly and feel confident that their colleagues will listen.

5. Team Review (show and tell)

The team review is a regularly scheduled meeting which gives team members the opportunity to demonstrate their work. It is also referred to as a sprint review or a show and tell. You may want to invite stakeholders such as directors or suppliers to this meeting and use it to tell them about the user stories that have been completed or other work which has been done. 

If your project is part of a larger organization or program you may want to open up your review to the rest of the organization every few weeks. This gives you the opportunity to show the most important work you’ve done, talk about what you’ve learned, explain your plans for the next few weeks, and answer questions. It also gives other teams the chance to see how your work relates to theirs.

User Stories

User stories are a way for your team to briefly record the things you need to do to build the product. You can use them to prompt discussions about features when you’re ready to start working on them.

The Backlog

A product backlog is used to store the user stories that haven’t yet been started. It is recommended that the user stories are ordered based on priority. If you are following Scrum you should also use a sprint backlog to manage the stories that the team has agreed to work on during a sprint.

Team Walls

Your team wall is an important tool that helps to track and manage the workload. The wall shows what your team has done, what they’re currently doing, and remaining work. Having a team wall helps your team to collaborate and allows other people in the organization to see what you’re doing.