Agile Methodology

5 min readJul 25, 2020

Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster. Instead of betting everything on a “big bang” launch, an agile team delivers work in small, but consumable, increments. It is a set of methods and practices where solutions evolve through collaboration between self-organizing, cross-functional teams. The team can manage a project by breaking it up into several stages and involving constant collaboration with stakeholders and continuous improvement and iteration at every stage.

1. Actors

Product Manager

· Works with customer to define product direction

· Creates product roadmap/ long vision

· True voice of the customer

· Discover user needs through research and insights

· Works closely with the strategic team

Product Owner

· Defines user story

· Prioritize backlog

· Maintain integrity of feature & components

· Communicates the voice of the customer

· Works closely with the technical team

Scrum Master

· Responsible for promoting & supporting scrum

· Servant leader of scrum

· Facilitate scrum events

With Product Owner

· Ensure goals, scopes are understood

· Find effective backlog

· Understand product backlog

· Re-prioritize suggestions of backlog to the maximum value

With Scrum team

· Coaching dev-team cross-functionally

· Helps to create high-value products

· Remove impediment

Scrum Team:

· Team members have different skillsets and cross-train each other so no one person becomes a bottleneck in the delivery of work. Strong scrum teams are self-organizing and approach their projects with a clear ‘we’ attitude. All members of the team help one another to ensure a successful sprint completion.

· The scrum team drives the plan for each sprint. They forecast how much work they believe they can complete over the iteration using their historical velocity as a guide. Keeping the iteration length fixed gives the development team important feedback on their estimation and delivery process, which in turn makes their forecasts increasingly accurate over time.

2. Requirement Artifacts: Non-Behavioral

a) Epic

· A big chunk of work with one common objective

· It could be a feature, customer request or business requirements

· Usually takes more than one sprint to complete

· The body of work that can be broken down into specific tasks (called user stories) based on the needs/requests of customers or end-users

General template

As a {Who}

I want {What}

So that {Why}

Additional Information

Priority: Must, Could, Should

Business context

Linked User-stories / epic

Example: An application to make online payment

b) User story

User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

General template

As a {Who}

I want {What}

So that {Why}

Additional Information

Priority: Must, Could, Should

Business context

Linked User-stories / epic

Example: (1) An application to make Debit card payment (2) An application to make credit card payment (3) An application to make payment with user points.

c) Acceptance Criteria

· The conditions that a product to meet/accepted by a user, a customer, or other systems.

· Its unique for each user story and define the feature behaviour from the end user's perspective.

· Well-written acceptance criteria will avoid unexpected results at the end of a development stage and ensure that all stakeholders & users are satisfied with what they get.

· It can be scenario oriented, rule-oriented (checklists) or custom formats.

General template

Given {a context}

When {an event}

Then {an outcome}

Purpose

· To define the boundaries of user stories

· To define these negative/exception scenarios and explain how the system should react to it

· To synchronize the visions of the client and the development team. It ensures that everyone has a common understanding of the requirements. Developers know exactly what kind of behaviour the feature must demonstrate, while stakeholders and the client understand what’s expected from the feature.

Example: (1) An application to make payment with invalid Debit card. (2) An application to make an online payment with given bank options

d) Requirement Traceability Matrix

· It creates traceable relationships between the requirements and all other project development artefacts included in the development process, from requirements to defects.

· An ability to describe and follow the life of a requirement, in both forwards, backwards direction and helpful for faster Analysis

Purpose

Ensure the product was successfully built: It enables all requirements changes to be tracked and traced, and it helps to monitor defects quickly.

For developers: RTM enables them to see defect rates for all system components and identify the problem areas.

For architects: In the design phase, the team can keep track of what happens when changes are implemented before a system has been completely redesigned.

For testers: It will reveal any missed or incorrect requirements, and it gives business analysts the ability to easily identify the requirements that need updating.

For Managers: To estimate efforts where requirements changes are needed. They can easily see test coverage, test assignments, and test execution statuses for a project.