Agile Structures and Frameworks

CDV2001

Module 4

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Agile Product Development: Concepts & Lifecycle

• Agile product development focuses on creating customer value through iterative, feedback-driven progress rather
than strict adherence to predefined plans.
• It emphasizes collaboration, adaptability, and continuous delivery — ensuring the product evolves in response to
real-world feedback and business priorities.

1. Concept of Agile Product Development

Agile product development is not just about coding faster — it’s about building the right product by continuously
validating assumptions and learning from users.
Instead of treating development as a one-time delivery, Agile treats it as an evolutionary process of discovery and
delivery.

Core Idea
“The purpose of Agile development is to deliver value early, get feedback, and adapt — not to blindly follow a plan.”
— Robert C. Martin (Uncle Bob)

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Traditional Development Agile Product Development
Plan everything upfront Adapt continuously based on learning
Deliver product at end Deliver working increments frequently
Fixed scope and timeline Flexible scope, prioritized by value
Customer involved at start/end Customer involved throughout

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

2. The Agile Product Development Lifecycle
Agile product development progresses through iterative cycles, where each iteration adds new features or improvements
guided by user feedback.

Phases in Agile Product Development Lifecycle

Phase Purpose Key Activities Artifacts / Outputs

Define the purpose, goals, and Identify stakeholders, business Vision Statement, Product
1. Product Vision
business value of the product. objectives, success metrics. Charter

Outline major milestones and Prioritize features by value and

2. Product Roadmap Product Roadmap
high-level goals over time. risk.

Plan which features will be Group product backlog items

3. Release Planning Release Plan
included in upcoming releases. into meaningful releases.
Plan specific features for next Define sprint goal and user
4. Iteration (Sprint) Planning Sprint Backlog
sprint. stories to deliver.
Build, test, and deliver working Implement features, run tests,
5. Development & Delivery Working Software Increment
increments of the product. demo to stakeholders.

Gather insights from users and Conduct sprint reviews and

6. Feedback & Adaptation Updated Product Backlog
metrics to refine backlog. retrospectives.
PRESIDENCY UNIVERISTY, BENGALURU, School of CSE
Continuous Feedback Loop
Agile development creates a learning cycle:
[Link] a small piece of the product.
[Link] its impact through customer feedback.
[Link] what works and what doesn’t.
[Link] the product and plan accordingly.

3. Agile Product Roadmap

The Product Roadmap provides a high-level view of the product’s direction over time, but it’s not a fixed plan — it
evolves with customer feedback and business changes.

Aspect Description
Communicate vision and high-level priorities to
Purpose
stakeholders.
Structure Divided into themes, epics, or goals — not fixed dates.
Ownership Product Owner (in Scrum) maintains and adjusts it.
Adaptability Updated after every release or major feedback cycle.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Example:
A mobile banking app roadmap might outline three broad goals:
•Release 1: Enable core banking transactions (Month 1–2)
•Release 2: Add bill payments and Zelle transfers (Month 3–4)
•Release 3: Introduce budgeting and insights dashboard (Month 5–6)

4. Release Planning in Agile

Release planning translates the roadmap into actionable short-term deliverables.
Instead of locking the scope, Agile release plans focus on delivering the most valuable features first, adjusting as
feedback arrives.

Activity Description
Define the smallest set of features that delivers core
Identify MVP (Minimum Viable Product)
value.
Estimate User Stories Use Story Points or Planning Poker to size work.
Prioritize by Value and Risk Deliver high-value, low-risk items first.
Plan Iterations per Release Organize work into sprints leading to a release.
Review and Adapt Adjust scope or schedule after every iteration.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

5. Role of Continuous Feedback and Iteration
Feedback is the engine of Agile product development. Each iteration allows learning and adjustment.

Feedback Source Type of Learning Example

Stakeholders suggest UI
Sprint Review Business & user value
improvements.
Team identifies blockers and
Daily Scrum Process feedback
adjusts.
Team adopts automated testing to
Retrospective Team performance
reduce defects.
Users request a mobile version
Customer Feedback Product direction
sooner.

Continuous feedback ensures that product evolution aligns with user expectations, reducing wasted effort on non-
value features.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

6. Example – Agile Product Lifecycle in Practice
Project: Online Food Delivery App

Phase Agile Activity Outcome

Define goal: “Deliver food in under
Product Vision Vision document
30 minutes.”
Plan releases: Core ordering →
Roadmap Product roadmap
Tracking → Loyalty rewards.
Release Planning Select features for Release 1. Release plan
Implement and test “Order and
Sprint Execution Working increment
Payment.”
Review & Feedback Customer demo and feedback. Improved backlog priorities

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

7. Comparison: Agile Product Lifecycle vs. Traditional Model

Aspect Traditional (Waterfall) Agile Product Development

Planning Fixed and upfront Adaptive and ongoing
Delivery One final release Multiple incremental releases
Customer Feedback At the end Continuous
Change Handling Difficult and costly Expected and embraced
Goal Follow plan Deliver value early and often

Takeaway
Agile product development is not about managing tasks—it’s about managing learning.
By integrating continuous feedback, adaptive planning, and incremental delivery, Agile ensures that every
iteration brings the product closer to what users truly need.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Summary

Key Concept Description

Agile product development emphasizes delivering
Definition
value iteratively and adapting through feedback.
Vision → Roadmap → Release Planning → Iterations
Lifecycle Phases
→ Feedback.
Collaboration, adaptability, continuous delivery,
Core Principles
customer feedback.
Product Vision, Product Roadmap, Release Plan, Sprint
Artifacts
Backlog, Increment.
Agile enables clean, evolutionary design aligned with
Uncle Bob’s Insight
changing requirements.
Empirical process control and feedback-driven
Mike Cohn’s Insight
planning are key to success.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Agile Metrics : Progress & Predictability

Agile metrics provide visibility, transparency, and predictability in software development.

They help teams inspect and adapt—core principles of Agile—by measuring what truly matters: working software,
team performance, and delivery consistency.

1. Importance of Metrics in Agile

In Agile, metrics are not about control or micromanagement but about learning, improvement, and forecasting.
They serve as feedback mechanisms that help teams and stakeholders understand how development is progressing
and where improvements can be made.

Purpose of Agile Metrics Description

Transparency Makes progress visible to all stakeholders.
Enables realistic forecasting of future work
Predictability
completion.
Identifies bottlenecks, inefficiencies, and areas for
Continuous Improvement
process optimization.
Customer Satisfaction Ensures the team is delivering value consistently.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

2. Common Agile Metrics

The three most common Agile metrics for tracking progress and predictability are:
1. Velocity
•Definition: The amount of work a team completes in a sprint, measured in Story Points.
•Purpose: Predicts how much work the team can handle in future sprints.
How It Works:
•If a team completes 35, 37, and 33 story points over three sprints, their average velocity is ≈ 35 story points per
sprint.
•The Product Owner uses this to forecast how many sprints are needed to complete the remaining backlog.

Sprint Committed Points Completed Points (Velocity)

Sprint 1 40 35
Sprint 2 38 37
Sprint 3 35 33

Interpretation:
•Stable velocity → Predictable delivery.
•Fluctuating velocity → May indicate impediments or scope instability.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

2. Sprint Burndown Chart
•Definition: A visual representation of remaining work (in story points or hours) versus time during a sprint.
•Purpose: Tracks daily progress within a sprint and identifies whether the team is on pace to meet the sprint goal.
How It Works:
•X-axis: Days of the sprint
•Y-axis: Remaining work
•The line should gradually “burn down” toward zero by the end of the sprint.

Day Remaining Points

1 40
3 30
5 20
7 10
10 0

Interpretation:
•Smooth downward slope: On track.
•Flat line: Blockers or overcommitment.
•Steep drop at end: Testing or integration delayed until late.
PRESIDENCY UNIVERISTY, BENGALURU, School of CSE
3. Release Burndown / Burnup Charts

Release Burndown
•Shows progress toward completing all work in a release.
•X-axis: Sprints; Y-axis: Remaining work (story points).

Release Burnup
•Shows accumulated work completed over time.
•Easier to visualize scope changes—if the total scope line changes, it reflects added or removed backlog items.
Example:
If total release scope = 200 story points and the team completes 35 per sprint, the burnup chart line rises steadily each
sprint.

Interpretation:
•Predicts the release date based on actual velocity.
•Highlights scope changes and their impact on schedule.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

3. How to Interpret and Use These Metrics

Metric What It Shows How to Use It Common Misuse

Plan sprint scope and
Velocity Team’s delivery capacity Using it to compare teams
forecast release
Sprint progress toward Identify impediments Updating manually or
Sprint Burndown
goal early infrequently
Predict release
Release Long-term release Ignoring added/removed
completion and track
Burndown/Burnup progress work
scope changes

Best Practices:
•Use metrics to start conversations, not end them.
•Focus on trends over time, not individual data points.
•Combine quantitative data (velocity) with qualitative insights (retrospectives).

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

4. Agile Progress Tracking vs. Traditional Tracking

Aspect Traditional (Waterfall) Agile Approach

Tracking Basis Schedule & milestones Working software delivered
Progress Measurement % of tasks done Story points completed
Empirical velocity & burndown
Forecasting Fixed plans
trends
Change Handling Discouraged Expected and adapted

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

5. Example: Using Agile Metrics Together
Scenario: A team developing an e-learning platform tracks metrics over several sprints.

Metric Insight
Stabilizes around 30 story points → Predictable
Velocity
output.
Shows early blockers in testing phase → Team
Sprint Burndown
automates tests.
Scope increases after stakeholder feedback →
Release Burnup
Adjusted timeline.

Takeaway
Agile metrics don’t measure people — they measure progress.
They support empirical decision-making, team self-improvement, and customer trust, aligning perfectly with both
Uncle Bob’s craftsmanship principles and Mike Cohn’s empirical Scrum philosophy.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Agile Metrics: Quality & Efficiency

Agile teams aim not only to deliver fast, but to deliver high-quality software that continuously meets customer
expectations.

1. The Role of Quality and Efficiency Metrics in Agile

In Agile, speed without quality leads to rework, and quality without efficiency delays value delivery.
Hence, Agile metrics are used to balance speed, quality, and continuous improvement.

Goal of These Metrics Description

Ensure technical excellence Measure code health, reliability, and maintainability.
Track how efficiently work moves from idea to
Optimize flow
delivery.
Identify bottlenecks Reveal where process delays or quality issues occur.
Support continuous improvement Provide objective data to refine Agile practices.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

2. Key Agile Quality and Efficiency Metrics

1. Defect Density
•Definition: Number of defects found per unit of code (e.g., per 1,000 lines of code or per story point).
•Purpose: Measures software stability and reliability.

Formula: Defect Density = (Total Defects) / (Size of Software Unit)

Example:
If 20 defects are found in 10,000 lines of code,
Defect Density = 0.002 defects/LOC (or 2 defects per KLOC).

Interpretation:
•Lower density = higher quality.
•Track trend across iterations to see if code quality is improving.

Uncle Bob: Believes defect density reflects discipline in TDD, refactoring, and clean coding practices. “The fewer bugs
you write, the faster you go.”
Mike Cohn: Suggests tracking defects per sprint to detect recurring problem areas (e.g., testing gaps or unclear
requirements).
PRESIDENCY UNIVERISTY, BENGALURU, School of CSE
2. Lead Time

•Definition: The total time from when a user story is created to when it is delivered to the customer.
•Purpose: Indicates how quickly the team delivers value.
| Formula: | Lead Time = Delivery Date − Request Date |

Example:
If a story was added on March 1 and delivered on March 7,
Lead Time = 6 days.

Interpretation:
•Shorter lead times → faster value delivery and higher responsiveness.
•Long lead times → excessive waiting, bottlenecks, or overcommitment.

Uncle Bob: Stresses that lean flow and continuous delivery reduce waste — aligning with Agile’s adaptability.
Mike Cohn: Recommends using lead time trends to identify systemic delays (e.g., too much work in progress or
dependency chains).

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

3. Cycle Time

•Definition: The time taken to complete a single work item once the team starts working on it.
•Purpose: Measures efficiency within the development process.

| Formula: | Cycle Time = Completion Date − Start Date |

Interpretation:
•Shorter, consistent cycle times → predictable delivery.
•Sudden increases → bottlenecks or unclear tasks.

Uncle Bob: Links shorter cycle times to high code cohesion and automated testing, which allow faster integration
and feedback.
Mike Cohn: Recommends visualizing cycle time using Cumulative Flow Diagrams (CFDs) to spot workflow blockages.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

4. Code Coverage

•Definition: The percentage of source code executed by automated tests.

•Purpose: Indicates how well the codebase is verified through testing.

| Formula: | Code Coverage = (Lines of Code Tested / Total Lines of Code) × 100 |

Example:
If 7,000 of 10,000 lines are covered by tests,
Coverage = 70%.

Interpretation:
•High coverage = better test confidence (but not always better quality).
•Combine with defect trends to assess test effectiveness.

Uncle Bob: A major advocate of Test-Driven Development (TDD) — he sees code coverage as a by-product of good
design, not the goal itself.
Mike Cohn: Advises teams to focus on meaningful coverage (critical paths and user-facing features), not chasing 100%.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

5. Build Success Rate (Continuous Integration Health)

•Definition: The percentage of successful builds in the CI pipeline.

•Purpose: Reflects integration stability and readiness for deployment.

| Formula: | Build Success Rate = (Successful Builds / Total Builds) × 100 |

Interpretation:
•High rate (>95%) = healthy, stable pipeline.
•Frequent build failures = integration issues or poor test reliability.

Uncle Bob: Promotes Continuous Integration (CI) as essential — frequent integration keeps the system always working.
Mike Cohn: Suggests using CI metrics to spot technical debt early, avoiding surprise failures late in the sprint.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

3. Using Metrics to Identify Bottlenecks
Agile metrics reveal where process inefficiencies or quality issues occur.

Symptom Possible Bottleneck Metric That Detects It

Long waiting time for code reviews Process delay Lead Time, Cycle Time
Frequent build failures Poor integration/testing Build Success Rate
Increasing bug counts Declining quality Defect Density
Slow progress despite effort Too much WIP or unclear scope Lead Time, Velocity

Actionable Improvement:
•Visualize workflow using Kanban or Cumulative Flow Diagrams.
•Discuss metrics during Sprint Retrospective to decide what to improve next.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

4. Team-Level Efficiency Metrics
These metrics help the team assess technical excellence and delivery consistency.
Metric What It Measures Why It Matters
Code Coverage Quality of automated testing Ensures confidence in changes
Build Success Rate Integration health Detects breakages early
Refactoring Frequency Code maintainability Improves long-term agility
Technical Debt Trend Code complexity & maintainability Tracks design decay

5. Agile Mindset Toward Metrics

Principle Agile Approach

Teams own their metrics and use them to self-
Metrics are for learning, not judgment
improve.
Testing, refactoring, and integration happen
Quality is built-in, not inspected later
continuously.
Efficiency = flow, not speed Focus on removing waste and improving throughput.
Transparency breeds trust Metrics shared openly with stakeholders.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Summary

Metric Type Examples Purpose

Defect Density, Code Coverage, Ensure technical excellence and
Quality Metrics
Build Success Rate software reliability
Measure delivery efficiency and
Flow Metrics Lead Time, Cycle Time
identify bottlenecks
Technical Debt, Refactoring Maintain long-term agility and
Team Metrics
Frequency sustainable pace

Key Takeaways

•Agile metrics for quality and efficiency focus on maintainability, reliability, and flow.
•They help teams identify waste, improve craftsmanship, and deliver sustainable value.
•Uncle Bob emphasizes clean code, TDD, and refactoring as measurable quality drivers.
•Mike Cohn emphasizes transparency, continuous feedback, and data-driven adaptation.
Together, they frame metrics as a tool for empowerment, not enforcement — helping Agile teams grow smarter, not
just faster.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Feature-Driven Development (FDD): Overview

Feature-Driven Development (FDD) is an Agile, model-driven software development methodology that emphasizes
building software around features — small, client-valued pieces of functionality.
It was originally developed by Jeff De Luca and Peter Coad in the late 1990s, designed to help teams manage large and
complex systems in a structured yet adaptive way.

1. Introduction and Essence of FDD

FDD focuses on delivering tangible, working features in short iterations (typically 2–3 weeks).
Each feature is defined from the user’s perspective — something meaningful and valuable, such as:
“Calculate the customer’s monthly loan interest,” or
“Generate a student attendance summary.”

Core Idea:
“Build by feature, deliver by feature.”
This makes the development process client-centric, predictable, and progress-measurable, aligning with Agile values
of working software and customer collaboration.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

2. Core Principles and Values of FDD

FDD Principle Description Connection to Uncle Bob / Mike Cohn

All planning and progress are based on Cohn emphasizes delivering business value in
Client-Centricity
features the client values. each iteration.

Development revolves around small, well- Uncle Bob advocates breaking work into small,
Feature-Based Planning
defined functional units. verifiable steps.

Start with an object-oriented domain model to Uncle Bob stresses clean architecture and
Model-Driven Design
guide implementation. strong design foundations.

Deliver features in short timeframes (2–10 Cohn’s Scrum approach promotes timeboxing
Short Iterations
days per feature set). and feedback.

Developers own specific classes or Both authors emphasize responsibility and

Individual Ownership & Accountability
components. craftsmanship.

Continuous integration and design/code Aligns with Agile’s focus on technical

Regular Builds & Inspections
reviews maintain quality. excellence and refactoring.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

3. FDD Process Overview

FDD consists of five sequential process steps, blending planning discipline with iterative delivery.

FDD Step Description Agile Equivalent

Create a high-level object model
1. Develop an Overall Model Agile Architecture Vision
based on domain understanding.
Break system into client-valued
2. Build a Feature List Product Backlog Creation
features (each ≤ 2 weeks of work).
Schedule and assign features to
3. Plan by Feature Sprint Planning
teams or owners.
Model and review the design for
4. Design by Feature each feature before Sprint Design & Refinement
implementation.
Code, test, and integrate the
5. Build by Feature Sprint Execution & Review
feature into the main build.

Each feature is designed, coded, and tested independently, leading to early validation and continuous delivery.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

4. When FDD is Most Applicable

FDD works best in:

•Large, complex projects where design consistency and progress visibility are crucial.
•Distributed or enterprise teams needing a structured Agile framework.
•Client-driven environments that prioritize measurable progress and reporting.

Examples of use:
•Banking applications (e.g., loan management system)
•E-commerce platforms (e.g., order tracking system)
•ERP or government software systems
FDD is less suited for highly exploratory projects where requirements change daily (Scrum or Kanban are better
there).

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

5. Key Roles in an FDD Project
FDD introduces clearly defined roles to ensure both ownership and collaboration.

Role Responsibility
Project Manager Oversees progress, schedules, and reporting.
Leads design, ensures architectural integrity, mentors
Chief Architect / Chief Programmer
others.
Development Manager Coordinates feature teams and assignments.
Responsible for specific classes/components in the
Class Owner (Developer)
system.
Temporary cross-functional team assembled to
Feature Team
implement a specific feature set.
Provides domain knowledge and validates features
Domain Expert / Client Representative
(similar to Product Owner in Scrum).

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

 Comparison with Scrum Roles:

FDD Role Scrum Equivalent

Domain Expert Product Owner
Chief Programmer Scrum Master / Technical Coach
Feature Team Development Team

9. Advantages of FDD
Predictable progress tracking through measurable features
High client involvement and satisfaction
Strong design consistency (object modeling)
Encourages accountability and ownership
Well-suited for large, complex projects

10. Limitations of FDD

Requires strong domain modeling expertise
Less flexibility if requirements change frequently
Upfront modeling may slow initial progress
Not ideal for small teams or exploratory projects

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

8. Real-World Example
Scenario: Online Banking System
Goal: Enable users to view transaction history, transfer funds, and pay bills online.

FDD Step Outcome

Identify domain entities like Account, Transaction,
Develop Overall Model
Customer
“View Transaction History,” “Transfer Funds,” “Pay
Build Feature List
Bills”
Prioritize “View Transaction History” as first
Plan by Feature
deliverable
Design by Feature Create class diagram and feature design package
Build by Feature Implement and test the feature within two weeks

Each feature passes through design, build, and inspection — giving continuous value and visibility to stakeholders.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

 Summary

Aspect FDD View Agile Link

Working software over
Focus Client-valued features
documentation
Planning Model-driven, feature-based Adaptive backlog refinement
Iteration Short, feature-sized Sprints in Scrum
Feedback Frequent delivery to client Continuous customer collaboration
Team Structure Defined roles, ownership Self-organizing teams

In Summary

• Feature-Driven Development (FDD) blends Agile’s iterative nature with the discipline of structured design.
Both Uncle Bob and Mike Cohn acknowledge its strengths in maintaining quality, ownership, and visibility —
though they advise balancing modeling discipline with flexibility and feedback.

• In essence, FDD stands as a client-centric, design-driven Agile approach — best for large projects where
clarity, progress tracking, and architectural stability are vital.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Agile Approach to Quality Assurance

In traditional (Waterfall) development, testing and quality assurance (QA) typically occur after coding — leading to
late defect discovery and high rework costs.
In contrast, Agile integrates quality practices throughout the development cycle, ensuring that “quality is built in, not
tested in.”
This approach aligns with Uncle Bob’s philosophy of “clean code, continuous feedback, and professional
craftsmanship,” and with Mike Cohn’s emphasis on “collaboration between developers, testers, and customers to
achieve shared quality goals.”

1. Shifting Quality Left in the Agile Lifecycle

Concept:

“Shift Left” means moving testing and quality assurance activities earlier in the development process.
Rather than waiting until the end of a sprint or release, testing starts from day one — during planning, design, and
development.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Traditional (Waterfall) Agile (Shift Left)
Testing happens after coding. Testing begins alongside coding.
QA identifies defects late. QA prevents defects early.
Separate testing phase. Continuous testing integrated into each iteration.

2. Continuous Testing and Its Importance

What Is Continuous Testing?

It is the practice of running automated and manual tests frequently throughout the Agile lifecycle — from integration
to deployment.

Testing is integrated into:

•Continuous Integration (CI): Each code commit triggers automated builds and tests.
•Continuous Delivery (CD): Ensures each increment is deployable and verified.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Purpose:
•Detect defects early
•Provide constant feedback
•Validate that the product always works in a “releasable” state

Benefits:
Aspect Agile Benefit
Early defect detection Lowers rework cost
Short feedback loops Accelerates learning
High confidence in releases Improves reliability
Automation Increases consistency and speed

3. Role of QA/Testers in Agile Teams

In Agile, QA is not a separate phase or department — testers are embedded members of the Scrum team.
They collaborate closely with developers and product owners throughout the sprint.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Key Roles and Responsibilities:

Responsibility Description
Collaborate in Story Creation Help define acceptance criteria for each user story.
Test Early & Often Participate from sprint planning to demo.
Automate Tests Develop regression and functional tests.
Bridge the gap between developers and product
Facilitate Communication
owners.
Promote continuous improvement through metrics
Drive Quality Mindset
and retrospectives.

Embedded and Collaborative QA:

•Testers join daily stand-ups, planning, and retrospectives.

•QA helps ensure that the Definition of Done (DoD) includes testing.
•They pair test with developers (like pair programming) for shared understanding.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

4. Agile Testing Quadrants

To organize testing activities, Brian Marick’s Agile Testing Quadrants (adopted by Mike Cohn) classify tests based on
purpose (support team vs. critique product) and type (business-facing vs. technology-facing).

Quadrant Type of Test Purpose Examples

Technology-facing, Verify code quality and Unit tests, Component
Q1
supports development design tests
Business-facing, supports Verify functionality and Functional tests, Story
Q2
development business logic tests
Business-facing, critiques Validate customer Exploratory tests,
Q3
product experience Usability tests, UAT
Technology-facing, Test non-functional Performance, Security,
Q4
critiques product aspects Load tests

How the Quadrants Guide Agile QA:

•Q1 & Q2: Focus on building quality in (developers + testers collaborate).
•Q3 & Q4: Focus on assessing overall product quality (often after integration).
•Encourages balance between automation and exploratory testing.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

5. Agile QA in Action – Example

Scenario: E-Commerce Application

Goal: Implement a “Product Search” feature in a 2-week sprint.

Stage Agile QA Practice Example

QA collaborates on acceptance “User can search by product name
Sprint Planning
criteria and filter by category.”
Developers write tests before code
Development TDD and automated unit tests
using JUnit.
Automated build triggers tests after
Integration Continuous testing in CI pipeline
each commit.
QA verifies functionality with Demo search and filter, gather
Sprint Review
stakeholders feedback.
QA and team identify Add performance tests for faster
Retrospective
improvements search.

Result → Fewer bugs, faster delivery, shared accountability for quality.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

6. Benefits of Agile QA

Early defect prevention (not just detection)

Shared ownership of quality across the team
Continuous customer feedback loop
Higher automation and reduced testing bottlenecks
Improved product reliability and user satisfaction

In Summary

Agile Quality Assurance is about:

•Building quality in from the start
•Testing continuously across all levels
•Collaborating across roles to prevent defects early
•Balancing automation and exploration

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Test Driven Development (TDD): Principles & Cycle

1. Introduction to TDD
Test-Driven Development (TDD) is a disciplined software development approach where tests are written before the
actual implementation code.
It is one of the core engineering practices of Extreme Programming (XP) and supports Agile principles such as continuous
feedback, simplicity, and technical excellence.

The Red–Green–Refactor Cycle

The core process of TDD is represented by a three-step feedback loop known as the Red–Green–Refactor cycle.

Phase Action Goal

Write a failing test for a small new
Red Define what the code should do.
behavior or feature.
Write the minimum code necessary
Green Achieve correctness quickly.
to make the test pass.
Clean up the code without Improve design, remove
Refactor
changing behavior. duplication.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

This cycle is repeated for every small functionality, ensuring that the system grows incrementally and reliably.

Example:

Writing a function to check if a number is even:

[Link]: Write test → isEven(4) should return true. (Test fails)
[Link]: Implement → return n % 2 == 0; (Test passes)
[Link]: Improve readability if needed, maintain clean code.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Benefits of TDD

Benefit Explanation Reference

Encourages developers to think
Improved Design about interfaces and modularity Uncle Bob
first.
Issues are caught immediately as
Less Debugging Mike Cohn
tests are continuously run.
Test cases describe system behavior
Living Documentation Both
and serve as documentation.
Developers can refactor confidently
Safe Refactoring knowing that existing tests verify Uncle Bob
correctness.
Supports Agile principle of working
Continuous Feedback Mike Cohn
software and short feedback loops.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Challenges of TDD

Challenge Description
Learning Curve Developers need discipline to write tests before code.
Time Investment Initial development appears slower but pays off later.
Poorly Written Tests If tests are unclear or brittle, they reduce confidence.
Some teams view testing as a separate phase, not an
Team Resistance
integrated activity.

Common Misconceptions of TDD

Myth Reality
TDD is only for testing It’s a design and thinking process.
TDD slows development It reduces debugging and rework time overall.
QA is still needed for integration and acceptance
TDD eliminates the need for QA
testing.
It scales when supported by automation tools and
TDD can only be used for small projects
CI/CD.
PRESIDENCY UNIVERISTY, BENGALURU, School of CSE
TDD and Agile Principles

TDD directly supports the Agile Manifesto values and principles:

Agile Principle How TDD Supports It

TDD ensures every increment is functional and
Working software is the primary measure of progress
verified.
Continuous attention to technical excellence Writing clean, tested code improves maintainability.
Tests allow safe, quick refactoring when requirements
Welcome changing requirements
evolve.
Build projects around motivated individuals Developers own both design and quality.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Example: TDD in a Scrum Sprint

Scrum Event TDD Contribution

Identify stories and define test cases for acceptance
Sprint Planning
criteria.
Development (Sprint Execution) Apply Red–Green–Refactor for each task.
Daily Scrum Discuss test progress and blockers.
Sprint Review Demonstrate working, tested code.
Sprint Retrospective Analyze test coverage and improve TDD practices.

TDD ensures every sprint increment meets the Definition of Done through automated validation.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Summary Table

Aspect Description
Writing tests before code to drive design and ensure
Definition
correctness.
Cycle Red → Green → Refactor
Goal Clean, maintainable, working software
Benefits Improved design, fewer defects, living documentation
Challenges Learning curve, initial time investment
“Write no production code without a failing test.” —
Philosophy
Uncle Bob

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Test-Driven Development (TDD): Practical Aspects

1. Overview

Test-Driven Development (TDD) is not just a testing activity — it is a development discipline that guides how
developers write clean, working code iteratively.
In practice, TDD involves writing a test before writing the corresponding functional code and refactoring continuously to
maintain simplicity and correctness.

Both Uncle Bob and Mike Cohn emphasize that TDD transforms how teams work:
•It brings clarity and precision to requirements.
•It reduces defects and increases developer confidence.
•It seamlessly integrates with Agile workflows such as Scrum Sprints.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Applying TDD in Practice — Step-by-Step

TDD is often implemented using the Red–Green–Refactor cycle (Uncle Bob’s model).

Step Action Purpose

Write a failing test that defines new
Red Clarify intent.
functionality.
Write just enough code to make
Green Achieve correctness.
the test pass.
Simplify and improve the code
Refactor Maintain quality.
while keeping tests green.

Example (Case Study – Login Validation):

•Red: Write a test: “If username or password is empty, login should fail.”
•Green: Write code to check non-empty inputs.
•Refactor: Remove duplicate checks or simplify conditional logic.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Writing Effective Unit Tests

According to Uncle Bob and Mike Cohn, effective unit tests should follow these principles:

Principle Description
Tests should execute quickly to encourage frequent
Fast
runs.
Tests should not depend on other tests or shared
Independent
state.
Repeatable Should produce the same result every time.
Self-validating Pass or fail without manual interpretation.
Timely Written before production code (core of TDD).

These principles (known as the F.I.R.S.T. rules by Uncle Bob) ensure that tests are reliable and easy to maintain.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Integrating TDD into Daily Agile Workflow

Agile Activity TDD Practice Example

Identify user stories and “As a user, I should be able to log
Sprint Planning acceptance criteria → convert to in.” → Write test for valid/invalid
test cases. credentials.
Implement features test-first using Write failing test → Implement →
Development
Red–Green–Refactor cycle. Refactor.
Discuss progress using test metrics Transparency of development
Daily Scrum
(“5 tests still failing”). health.
Demonstrate features backed by All acceptance tests green = feature
Sprint Review
passing tests. accepted.
Discuss test coverage, flaky tests,
Retrospective Team learns from testing feedback.
and ways to improve automation.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Practical Case Study: Banking Application Example
Let’s apply TDD to a banking transaction module.

Scenario Test Case (Red) Implementation (Green) Refactor

Write test: Add check if (amount
Transfer amount cannot Extract condition into
assertFalse(trans < 0) return
be negative. validation method.
fer(-100)) false;
Write test:
Balance should reduce assertEquals(900, Remove redundant
Update balance logic.
after transfer. getBalance()) after balance recalculations.
transfer(100)

Outcome:
•The design evolves naturally.
•Each functionality is validated, documented, and safe to modify.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Common TDD Integration Tools

Tool Use Context

Used in Uncle Bob’s C++/Java
JUnit Unit testing framework for Java
examples
Mocking framework to simulate
Mockito For service-layer testing
dependencies
Run tests automatically on each
Jenkins / GitHub Actions Continuous Integration (CI) tools
commit
Code quality and test coverage
SonarQube Monitors test health in Agile teams
analysis

Mike Cohn emphasizes integrating automated testing into the Continuous Integration (CI) pipeline to ensure every
sprint increment meets quality standards.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Benefits of TDD in Practice

Benefit Explanation Author Reference

Bugs are caught before code
Fewer Defects Mike Cohn
integration.
Code evolves through test-driven
Better Design Uncle Bob
structure.
Immediate validation of every
Continuous Feedback Both
change.
Tests ensure changes don’t break
Confidence in Refactoring Uncle Bob
functionality.
Shared test base builds trust
Team Collaboration Mike Cohn
among developers and testers.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Challenges and Mitigation
Challenge Example Mitigation Strategy
Developers skip writing tests under Treat test writing as part of the
Sprint deadlines.
time pressure. Definition of Done.
Overly complex tests. Duplicated test logic. Refactor test code regularly.
Use meaningful test names
Poor test naming and structure. Hard to understand purpose.
(“shouldRejectInvalidPassword”).

Summary: How TDD Aligns with Agile Principles

Agile Principle TDD Alignment

Working software is the primary measure of progress Tests verify working functionality frequently.
Continuous attention to technical excellence Refactoring improves code quality.
Welcome changing requirements TDD provides a safety net for refactoring and change.
Deliver working software frequently Continuous integration ensures fast delivery.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Example TDD Workflow (Diagram) This iterative cycle repeats throughout the sprint — forming the backbone of
Agile engineering discipline.

In Summary

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

In Summary

Aspect Uncle Bob’s View (T1) Mike Cohn’s View (T2)

TDD is about design, not just TDD ensures predictable, quality
Purpose
testing. delivery.
Craftsmanship, Clean Code, Team Collaboration, Continuous
Focus
Refactoring Feedback
Aligns with Scrum’s Definition of
Integration Red–Green–Refactor as habit
Done
Maintainable, flexible, high-quality Confident teams and satisfied
Outcome
systems customers

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Agile in Global Software Development (GSD): Challenges

1. Introduction

Global Software Development (GSD) refers to software teams distributed across multiple geographical locations, time
zones, and cultures.
When organizations attempt to adopt Agile methods in GSD, they often face challenges due to reduced face-to-face
communication, coordination difficulties, and time differences.
While Agile emphasizes collaboration, adaptability, and frequent communication, distributed settings make these
principles harder to practice.

“Agile thrives on communication and collaboration. Distance makes both harder.” — Robert C. Martin (T1)
“Agile in a global context is possible, but it requires conscious effort and the right tools and habits.” — Mike Cohn
(T2)

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

The Agile–GSD Paradox

Agile Principle (as per Manifesto) Challenge in GSD

Communication barriers due to distance, time zones,
Individuals and interactions over processes and tools
and language differences.
Limited access to customers or product owners in
Customer collaboration over contract negotiation
remote locations.
Responding to change over following a plan Coordination delays make adapting quickly harder.
Face-to-face conversation is the most effective Distributed teams rely on virtual, asynchronous
communication communication.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Communication Barriers

(a) Time Zone Differences

•Teams spread across continents (e.g., India, USA, Europe) have limited overlapping work hours.
•Synchronous activities like Daily Scrum, Sprint Planning, or Retrospectives become difficult to schedule.

Example:
A Scrum team with members in Bangalore (IST) and California (PST) may only have a 1-hour overlap window, making
real-time collaboration rare.

Solutions (Cohn’s recommendation):

•Use asynchronous communication tools (Slack, Teams, Confluence).
•Record sprint demos or discussions for delayed viewing.
•Create rotating meeting schedules to share the inconvenience across time zones.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

(b) Cultural and Language Differences
•Different work ethics, hierarchy perceptions, and feedback styles cause misunderstanding.
•For instance, in some cultures, disagreement with seniors in a meeting might be avoided — reducing open
communication.

Uncle Bob’s viewpoint:

Agile teams must build mutual trust and respect to ensure honest feedback — a key to self-organizing behavior.

Practical approaches:
•Conduct cross-cultural training sessions.
•Encourage psychological safety in retrospectives — “All voices matter.”
•Use video over text when tone matters.
(c) Lack of Informal Communication

•In co-located teams, casual hallway or coffee break conversations often spark problem-solving.
•In distributed teams, such spontaneous communication is missing.

Solution (Mike Cohn’s advice):

•Schedule virtual coffee breaks or end-of-sprint social calls to foster team bonding.
•Use collaboration spaces (e.g., Miro, Jamboard) for informal brainstorming.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

4. Coordination Challenges

(a) Synchronizing Work Across Teams

Agile relies on short iterations (sprints), frequent integration, and continuous feedback.
In GSD, misalignment between teams leads to delays and integration problems.

Example:
Two Scrum teams in different countries working on dependent modules may complete sprints out of sync, causing
integration failures.

Solutions:
•Use Agile Release Trains (ARTs) in scaled Agile setups to align distributed teams.
•Create a shared Definition of Done (DoD) to maintain consistency.
•Employ continuous integration (CI) tools like Jenkins or GitHub Actions to merge work frequently.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

(b) Product Ownership and Decision Delays
•The Product Owner is often located away from development teams.
•Questions about requirements remain unresolved due to asynchronous communication.
Mike Cohn’s solution:
Appoint local proxy product owners or feature owners to bridge time and location gaps.
Encourage developers to collaborate directly with customers rather than waiting for approvals.

(c) Maintaining Agile Ceremonies

•Daily stand-ups lose effectiveness when participants join asynchronously.

•Sprint retrospectives may have low participation due to fatigue or timing issues.

Recommendations:
•Use asynchronous tools like Geekbot for distributed Daily Scrums.
•Rotate retrospective facilitators across locations to build shared responsibility.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

5. Tooling and Infrastructure Considerations
(a) Collaboration Tools
GSD depends heavily on digital platforms to simulate co-located interaction.

Agile Activity Supporting Tools

Daily Scrum / Stand-up Zoom, Microsoft Teams, Slack (huddles)
Sprint Planning / Backlog Refinement Jira, Trello, Azure DevOps
Code Collaboration GitHub, GitLab, Bitbucket
Documentation Confluence, Google Docs
Retrospectives Miro, EasyRetro, Parabol

Both Uncle Bob and Cohn emphasize that tools should support collaboration, not replace it — Agile is still people-first.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

(b) Infrastructure Reliability

•Poor connectivity, VPN restrictions, or slow tools can hinder real-time work.
•Lack of shared environments delays testing and integration.

Solutions:
•Invest in cloud-based CI/CD pipelines.
•Standardize tooling environments across teams.
•Provide access to shared staging servers for integration testing.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

6. Example Case Study – Distributed Scrum Team
Scenario:
A multinational e-commerce company with teams in India, Germany, and the U.S. develops a global order tracking
feature.

Challenge Impact Agile Solution

Local proxy product owner and
Time zone gap delays decisions. Team idle waiting for clarifications.
daily asynchronous stand-ups.
Continuous Integration and shared
Integration issues between teams. Sprint deliverables break at merge.
“Definition of Done.”
Cultural misunderstanding in Retrospective etiquette and
Feedback perceived as criticism.
reviews. empathy training.

Outcome: After 3 sprints, velocity stabilized, and defect leakage decreased by 30%.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

7. Best Practices for Agile in GSD (from Cohn and Martin)

Focus Area Recommended Practice Source

Prefer video + chat over email;
Communication Mike Cohn
build empathy.
Use short, frequent check-ins
Coordination Robert C. Martin
instead of long meetings.
Encourage transparency about
Trust Building Mike Cohn
blockers and progress.
Apply TDD, pair programming,
Technical Practices Robert C. Martin
CI/CD to reduce rework.
Conduct sprint retrospectives
Cultural Integration Mike Cohn
focused on team bonding.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Agile Principles Revisited in Global Context

Agile Principle Distributed Application

Face-to-face conversation Video calls and digital collaboration spaces.
Working software as progress Shared CI/CD dashboards showing increment status.
Trust remote members with autonomy and
Build projects around motivated individuals
accountability.
Welcome change Maintain an adaptive backlog using tools like Jira.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Summary

Challenge Area Impact on Agile Mitigation Strategy

Time Zone Gaps Delays collaboration Asynchronous communication tools
Cross-cultural awareness &
Cultural Barriers Miscommunication, low morale
empathy
Coordination Broken sprint flow Shared Definition of Done, CI/CD
Tooling Reduced transparency Standardized Agile toolchain

By consciously adapting communication, collaboration, and technical practices, Agile principles can thrive even in
global, distributed environments.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Agile Approach in GSD: Strategies & Best Practices

1. Introduction
When Agile principles are applied to Global Software Development (GSD) — where teams are distributed across different locations, time
zones, and cultures — success depends on how well teams adapt communication, trust, and coordination practices.

2. Core Objective
The goal of Agile in a GSD environment is to:
•Maintain collaboration and continuous feedback,
•Foster trust among distributed members,
•Deliver working software frequently, and
•Ensure transparency and adaptability across all sites.

3. Key Strategies & Best Practices

A. Communication Strategies in Global Agile Teams

Agile thrives on face-to-face conversation, but GSD replaces that with rich, frequent, and transparent virtual communication.
1. Virtual Stand-ups
•Short, daily sync-up meetings via video calls (Zoom, Teams, Google Meet).
•Encourage each member to answer the Three Scrum Questions:
• What did I do yesterday?
• What will I do today?
• What blockers are in my way?
Example:
In a project between India and the U.S., the Scrum Master alternates meeting times weekly to ensure fairness.
PRESIDENCY UNIVERISTY, BENGALURU, School of CSE
 2. Use of Rich Communication Tools
Effective distributed Agile teams rely on tools that enhance transparency and visibility.

Purpose Recommended Tools

Stand-ups & Meetings Zoom, Microsoft Teams
Instant Messaging Slack, Mattermost
Task Tracking Jira, Trello, Azure DevOps
Knowledge Sharing Confluence, Notion
Code Collaboration GitHub, GitLab
Retrospectives Parabol, Miro, EasyRetro

3. Asynchronous Communication
Since real-time overlap is limited, asynchronous updates become critical.
Teams can:
•Use daily written updates via Slack threads or project channels.
•Record sprint demos for later review.
•Maintain a shared dashboard for sprint progress and impediments.
Example:
A global healthcare software team uses Slack for async status updates and a Jira dashboard for sprint tracking.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

B. Building Trust and Team Cohesion Across Distances
In Agile, trust and collaboration are more important than formal processes. In distributed teams, trust doesn’t happen naturally — it must
be intentionally cultivated.

1. Transparency and Visibility

•Share progress dashboards (velocity charts, burndown charts).
•Make decisions and blockers visible to all.
•Use “working software” demos frequently to build confidence.
Mike Cohn: “Visibility creates trust — teams trust what they can see.”

2. Cultural Sensitivity and Inclusivity

•Encourage open communication, respecting cultural norms.
•Avoid scheduling meetings in culturally sensitive times.
•Create an environment of psychological safety — where everyone can voice ideas.

3. Virtual Team-Building Activities

•Conduct virtual coffee breaks, end-of-sprint celebrations, or icebreakers.
•Pair developers from different locations for pair programming — a core XP practice that enhances mutual understanding.
Uncle Bob’s Principle:
“Pairing isn’t just about code; it’s about building shared understanding and respect.”

4. Empowerment and Shared Ownership

•Rotate responsibilities — e.g., retrospective facilitator, demo presenter.
•Make all members feel ownership of the product outcome, not just local goals.
•Empower remote members to make decisions without waiting for central approval.
PRESIDENCY UNIVERISTY, BENGALURU, School of CSE
C. Distributed Agile Patterns and Anti-Patterns
1. Common Agile Patterns for Distributed Teams
Pattern Description Benefit
A scaled coordination meeting between Synchronizes multiple teams across
Scrum of Scrums
Scrum teams. locations.
Local representative of the main Reduces decision delays due to time
Proxy Product Owner
Product Owner to clarify requirements. zones.
Teams in different regions work
Follow-the-Sun Development Achieves 24-hour development cycles.
sequentially across time zones.
Shared visualization of tasks and
Virtual Kanban Boards Ensures global visibility.
progress.

Example:
In a multinational fintech project, a “Scrum of Scrums” connects teams in Germany, India, and Canada every two days to align sprint
progress.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

2. Common Anti-Patterns (Pitfalls to Avoid)

Anti-Pattern Description Negative Effect

Teams communicate only through Jira Loss of human connection and shared
Over-Reliance on Tools
or emails. understanding.
Centralized decision-making ignores
Command-and-Control Management Reduces motivation and autonomy.
remote team input.
Sprints become mini-waterfall cycles
Fake Agile (Distributed Waterfall) Agile principles are not truly practiced.
due to delays.
Remote members not included in
Invisible Teams Low morale and disengagement.
discussions or recognition.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

 4. Supporting Technical Practices
Both Cohn and Martin stress that distributed Agile depends on strong technical practices that maintain code quality and integration.
Practice Purpose Tool Example
Continuous Integration (CI) Merge and test code daily. Jenkins, GitHub Actions
Automated Testing / TDD Maintain quality across geographies. JUnit, Selenium, PyTest
Code Reviews & Pair Programming Encourage shared understanding. GitHub Pull Requests
Feature Toggles Manage partial releases. LaunchDarkly

These practices reinforce trust through transparency and reliability.

5. Example Case Study – Distributed Agile in a Global E-Commerce Project

Aspect Implementation Outcome

Daily virtual stand-ups; Slack async Improved transparency and reduced
Communication
updates delays
Pair programming across India–USA
Trust Better code consistency
teams
Scrum of Scrums + shared Jira
Coordination Fewer sprint-level dependencies
dashboard
Quality TDD and continuous integration 30% defect reduction per release

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

6. Summary Table: Key Strategies and Best Practices

Focus Area Best Practice Expected Benefit

Communication Virtual stand-ups, async updates, video calls Higher transparency and engagement
Shared dashboards, continuous feedback
Collaboration Stronger alignment
loops
Trust Cultural inclusion, open retrospectives Higher team morale
Coordination Scrum of Scrums, shared Definition of Done Reduced duplication and confusion
Technical Practices TDD, CI/CD, code reviews Consistent code quality

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Agile Project Management and Tools
1. Introduction
Agile Project Management (APM) focuses on delivering value through collaboration, adaptability, and transparency — rather than rigid
plans.
Traditional tools (like MS Project or Gantt charts) fail to support the iterative, incremental, and team-driven nature of Agile work.
Hence, Agile teams use modern project management tools like Jira, Trello, Azure DevOps, and Asana, which provide real-time visibility
into progress, priorities, and blockers.

2. Common Agile Project Management and Collaboration Tools

Tool Primary Use Key Features

Backlog management, sprint boards,
Jira Complete Agile project management
burndown charts
Trello Lightweight task visualization Kanban boards, cards, checklists
Azure DevOps Enterprise-level Agile management Sprint tracking, pipelines, test plans
Workflows, task dependencies,
Asana Cross-team collaboration
dashboards
[Link] Planning and automation Custom workflows and reporting
ClickUp All-in-one productivity Goals, docs, and Agile sprint views

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE