Agile Methodology - Quick Guides

Agile Methodology Study Notes

Agile is a software development methodology to develop a software incrementally utilizing short iterations of 1 week to 1 month so that the development is lined up with the changing business needs. This simple study notes utilizes suitable examples to help you understand agile development in a general and quick way.


This study notes has been prepared for beginners to help them understand the basics of Agile principles and its execution. After completing this study notes, you will find yourself at a moderate level of expertise, from where you can progress further.


Before proceeding with this study notes, you need a fundamental knowledge of software development concepts such as software requirements, coding, testing, etc.

Agile Methodology - Primer

Agile is a software development methodology to develop a software incrementally utilizing short iterations of 1 week to 1 month so that the development process is lined up with the changing business needs. Rather than a single-pass development of 6 to 18 months where all the prerequisites and risks are predicted upfront, Agile adopts a procedure of frequent feedback where a workable product is delivered after 1 week to 1 month iteration.


Roles in Agile

Scrum Master

A Scrum Master is a team leader and facilitator who helps the colleagues to follow agile practices so that they can meet their responsibilities. The responsibilities of a scrum master are as per the following −

  • To empower close co-operation between all roles and functions.

  • To remove any blocks.

  • To shield the team from any influences.

  • To work with the organization to track the development progress and processes of the company.

  • To ensure that Agile Inspect & Adapt processes are utilized properly which includes

    • Day by day stand-ups,
    • Planned meetings,
    • Demo,
    • Audit,
    • Review Meetings, and
    • To facilitate team meetings and decision-making procedure.

Product Owner

A Product Owner is the person who drives the product from business perspective. The responsibilities or a Product Owner are as per the following −

  • To define the requirements and organize their values.
  • To decide the release date and contents.
  • To play an active role in iteration planning and release planning meetings.
  • To ensure that team is working on the most esteemed requirement.
  • To represent the voice of the client.
  • To accept the user stories that meet the meaning of done and defined acknowledgment criteria.

Cross-functional Team

Every agile team should be a independent team with 5 to 9 colleagues and an average experience ranging from of 6 to 10 years. Normally, an agile team comprises of 3 to 4 developers, 1 tester, 1 technical lead, 1 product owner and 1 scrum master.


Product Owner and Scrum master are considered to be a part of Team Interface, though other members are part of Technical Interface.

How an Agile Team Plans its Work?

An Agile team works in iterations to deliver user stories where every iteration is of 10 to 15 days. Each user story is planned based on its backlog prioritization and size. The team utilizes its ability − how many hours are available with team to work on tasks − to decide how much scope they have to plan.



A Point characterizes how much a team can commit. A point usually refers to 8 hours. Each story is estimated in points.

Limit characterizes how much an individual can submit. Limit is assessed in hours.


Capacity defines how much an individual can commit. Capacity is estimated in hours.

What is a User Story?

A user story is a prerequisite which characterizes what is required by the user as functionality. A user story can be in two structures −

  • As a <User Role> I want <Functionality> so that <Business Value>
  • In order to <Business value> as a <User Role> I want <Functionality>

During release planning, a rough estimate is given to a user story utilizing relative scale as points. During iteration planning, the story is separated into tasks.

Relationship of User Stories and Tasks

  • User story talks about what is to be done. It characterizes what a user needs.
  • Task talks about how it is to be done. It defines how a functionality is to be executed.
  • Stories are executed by tasks. Each story is a assortment of tasks.
  • User story is separated into tasks when it is planned in current iteration.
  • Tasks are estimated in hours, generally from 2 to 12 hours.
  • Stories are validated using acceptance tests.


When a Story is Done

The team decides what done means. The criteria may be −

  • All tasks (development, testing) are finished.
  • All acceptance tests are running and are passed.
  • No defect is open.
  • Product owner has accepted the story.
  • Deliverable to the end-user.

What is Acceptance Criteria?

Criteria defines the functionality, conduct, and performance required by a feature so that it can be accepted by the product owner. It characterizes what is to be done so that the developer knows when a user story is complete.

How the Requirements are Defined?

Requirements are defined as

  • A User Story,
  • With Acceptance Criteria, and
  • Tasks to execute the story.

Agile Methodology - Manifesto

In February 2001, at the Snowbird resort in Utah, 17 software engineers met to discuss lightweight development methods. The result of their meeting was the following Agile Manifesto for software development −

We are uncovering better methods of developing software by doing it and helping other people do it. Through this work, we have come to value −

  • Individuals and interactions over Processes and tools
  • Working software over Comprehensive documentation
  • Client 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.

Twelve Principles of Agile Manifesto

  • Customer Satisfaction − Highest priority is given to fulfill the requirements of clients through early and consistent delivery of valuable software.

  • Welcome Change − Changes are inescapable during software development. Ever-changing requirements should be welcome, even late in the development stage. Agile processes should work to increase clients' competitive advantage.

  • Deliver a Working Software − Deliver a working software frequently, ranging from a few weeks to a few months, considering shorter time-scale.

  • Collaboration − Business people and engineers must work together during the whole life of a project.

  • Motivation − Projects should be built around motivated people. Provide an environment to support individual colleagues and trust them so as to make them feel responsible to get the job done.

  • Face-to-face Conversation − Face-to-face conversation is the most proficient and effective way of conveying information to and within a development team.

  • Measure the Progress as per the Working Software − Working software is the key and it ought to be the primary measure of progress.

  • Maintain Constant Pace − Agile processes aim towards sustainable development. The business, the engineers, and the users should be able to maintain a consistent pace with the project.

  • Monitoring − Pay regular attention to technical excellence and good design to upgrade agility.

  • Simplicity − Keep things basic and use basic terms to measure the work that isn't finished.

  • Self-organized Teams − An agile team should be self-organized and should not depend heavily on different teams because the best architectures, prerequisites, and designs emerge from self-organized teams.

  • Review the Work Regularly − Review the work done at regular intervals so that the team can reflect on how to become more effective and adjust its conduct accordingly.

Agile Methodology - Characteristics

Iterative/incremental and Ready to Evolve

Most of the agile development methods break an issue into smaller tasks. There is no immediate long-term planning for any requirement. Ordinarily, cycles are planned which are of vary short period of time, for example, 1 to 4 weeks. A cross-functional team is made for each cycle that works in all functions of software development like planning, requirements analysis, design, coding, unit testing, and acceptance testing. The result at the finish of the cycle is a working product and it is demonstrated to the stakeholders at the finish of an iteration.

After demo, review comments are taken and are planned to be incorporated in the working software as required.


Face-to-face Communication

Each agile team should have a client representative such as a product owner in scrum methodology. This representative is authorized to act on behalf of the stakeholders and he can answer the questions of the developers in between iterations.

An information radiator (physical display) is normally located prominently in an office, where passers-by can see the improvement of the agile team. This information radiator shows an up-to-date summary of the status of a project.

Feedback Loop

Daily stand-up is a common culture of any agile development; it is also known as daily scrum. It is a sort of a brief session where each team member reports to each other regarding the status of what they have done, what to do next, and any problems they are facing.

Agile Methodology - Daily Stand-Up

Day by day stand-up, as the name recommends, is a daily status meeting among all the members of an agile team. It not only gives a discussion for regular updates but also brings the problems of colleagues into focus so that it can be quickly addressed. Daily stand-up is a must-do practice, no matter how an agile team is established regardless of its office location.

What is Daily Stand-up?

  • A daily stand-up is a day by day status meeting among all colleagues and it is held generally for 15 minutes.

  • Every member has to respond three important questions −

    • What I did yesterday?
    • What I'll do today?
    • Any impediment I am facing.../ I am blocked due to...
  • Daily stand-up is for status update, not for any conversation. For conversation, colleagues should schedule another meeting at a different time.

  • Participants usually stand instead of sitting so that the meeting gets over rapidly.

Why Stand-up is Important?

The benefits of having a daily stand-up in agile are as per the following −

  • The team can evaluate the progress every day and see if they can deliver aaccording to the iteration plan.
  • Each colleague informs all about his/ her responsibilities for the day.
  • It provides visibility to the team on any postponement or obstacles.

Who Attends a Stand-up?

  • The scrum master, the product owner, and the delivery team should attend the stand-up regularly.

  • Stakeholders and clients are encouraged to attend the meeting and they can act as an observer, but they are not supposed to participate in stand-ups.

  • It is the scrum master's responsibility to take note of each colleague's questions and the issues they are facing.

Geographically Dispersed Teams

Stand-ups can be done in multiple ways, in case the agile team members are operating from various time zones −

  • Select a member on a rotational basis, who can attend the stand-up meeting of teams located in various time zones.

  • Have a separate stand-up per team, update the status of the stand-up in a tool such as Rally, SharePoint, Wikis and so on.

  • Have a wide variety of communication tools ready like conference call, video conferencing, instant messengers, or any other third-party information sharing tools.

Agile Methodology - Definition Of Done

The meaning of done for User Story, Iteration, and Release is given below.

User Story

A user story is a requirement which is planned in a few sentences in regular language of an user and it should be finished within an iteration. A user story is done when

  • All the related code have been checked-in.
  • All the unit test cases have been passed.
  • All the acceptance test cases have been passed.
  • Help text is written.
  • Product Owner has acknowledged the story.


An iteration is a time boxed collection of user stories / defects to be worked upon and accepted within the release of a product. Iterations are characterized during iteration planning meeting and finished with an iteration demo and review meeting. An iteration is also termed as a sprint. An iteration is done when

  • Product backup is complete.
  • Performance has been tested.
  • User stories have been accepted or moved to the next iteration.
  • Bugs have been fixed or postponed to the next iteration.


A release is a major achievement that represents an internal or external delivery of working, tested version of the product/system. A release is done when

  • System is stress tested.
  • Performance is tuned.
  • Security validations are completed.
  • Disaster recovery plan is tested.

Agile Methodology - Release Planning

The reason of release planning is to create a plan to deliver an augmentation to the product. It is done after every 2 to 3 months.


Who is Involved?

  • Scrum Master − The scrum master acts as a facilitator for the agile delivery team.

  • Product Owner − The product owner represents the overall perspective of the product backlog.

  • Agile Team − Agile delivery team gives insights on the technical feasibilities or any dependencies.

  • Stakeholders − Stakeholders like clients, program managers, subject matter experts act as advisers as decisions are made around the release planning.

Requirements of Planning

The requirements of release planning are as per the following −

  • A ranked product backlog, managed by the Product Owner. Generally five to ten features are taken which the product owner feels that can be included in a release

  • Team's input about capacities, known velocity or about any technical challenge

  • High-level vision

  • Market and Business objective

  • Acknowledgement whether new product backlog items are required

Materials Required

The list of materials required for release planning is as per the following −

  • Posted agenda, reason
  • Flip diagrams, whiteboards, markers
  • Projector, way to share PCs having information/tools required during planning meeting
  • Planning data

Planning Data

The list of data required to do release planning is as per the following −

  • Past iterations or release planning results
  • Feedback from different stakeholders on product, economic situations, and deadlines
  • Action plans of past releases / iterations
  • Highlights or defects to be considered
  • Velocity from past releases/ estimates.
  • Organizational and individual calendars
  • Inputs from different teams and subject matter experts to manage any dependencies


The output of a release planning can be the following −

  • Release plan
  • Responsibility
  • Issues, concerns, dependencies, and assumptions which are to be checked
  • Proposals to improve future release plannings


The agenda of a release planning can be −

  • Opening ceremony − Welcome message, review purpose and plan, organizing tools and introduction to business sponsors.

  • Product Vision, Roadmap − Show the large image of the product.

  • Review past releases − Discussion on any item which can affect the plan.

  • Release name/theme − Inspect the current status of roadmap themes and do the necessary changes, if any.

  • Velocity − Present the velocity for the current release and of past releases.

  • Release schedule − Review key milestones and decision on time boxes for release and iterations within release.

  • Issues and concerns − Check any concerns or issue and record them.

  • Review and Update the Definition of Done − Review the definition of done and roll out appropriate changes based on technology, skill, or changes in colleagues since the last iteration / release.

  • Stories and items to be considered − Present the user stories and highlights from the product backlog to be considered for scheduling in the current release.

  • Determine sizing values − If the velocity is unknown, then plan the sizing values to be utilized in the release planning.

  • Coarse the size of stories − The delivery team determines the appropriate size of the stories under consideration and splits the stories into multiple iterations if a story is excessively large. The product owner and the subject matter experts clarify the doubts, elaborate the acknowledgment criteria, and make proper story splits. The scrum master encourages the collaboration.

  • Map stories to iterations − The delivery team and the product owner move the stories/defects in the iterations based on the size and velocity. The scrum master encourages the collaboration.

  • New concerns or issues − Check any new issues based on past experience and record the same.

  • Dependencies and assumptions − Check any dependencies/assumptions arranged during the release planning.

  • Commit − The scrum master calls for the planning. Delivery team and Product owner signal it as the best plan and then commit to move to the next level of planning, that is, iteration planning.

  • Communication and logistics planning − Review/Update the communication and logistics planning for the release.

  • Parking lot − Process parking lot means all items should be either resolved or set as things to do.

  • Distribute Action items and action plans − Distribute the action items among their owners, process the action plan.

  • Retrospect − Solicit feedback from members to make the meeting effective.

  • Close − Celebrate the achievement.

Agile Methodology - Iteration Planning

The reason of iteration planning is for the team to finish the set of top-ranked product backlog items. This commitment is time boxed based on the length of iteration and team velocity.


Who is Involved?

  • Scrum Master − The scrum master acts as a facilitator for the agile delivery team.

  • Product Owner − The product owner deals with the detailed view of the product backlog and their acknowledgment criteria.

  • Agile Team − Agile delivery characterizes their assignments and sets the effort estimates required to satisfy the dedication.

Prerequisites of Planning

  • Items in product backlog are estimated and have a relative story point assigned.
  • Ranking has been given to portfolio items by the product owner.
  • Acknowledgment standards has been clearly expressed for each portfolio item.

Planning Process

Following are the steps associated in iteration planning −

  • Break how many stories can fit in an iteration.
  • Break these stories into tasks and assign each task to their owners.
  • Each assessments is given estimates in hours.
  • These estimates help team members to check how many task hours each member have for the iteration.
  • Colleagues are assigned tasks considering their velocity or capacity so that they are not overburdened.

Velocity Calculation

An agile team calculates velocity dependent on past iterations. Velocity is an average number of units required to complete user stories in an iteration. For example, if a team took 12, 14, 10 story points in each iteration for the last three iterations, the team can take 12 as velocity for the next iteration.

Planned velocity tells the team how many user stories can be finished in the current iteration. If the team quickly finishes the tasks assigned, then more user stories can be pulled in. Otherwise, stories can be moved out too to the following iteration.

Task Capacity

The capacity of a team is derived from the following three facts −

  • Number of perfect working hours in a day
  • Available days of person in the iteration
  • Percentage of time a member is exclusively available for the team.

Suppose a team has 5 members, committed to work full time (8 hours a day) on a project and no one is on leave during an iteration, then the task capacity for a two-week iteration will be −

5 × 8 × 10 = 400 hours

Planning Steps

  • Product Owner depicts the highest ranked item of product backlog.
  • Team describes the undertakings required to complete the item.
  • Team members own the tasks.
  • Team members estimate the time to complete each task.
  • These steps are repeated for all the items in the iteration.
  • If any individual is overloaded with tasks, then his/her task is distributed among other colleagues.

Agile Methodology - Product Backlog

A product backlog is a list of items to be finished. Items are positioned with highlight descriptions. In an perfect situation, items should be separated into user stories.

Why Product Backlog is Important?

  • It is prepared so that goal can be given to each and every feature.
  • It helps in planning the roadmap for the product.
  • It helps in re-ranking the highlights so that more value can be added to the product.
  • It encourages in determining what to prioritize first. Team ranks the item and then builds value.

Characteristics of Product Backlog

  • Each product should have one product backlog which can have a set of large to very large highlights.

  • Multiple teams can work on a single product backlog.

  • Ranking of features is done dependent on business esteem, technical value, risk management or strategic fitness.

  • Highest ranking items are decomposed into smaller stories during release planning so that they can be finished in future iterations.

Agile Methodology - Useful Terms

Acceptance Criteria

It is the conditions set by the product owner or the client in order to accept a component to be valid and adhering to their requirements.

Backlog Grooming

It is a continuous procedure in which the product manager or the client manages the product backlog by getting feedback from agile teams. This process includes organizing the portfolio items, breaking them in smaller items, planning them for future iterations, creating new stories, updating acceptance criteria or elaborating acceptance criteria in details.


It is the amount of work a team can take to finish in one iteration.


An improvement done to a product or ability of value to stakeholder which can be created in a release.


A theme-based work item that can be finished within a time box and accepted within the release of a product. Iteration work is defined during iteration planning and it finishes with demo and review meeting. It is also named as Sprint.


An increment is the changing state of a product as it undergoes gradual development. It is typically represented by achievements or number of fixed iterations.

Product Owner

The product owner is a member of the Agile delivery team, responsible to gather and rank business requirements in the product backlog. A product owner conveys what is to be done in a release/iteration. He/she sets the responsibilities and is responsible to protect team from any change in requirements during an iteration.

Product Backlog

Set of functional and non-functional product requirements.

Product Backlog Items

May be user stories, defects, features which are to be created by the agile team.


A common unit used to set the relative size of user stories, features, or any other portfolio items.


A time box where work is done to help delivery of testable increment to a software. In scrum, a release consists of various iterations.


A specification of a software product to satisfy a stated contract or functionality. User stories and portfolio items are kinds of requirements.

A particular of a product item to fulfill an expressed agreement or usefulness. Client stories and portfolio things are kinds of necessities.

Story Points

A unit used by the agile team to appraise relative sizes of user stories and highlights.


Same as Iteration.


A fixed duration of time in which a deliverable is to be developed. Typically, along with fixing start and end date of a timebox, the number of assets is also fixed.


It is a unit of work that contributes towards the completion of a user story within an iteration. User stories are decomposed into multiple tasks and each task can be divided between team members marking them as owner of the tasks. Team members can take responsibility of each task, update estimates, log work done or to-do as desired.

It is a unit of work that contributes towards the fulfillment of a client story inside an emphasis. Client stories are disintegrated into numerous errands and each assignment can be isolated between colleagues checking them as proprietor of the undertakings. Colleagues can assume liability of each undertaking, update gauges, log work done or to-do as wanted.

User Story

A listed acceptance criteria to fulfil certain prerequisites of a user. It is normally written from the perspective of an end-user.


A measure to weight the accepted work in an iteration or timebox. Ordinarily it is the sum of story points accepted in an iteration.

Input your Topic Name and press Enter.