Why Agile Is Not Optional Anymore — and Why Real Agile Skills Are Rare
Walk into any IT company in Pune today — Persistent Systems, KPIT, Zensar, Infosys BPO, Capgemini, any of the hundreds of technology firms in Hinjewadi and Kharadi — and you will find Scrum boards, sprint planning meetings, product backlogs and retrospectives. Agile has become the operating system of Indian software delivery. The question is no longer whether a company uses Agile — it is whether the people involved actually know how to do it properly, or whether they are using Agile vocabulary while working in the same old ways with different meeting names.
🎓 Next Batch Starting Soon — Limited Seats
Free demo class available • EMI facility available • 100% placement support
This gap between nominal Agile adoption and genuine Agile competency is the opportunity. Teams that genuinely practice Scrum — with a skilled Scrum Master who removes impediments, a Product Owner who manages the backlog with real business understanding, and a team that commits meaningfully to sprint goals — consistently deliver better outcomes than teams that go through Agile motions without understanding why each practice exists. Companies know this, which is why demand for properly trained Agile practitioners keeps growing. A certified Scrum Master who can actually run effective sprints earns significantly more than a project manager with the same years of experience who does not have that skill.
Aapvex's Agile and Scrum programme is built around simulation — you do not just learn what a sprint is, you run one. You do not just learn what backlog refinement means, you practice prioritising a real product backlog using real agile techniques. You do not just read about retrospectives, you facilitate one and receive feedback. This simulation-first approach produces practitioners who can walk into any agile team on their first day and contribute meaningfully — which is exactly what employers are looking for. The programme also covers Kanban for flow-based teams, SAFe (Scaled Agile Framework) concepts for enterprise-level Agile understanding, and exam preparation for the CSM, PSM and PMI-ACP certifications that validate your Agile credentials to employers. Call 7796731656.
85%
IT Projects Use Agile in India
₹18L
Avg. Scrum Master Salary
6
Sprint Simulations Included
100%
Placement Assistance
Who Should Join This Agile & Scrum Programme?
- Software developers, QA engineers and technical team members working in Agile environments
- Project managers and team leads transitioning to Agile methodologies
- Business analysts who want to move into Product Owner roles
- Scrum practitioners who have been doing Agile without formal training
- HR, marketing and operations professionals whose organisations are adopting Agile
- IT managers who need to understand Agile well enough to lead Agile teams
- Freshers and new graduates entering the IT industry who want Agile skills from day one
- Anyone preparing for CSM, PSM, PMI-ACP or SAFe certification exams
Prerequisites — What You Need Before Joining
- No prior Agile experience required — the course starts from Agile Manifesto fundamentals
- Basic understanding of how software projects work is helpful but not mandatory
- For PMI-ACP: 2,000 hours of general project experience and 1,500 hours of Agile project experience required by PMI
- For CSM: no prerequisites — Scrum Alliance only requires course attendance and passing the online exam
Scrum vs Kanban vs SAFe — Understanding the Agile Landscape
🔄 Scrum — Sprint-Based Iterative Delivery
- Fixed-length Sprints (1-4 weeks) with defined events
- Three roles: Scrum Master, Product Owner, Dev Team
- Five events: Sprint, Planning, Daily Scrum, Review, Retro
- Best for: product development with evolving requirements
- Most widely used Agile framework globally and in India
- CSM and PSM are the most recognised Scrum certifications
- Foundation for SAFe and most other scaled Agile approaches
📌 Kanban — Flow-Based Continuous Delivery
- No fixed Sprints — work flows continuously through the board
- WIP (Work In Progress) limits to manage throughput
- Best for: operations, support, maintenance work
- Visualises workflow and identifies bottlenecks immediately
- Less prescriptive than Scrum — easier to adopt incrementally
- Often combined with Scrum as Scrumban for hybrid teams
- SAFe combines Scrum, Kanban and XP for enterprise Agile
Tools, Frameworks & Methodologies You Will Master
Jira
Backlog & sprint tracking
Azure DevOps
Microsoft Agile platform
Trello
Kanban visualisation
Scrum Board
Sprint management
Burndown Charts
Sprint progress tracking
Velocity Charts
Team performance
Planning Poker
Agile estimation
Sprint Calendar
Ceremony scheduling
Retrospective
Team improvement tool
User Stories
Requirements format
SAFe Framework
Enterprise Agile
Confluence
Team documentation
Certifications This Programme Prepares You For
CSM — Certified ScrumMaster
Scrum Alliance foundational Scrum Master credential
PSM I — Professional Scrum Master
Scrum.org's assessment-based Scrum credential
PMI-ACP
PMI Agile Certified Practitioner — most comprehensive Agile cert
SAFe Agilist (SA)
Leading SAFe — enterprise Agile framework certification
CSPO
Certified Scrum Product Owner by Scrum Alliance
CSM Advanced (A-CSM)
Advanced Scrum Master — next step after CSM
Detailed Curriculum — 8 Comprehensive Modules
The programme moves from Agile philosophy through Scrum mastery to Kanban, SAFe, and certification preparation. Sprint simulation exercises run throughout — not as a module at the end, but integrated into every relevant session so concepts are applied immediately after they are introduced.
1
Agile Foundations — The Manifesto, 12 Principles & Why Agile Exists
Understanding why Agile was created — and why the specific values and principles in the Manifesto were chosen — makes everything about Agile practice more intuitive and memorable. This module does not treat the Manifesto as a document to memorise for an exam. It treats it as a problem statement with a solution.
The pre-Agile world is covered first: the waterfall software projects of the 1990s, why long upfront planning consistently produced software that did not match user needs by the time it was delivered, and the specific failure patterns (requirements that changed, stakeholders who were not engaged until too late, teams working in isolation) that motivated 17 experienced practitioners to gather at Snowbird, Utah in 2001 and draft a different approach. The four Manifesto values are examined with genuine depth: Individuals and interactions over processes and tools (not abandoning processes, but recognising that rigid process compliance kills the human communication that produces good software); Working software over comprehensive documentation (not eliminating documentation, but recognising that documentation does not deliver value — working software does); Customer collaboration over contract negotiation (not eliminating contracts, but involving customers continuously rather than defining everything upfront and then holding them to it); Responding to change over following a plan (not abandoning planning, but building a planning approach that accommodates reality rather than pretending the future is knowable). Each of the 12 Principles is covered with a real-world application scenario — what does "sustainable pace" look like in practice? What does "simplicity — the art of maximising the work not done — is essential" actually mean on a project?
The distinction between the Agile mindset (a set of values and beliefs about how software should be developed) and Agile frameworks (specific practices like Scrum, Kanban, XP that implement the mindset) is established here because conflating them is one of the most common errors in both practice and examination contexts.
The pre-Agile world is covered first: the waterfall software projects of the 1990s, why long upfront planning consistently produced software that did not match user needs by the time it was delivered, and the specific failure patterns (requirements that changed, stakeholders who were not engaged until too late, teams working in isolation) that motivated 17 experienced practitioners to gather at Snowbird, Utah in 2001 and draft a different approach. The four Manifesto values are examined with genuine depth: Individuals and interactions over processes and tools (not abandoning processes, but recognising that rigid process compliance kills the human communication that produces good software); Working software over comprehensive documentation (not eliminating documentation, but recognising that documentation does not deliver value — working software does); Customer collaboration over contract negotiation (not eliminating contracts, but involving customers continuously rather than defining everything upfront and then holding them to it); Responding to change over following a plan (not abandoning planning, but building a planning approach that accommodates reality rather than pretending the future is knowable). Each of the 12 Principles is covered with a real-world application scenario — what does "sustainable pace" look like in practice? What does "simplicity — the art of maximising the work not done — is essential" actually mean on a project?
The distinction between the Agile mindset (a set of values and beliefs about how software should be developed) and Agile frameworks (specific practices like Scrum, Kanban, XP that implement the mindset) is established here because conflating them is one of the most common errors in both practice and examination contexts.
2
Scrum Framework — Roles, Events, Artefacts & the Sprint Lifecycle
Scrum is deliberately simple — the entire Scrum Guide is less than 20 pages. But that simplicity conceals significant depth in what each role, event and artefact is actually for and how it is properly executed. Most "failed Scrum" implementations fail not because Scrum doesn't work, but because one or more of these elements are implemented incorrectly or incompletely.
The three Scrum roles are covered with the nuance that exam questions and real-world practice require. The Product Owner is not a requirements analyst who writes user stories — the Product Owner is the accountable decision-maker for the product, responsible for the product backlog, for ordering it based on business value, and for ensuring the development team understands what is needed and why. The Scrum Master is not a project manager with a different title — the Scrum Master is a servant-leader who helps the team apply Scrum correctly, removes impediments, shields the team from interruptions, and coaches the organisation on Scrum adoption. The Development Team is not "the coders" — it is the self-organising, cross-functional group of professionals who collectively own the work of creating a done increment each Sprint.
The five Scrum events are practised through real simulation: Sprint Planning (how to select a sprint goal, how to determine what can be done in one sprint, how to create the sprint backlog), Daily Scrum (the 15-minute coordination event — not a status report to the Scrum Master, but a planning event for the development team), Sprint Review (demonstrating the increment to stakeholders and adapting the product backlog based on feedback — not a sign-off ceremony), and Sprint Retrospective (the team's regular opportunity to improve their own process — the most frequently neglected Scrum event and the one that matters most for long-term team performance). The three Scrum artefacts — Product Backlog, Sprint Backlog, Increment — are covered with their associated commitments: Product Goal, Sprint Goal, Definition of Done. The Definition of Done is covered in depth because it is one of the most examination-tested topics and one of the most commonly misunderstood in practice.
The three Scrum roles are covered with the nuance that exam questions and real-world practice require. The Product Owner is not a requirements analyst who writes user stories — the Product Owner is the accountable decision-maker for the product, responsible for the product backlog, for ordering it based on business value, and for ensuring the development team understands what is needed and why. The Scrum Master is not a project manager with a different title — the Scrum Master is a servant-leader who helps the team apply Scrum correctly, removes impediments, shields the team from interruptions, and coaches the organisation on Scrum adoption. The Development Team is not "the coders" — it is the self-organising, cross-functional group of professionals who collectively own the work of creating a done increment each Sprint.
The five Scrum events are practised through real simulation: Sprint Planning (how to select a sprint goal, how to determine what can be done in one sprint, how to create the sprint backlog), Daily Scrum (the 15-minute coordination event — not a status report to the Scrum Master, but a planning event for the development team), Sprint Review (demonstrating the increment to stakeholders and adapting the product backlog based on feedback — not a sign-off ceremony), and Sprint Retrospective (the team's regular opportunity to improve their own process — the most frequently neglected Scrum event and the one that matters most for long-term team performance). The three Scrum artefacts — Product Backlog, Sprint Backlog, Increment — are covered with their associated commitments: Product Goal, Sprint Goal, Definition of Done. The Definition of Done is covered in depth because it is one of the most examination-tested topics and one of the most commonly misunderstood in practice.
3
Product Backlog Management — User Stories, Estimation & Prioritisation
The quality of a Scrum team's product backlog is one of the strongest predictors of their delivery effectiveness. A well-managed backlog gives the team clear, appropriately-sized work items with understood acceptance criteria and business value priorities. A poorly managed backlog produces confused sprints, missed goals and frustrated stakeholders. This module teaches backlog management as a craft, not a clerical activity.
User stories are introduced as the primary format for expressing product backlog items: the "As a [user type], I want [goal], so that [benefit]" template provides structure without rigidity, and the real skill lies in writing stories that are independent, negotiable, valuable, estimable, small enough and testable — the INVEST criteria that distinguish useful user stories from requirements documents dressed up in story format. Acceptance criteria are covered as the specific, testable conditions that define when a story is done to the satisfaction of the Product Owner. The difference between "the system shall..." requirements language and acceptance criteria written in Given/When/Then (Gherkin) format is practised with real examples.
Agile estimation is covered through multiple techniques: story points (relative size estimation using Fibonacci numbers — 1, 2, 3, 5, 8, 13, 21), planning poker (the collaborative estimation game that uses the Fibonacci sequence and wisdom-of-the-crowd dynamics to reduce estimation bias), T-shirt sizing (for coarse-grained epic-level estimation), and affinity mapping (clustering stories by relative size without individual story discussion). Velocity — the amount of story points a team completes in a sprint — is introduced as the key metric for sprint planning and release forecasting. The difference between commitment-based planning (a team commits to completing specific stories in a sprint) and forecast-based planning (a team forecasts what they expect to complete, without the psychological pressure of commitment) is a nuanced but examination-relevant distinction that reflects real debates in the Agile community.
User stories are introduced as the primary format for expressing product backlog items: the "As a [user type], I want [goal], so that [benefit]" template provides structure without rigidity, and the real skill lies in writing stories that are independent, negotiable, valuable, estimable, small enough and testable — the INVEST criteria that distinguish useful user stories from requirements documents dressed up in story format. Acceptance criteria are covered as the specific, testable conditions that define when a story is done to the satisfaction of the Product Owner. The difference between "the system shall..." requirements language and acceptance criteria written in Given/When/Then (Gherkin) format is practised with real examples.
Agile estimation is covered through multiple techniques: story points (relative size estimation using Fibonacci numbers — 1, 2, 3, 5, 8, 13, 21), planning poker (the collaborative estimation game that uses the Fibonacci sequence and wisdom-of-the-crowd dynamics to reduce estimation bias), T-shirt sizing (for coarse-grained epic-level estimation), and affinity mapping (clustering stories by relative size without individual story discussion). Velocity — the amount of story points a team completes in a sprint — is introduced as the key metric for sprint planning and release forecasting. The difference between commitment-based planning (a team commits to completing specific stories in a sprint) and forecast-based planning (a team forecasts what they expect to complete, without the psychological pressure of commitment) is a nuanced but examination-relevant distinction that reflects real debates in the Agile community.
4
Sprint Simulation — Running Real Sprints from Planning to Retrospective
This module is the centrepiece of Aapvex's Agile programme — two complete, fully simulated Scrum sprints from initial product backlog through sprint planning, daily scrums, sprint review and retrospective. No other preparation approach produces the practical competency that actual sprint experience provides.
The simulation begins with a product backlog for a realistic software product (a field service management mobile application with a complex set of stakeholder needs). Students are assigned to Scrum teams, roles are assigned (rotating so every student experiences Product Owner, Scrum Master and Development Team member roles), and the full Sprint 1 lifecycle is run with the trainer facilitating and providing coaching interventions at key decision points. Sprint Planning tests whether students can genuinely define a Sprint Goal, select appropriate backlog items for the sprint capacity, and decompose user stories into development tasks. Daily Scrums are run in real time — students experience the difference between a 15-minute effective coordination event and a status meeting that drifts into 45-minute problem-solving discussions. The Sprint Review involves presenting the increment to simulated stakeholders (played by the trainer) who have opinions, feedback and requests that require the Product Owner to make real backlog decisions. The Retrospective uses the Start-Stop-Continue format and produces actionable improvement items that are actually implemented in Sprint 2.
Sprint 2 runs with the improvements from Sprint 1 retrospective applied — so students experience the continuous improvement dynamic that makes sustained Scrum teams more effective over time. Common Scrum failure modes are deliberately introduced in the simulation: a stakeholder who tries to add scope to the current Sprint, a team member who is not participating in Daily Scrums, a Product Owner who cannot make backlog decisions, a Scrum Master who solves problems rather than empowering the team to solve them — and students practice the appropriate responses to each.
The simulation begins with a product backlog for a realistic software product (a field service management mobile application with a complex set of stakeholder needs). Students are assigned to Scrum teams, roles are assigned (rotating so every student experiences Product Owner, Scrum Master and Development Team member roles), and the full Sprint 1 lifecycle is run with the trainer facilitating and providing coaching interventions at key decision points. Sprint Planning tests whether students can genuinely define a Sprint Goal, select appropriate backlog items for the sprint capacity, and decompose user stories into development tasks. Daily Scrums are run in real time — students experience the difference between a 15-minute effective coordination event and a status meeting that drifts into 45-minute problem-solving discussions. The Sprint Review involves presenting the increment to simulated stakeholders (played by the trainer) who have opinions, feedback and requests that require the Product Owner to make real backlog decisions. The Retrospective uses the Start-Stop-Continue format and produces actionable improvement items that are actually implemented in Sprint 2.
Sprint 2 runs with the improvements from Sprint 1 retrospective applied — so students experience the continuous improvement dynamic that makes sustained Scrum teams more effective over time. Common Scrum failure modes are deliberately introduced in the simulation: a stakeholder who tries to add scope to the current Sprint, a team member who is not participating in Daily Scrums, a Product Owner who cannot make backlog decisions, a Scrum Master who solves problems rather than empowering the team to solve them — and students practice the appropriate responses to each.
5
Kanban, Lean & Flow-Based Agile Approaches
Not all work fits neatly into two-week sprints. Operations teams, support functions, maintenance work, and ongoing service delivery often benefit more from Kanban's continuous flow approach than from Scrum's sprint structure. Understanding when to use Kanban instead of (or alongside) Scrum is an important practical skill and a significant exam topic.
Kanban's four core principles are covered: start with what you do now (Kanban is evolutionary, not revolutionary — you improve existing processes rather than replacing them), agree to pursue incremental, evolutionary change, respect current roles and responsibilities, and encourage acts of leadership at all levels. The six core practices of Kanban are taught and applied hands-on: visualising the workflow (designing a Kanban board that accurately represents how work actually moves through the process), limiting work in progress (the counterintuitive but empirically proven practice of artificially constraining the number of active items to improve throughput), managing flow (ensuring work moves smoothly from start to done without accumulating in queues), making process policies explicit (agreeing on entry criteria for each column so decisions about moving work are consistent), implementing feedback loops (the Kanban cadences: service delivery review, replenishment meeting, daily standup, operations review, risk review), and improving collaboratively using models and the scientific method.
The flow metrics that make Kanban analytically powerful are practised: Cycle Time (how long a work item takes from start to done), Throughput (how many items are completed per unit of time), Work In Progress (the number of items currently active), and Work Item Age (how long currently active items have been in progress — the primary early warning indicator of items that are stuck or forgotten). Cumulative Flow Diagrams are covered as the visual tool that makes all these metrics visible simultaneously. The Scrumban hybrid — combining Scrum's sprint and retrospective cadences with Kanban's continuous flow and WIP limits — is introduced as a popular real-world combination for teams that need both the regularity of sprints and the flexibility of flow.
Kanban's four core principles are covered: start with what you do now (Kanban is evolutionary, not revolutionary — you improve existing processes rather than replacing them), agree to pursue incremental, evolutionary change, respect current roles and responsibilities, and encourage acts of leadership at all levels. The six core practices of Kanban are taught and applied hands-on: visualising the workflow (designing a Kanban board that accurately represents how work actually moves through the process), limiting work in progress (the counterintuitive but empirically proven practice of artificially constraining the number of active items to improve throughput), managing flow (ensuring work moves smoothly from start to done without accumulating in queues), making process policies explicit (agreeing on entry criteria for each column so decisions about moving work are consistent), implementing feedback loops (the Kanban cadences: service delivery review, replenishment meeting, daily standup, operations review, risk review), and improving collaboratively using models and the scientific method.
The flow metrics that make Kanban analytically powerful are practised: Cycle Time (how long a work item takes from start to done), Throughput (how many items are completed per unit of time), Work In Progress (the number of items currently active), and Work Item Age (how long currently active items have been in progress — the primary early warning indicator of items that are stuck or forgotten). Cumulative Flow Diagrams are covered as the visual tool that makes all these metrics visible simultaneously. The Scrumban hybrid — combining Scrum's sprint and retrospective cadences with Kanban's continuous flow and WIP limits — is introduced as a popular real-world combination for teams that need both the regularity of sprints and the flexibility of flow.
6
Scaling Agile — SAFe, LeSS & Enterprise Agile Frameworks
A single Scrum team of 7-10 people can be highly effective. But what happens when you have 50, 100 or 500 people working on related products? The scaling challenge — maintaining Agile principles and practices when multiple teams must coordinate their work — is one of the most important topics for experienced practitioners and a growing examination focus.
SAFe (Scaled Agile Framework) is covered as the most widely adopted enterprise Agile framework in India. The SAFe conceptual architecture is explained: the Team Level (where individual Scrum teams operate in normal two-week sprints), the Programme Level (where multiple teams synchronise through the Agile Release Train — a virtual organisation of 50-125 practitioners who plan together in Programme Increments of 8-12 weeks), the Large Solution Level (for the most complex products requiring multiple ARTs), and the Portfolio Level (aligning strategy and investment to the work being done). The Programme Increment (PI) Planning event — the all-hands planning ceremony where all teams on an ART plan their work for the next PI together — is one of the most significant and exam-tested SAFe practices. PI Planning requires physical (or virtual) co-location of all teams, produces team PI objectives and a consolidated programme board that makes dependencies and milestones visible across all teams, and is described by many SAFe practitioners as the single highest-value regular event in their organisations.
LeSS (Large-Scale Scrum) is introduced as the alternative scaling framework that takes a more minimalist approach — extending Scrum to multiple teams with as few additional roles, artefacts and events as possible. The fundamental LeSS principle is that scaling should be done by applying Scrum more deeply, not by adding process overhead. The Scrum@Scale framework by Jeff Sutherland (Scrum co-creator) is also introduced. For exam purposes, SAFe terminology and practices are the most commonly tested, but understanding the principles behind multiple frameworks is more valuable than memorising any single framework's vocabulary.
SAFe (Scaled Agile Framework) is covered as the most widely adopted enterprise Agile framework in India. The SAFe conceptual architecture is explained: the Team Level (where individual Scrum teams operate in normal two-week sprints), the Programme Level (where multiple teams synchronise through the Agile Release Train — a virtual organisation of 50-125 practitioners who plan together in Programme Increments of 8-12 weeks), the Large Solution Level (for the most complex products requiring multiple ARTs), and the Portfolio Level (aligning strategy and investment to the work being done). The Programme Increment (PI) Planning event — the all-hands planning ceremony where all teams on an ART plan their work for the next PI together — is one of the most significant and exam-tested SAFe practices. PI Planning requires physical (or virtual) co-location of all teams, produces team PI objectives and a consolidated programme board that makes dependencies and milestones visible across all teams, and is described by many SAFe practitioners as the single highest-value regular event in their organisations.
LeSS (Large-Scale Scrum) is introduced as the alternative scaling framework that takes a more minimalist approach — extending Scrum to multiple teams with as few additional roles, artefacts and events as possible. The fundamental LeSS principle is that scaling should be done by applying Scrum more deeply, not by adding process overhead. The Scrum@Scale framework by Jeff Sutherland (Scrum co-creator) is also introduced. For exam purposes, SAFe terminology and practices are the most commonly tested, but understanding the principles behind multiple frameworks is more valuable than memorising any single framework's vocabulary.
7
Agile Metrics, Reporting & Managing Stakeholders in Agile Projects
One of the most common friction points when organisations adopt Agile is the question of reporting: "If you don't have a project plan, how do I know what you are delivering and when?" This module covers Agile metrics and stakeholder management — how to give executives and stakeholders the visibility they need without reverting to the command-and-control reporting that undermines agile ways of working.
Agile-friendly metrics are covered: velocity (average story points completed per sprint — used for sprint planning and release forecasting, not for comparing teams or evaluating individuals), burndown charts (displaying remaining work in a sprint against time — the most visible Agile progress indicator), burnup charts (displaying completed work and total scope over time — more honest than burndown because they make scope changes visible), and cumulative flow diagrams (showing work item distribution across workflow stages over time). The specific failure modes of misapplying these metrics are covered because metric abuse is rampant: using velocity to compare teams (destroys collaborative estimation), publishing individual team velocities to executives (creates velocity inflation), treating the burndown as a commitment rather than a forecast (creates the same Gantt-chart-over-Scrum dynamic that Agile was designed to escape).
Managing stakeholders in Agile contexts is covered as a specific skill because Agile's transparency — making progress and impediments visible to anyone — can be uncomfortable for stakeholders accustomed to managed information. Sprint Reviews as stakeholder engagement events (how to structure a review that generates genuine feedback rather than just a demonstration), managing the tension between the Product Owner's backlog authority and stakeholders who want to direct the team directly, and communicating release forecasts using cone of uncertainty and probabilistic planning rather than false-precision Gantt charts are all covered with real scenarios.
Agile-friendly metrics are covered: velocity (average story points completed per sprint — used for sprint planning and release forecasting, not for comparing teams or evaluating individuals), burndown charts (displaying remaining work in a sprint against time — the most visible Agile progress indicator), burnup charts (displaying completed work and total scope over time — more honest than burndown because they make scope changes visible), and cumulative flow diagrams (showing work item distribution across workflow stages over time). The specific failure modes of misapplying these metrics are covered because metric abuse is rampant: using velocity to compare teams (destroys collaborative estimation), publishing individual team velocities to executives (creates velocity inflation), treating the burndown as a commitment rather than a forecast (creates the same Gantt-chart-over-Scrum dynamic that Agile was designed to escape).
Managing stakeholders in Agile contexts is covered as a specific skill because Agile's transparency — making progress and impediments visible to anyone — can be uncomfortable for stakeholders accustomed to managed information. Sprint Reviews as stakeholder engagement events (how to structure a review that generates genuine feedback rather than just a demonstration), managing the tension between the Product Owner's backlog authority and stakeholders who want to direct the team directly, and communicating release forecasts using cone of uncertainty and probabilistic planning rather than false-precision Gantt charts are all covered with real scenarios.
8
CSM, PSM & PMI-ACP Exam Preparation — Getting Certified
Agile certifications validate your knowledge and open doors that experience alone sometimes cannot. This module covers the three most valuable Agile certifications in the Indian market and prepares you specifically for each.
The CSM (Certified ScrumMaster) from Scrum Alliance requires completing a Scrum Alliance-approved training programme (which Aapvex provides) and passing a 50-question online exam. The exam is open-book, has a 60-minute time limit, and requires 74% to pass. CSM questions test understanding of Scrum framework, Scrum Master role responsibilities, team dynamics, and Agile principles — not trick questions, but questions that require genuine understanding of what Scrum is for and how it works. The CSM is the most widely listed Agile certification in Indian IT job descriptions and the logical starting point for most practitioners.
The PSM I (Professional Scrum Master I) from Scrum.org is the assessment-based alternative to CSM — no training course is required, only passing the exam. The PSM I is generally considered more rigorous than CSM because it cannot be passed with surface-level familiarity. With 80 questions in 60 minutes (no time to look things up), it rewards deep, internalised understanding of Scrum. The passing score is 85%. Aapvex prepares students for PSM I with the same rigour applied to CSM.
The PMI-ACP (Agile Certified Practitioner) from PMI is the most comprehensive and prestigious Agile credential — it covers Scrum, Kanban, Lean, XP, DSDM and other agile approaches in a single credential. It requires 2,000 hours of general project experience and 1,500 hours of agile project experience, plus 21 contact hours of Agile training. The exam has 120 questions covering seven domains: Agile Principles and Mindset, Value-Driven Delivery, Stakeholder Engagement, Team Performance, Adaptive Planning, Problem Detection and Resolution, and Continuous Improvement. Full practice question banks and mock exams for all three certifications are included in the programme.
The CSM (Certified ScrumMaster) from Scrum Alliance requires completing a Scrum Alliance-approved training programme (which Aapvex provides) and passing a 50-question online exam. The exam is open-book, has a 60-minute time limit, and requires 74% to pass. CSM questions test understanding of Scrum framework, Scrum Master role responsibilities, team dynamics, and Agile principles — not trick questions, but questions that require genuine understanding of what Scrum is for and how it works. The CSM is the most widely listed Agile certification in Indian IT job descriptions and the logical starting point for most practitioners.
The PSM I (Professional Scrum Master I) from Scrum.org is the assessment-based alternative to CSM — no training course is required, only passing the exam. The PSM I is generally considered more rigorous than CSM because it cannot be passed with surface-level familiarity. With 80 questions in 60 minutes (no time to look things up), it rewards deep, internalised understanding of Scrum. The passing score is 85%. Aapvex prepares students for PSM I with the same rigour applied to CSM.
The PMI-ACP (Agile Certified Practitioner) from PMI is the most comprehensive and prestigious Agile credential — it covers Scrum, Kanban, Lean, XP, DSDM and other agile approaches in a single credential. It requires 2,000 hours of general project experience and 1,500 hours of agile project experience, plus 21 contact hours of Agile training. The exam has 120 questions covering seven domains: Agile Principles and Mindset, Value-Driven Delivery, Stakeholder Engagement, Team Performance, Adaptive Planning, Problem Detection and Resolution, and Continuous Improvement. Full practice question banks and mock exams for all three certifications are included in the programme.
Hands-On Projects & Simulation Exercises
Every concept in this programme is applied through realistic simulation exercises and case study projects. By the end you will have a portfolio of documented project work that proves your practical competency to employers and certification bodies alike.
🔄 Sprint 1 & 2 Full Simulation
Two complete simulated Scrum sprints from product backlog through planning, daily scrums, review and retrospective. Rotating roles ensure every student experiences Scrum Master, Product Owner and team member perspectives.
📋 Product Backlog Creation
Create a complete product backlog for a simulated mobile application — writing 20+ user stories in INVEST format with acceptance criteria, estimating in story points using planning poker, and prioritising using MoSCoW and weighted shortest job first.
📊 Kanban Board Design & Flow Analysis
Design and populate a Kanban board for a simulated IT support team — setting WIP limits, calculating cycle time and throughput from historical data, building a cumulative flow diagram and identifying bottlenecks.
🏗️ PI Planning Simulation
Participate in a simulated SAFe Programme Increment planning session — team PI objectives, programme board dependency mapping, risk identification and ROAM (Resolved, Owned, Accepted, Mitigated) classification.
📈 Agile Metrics Dashboard
Build a velocity chart, burndown chart and cumulative flow diagram from sprint data, and write a sprint review narrative that communicates Agile progress to simulated non-technical stakeholders.
📝 CSM / PSM Mock Exams × 3
Three full mock examinations in CSM and PSM I format with comprehensive review, covering all Scrum Guide topics, common failure scenarios and the specific question types that appear in each certification exam.
Career Opportunities & Salaries After Agile & Scrum
Agile skills are in demand across virtually every technology and increasingly non-technology sector in India. The specific role titles and salary bands depend on seniority and domain, but Agile fluency consistently provides a meaningful salary premium over equivalent experience without it.
Scrum Master
₹8L–₹18L/yr
Facilitating Scrum, coaching teams, removing impediments. One of the most consistently in-demand roles in Indian IT.
Agile Coach
₹18L–₹35L/yr
Coaching organisations and multiple teams on Agile transformation. Requires 4+ years Scrum Master experience.
Product Owner
₹10L–₹22L/yr
Owning the product backlog, defining user stories, making prioritisation decisions. High demand at product companies.
Agile Project Manager
₹12L–₹25L/yr
Managing Agile delivery, hybrid PM roles. PMP + Agile combination is highly valued.
Release Train Engineer
₹18L–₹35L/yr
Facilitating SAFe Agile Release Trains. In demand at large enterprises running SAFe.
Head of Agile Delivery
₹30L–₹55L+/yr
Senior Agile leadership. Programme-level Agile transformation and delivery governance.
"I had been using Agile vocabulary for two years without really understanding it. The sprint simulation sessions at Aapvex were genuinely eye-opening — I realised how many things my team was doing wrong because we had never been properly trained. The module on Scrum failure modes was worth the entire course fee by itself. Got the Scrum Master role at a product startup in Pune four weeks after completing the CSM exam. The salary was 40% higher than my previous BA role."— Sneha Kulkarni, Scrum Master, Product Startup, Pune
Industries Actively Hiring Agile & Scrum Professionals
- Software Development and IT Services — Agile is the standard delivery framework at virtually every Indian IT company
- Banking and Financial Services — digital banking, fintech and insurance product development
- E-commerce and Product Companies — Flipkart, Swiggy, Zepto, PhonePe and every product company runs Agile
- Pharma and Healthcare Technology — increasingly adopting Agile for software development and clinical operations
- Manufacturing — Industry 4.0 projects, IoT product development, embedded systems teams
- Telecom — 5G product development, digital transformation programmes
- Consulting — Big 4 and management consultancies helping clients with Agile transformations
- Government Technology — DigiYatra, CoWIN and other government digital initiatives used Agile
- EdTech — one of the fastest-growing Agile employer sectors in India
- HR Technology — HRMS product companies and digital HR transformation projects
Frequently Asked Questions — Agile & Scrum
What is the difference between Agile and Scrum — are they the same thing?
Agile and Scrum are related but not the same. Agile is a mindset and philosophy — a set of values and principles (articulated in the Agile Manifesto) about how software should be developed: iteratively, collaboratively, with frequent customer feedback and a willingness to adapt plans when reality changes. Scrum is a specific framework that implements the Agile principles through concrete practices: two-week sprints, three defined roles, five prescribed events and three artefacts. Kanban, XP (Extreme Programming), DSDM and SAFe are other frameworks that also implement Agile principles, each with different practices and emphases. Saying you "do Agile" usually means you use one of these frameworks. Saying you "do Scrum" means you specifically use the Scrum framework. You can do Scrum and still not embody the Agile mindset, which is why understanding the underlying principles matters as much as knowing the Scrum ceremonies.
What is a Scrum Master and what do they actually do every day?
A Scrum Master is a servant-leader responsible for ensuring the Scrum team understands and applies Scrum correctly, and for removing the impediments that prevent the team from delivering their sprint goal. A good day for a Scrum Master might include: facilitating a 15-minute Daily Scrum that produces a clear team plan for the day, following up on an impediment from yesterday (chasing IT for a system access issue that has been blocking a developer), having a coaching conversation with a Product Owner who is struggling to say no to stakeholder requests that would disrupt the current sprint, participating in a backlog refinement session to help the team understand upcoming stories, and attending a cross-team dependency discussion to ensure the next sprint does not hit a coordination blocker. What a Scrum Master does not do: assign tasks to team members, report status to management on behalf of the team, or make product decisions. The Scrum Master's job is to make the system work better — not to manage the people within it.
How long does it take to become a certified Scrum Master?
The CSM (Certified ScrumMaster) can technically be obtained in 2 days — Scrum Alliance allows training providers to certify candidates after a 2-day workshop and an online exam. However, the 2-day CSM course produces candidates who have been exposed to Scrum, not practitioners who can actually run it effectively. Aapvex's 6-8 week programme produces Scrum Masters who have run sprint simulations, practiced backlog management, facilitated retrospectives and dealt with common Scrum anti-patterns — a much more useful preparation for the real job. The online CSM exam (50 questions, 60 minutes, open-book) can be taken immediately after completing the training course requirement. Most well-prepared candidates pass on the first attempt.
What is the salary of a Scrum Master in Pune and Bangalore?
Scrum Master salaries in Indian IT cities depend primarily on seniority and industry. Entry-level Scrum Masters (1-2 years, CSM certified) in Pune and Bangalore earn Rs.7-12 LPA. Mid-level Scrum Masters with 3-5 years of experience and multiple successful team coaching engagements earn Rs.12-20 LPA. Senior Scrum Masters who can coach multiple teams simultaneously and support Agile transformations at organisational scale earn Rs.18-30 LPA. Agile Coaches who work at the programme and portfolio level earn Rs.25-40 LPA. The highest salaries are at product companies (Flipkart, Swiggy, PhonePe, CRED) and multinational IT services firms with large Agile delivery practices.
What is the difference between CSM and PSM I certifications?
The CSM (Certified ScrumMaster) is issued by the Scrum Alliance and requires completing an approved training course (Aapvex's programme qualifies) before taking the online exam. It is more widely listed in Indian job descriptions and is the most common first Agile certification. The PSM I (Professional Scrum Master I) is issued by Scrum.org and is purely assessment-based — no training course is required, you simply pay and take the exam. The PSM I is generally considered more rigorous: 80 questions in 60 minutes, 85% passing score, no open-book facility. Many practitioners hold both as complementary credentials. In terms of employer recognition, both are well-accepted in India. In terms of actual knowledge demonstration, the PSM I is harder to fake than the CSM and therefore slightly more respected by technical hiring managers who understand the distinction.
What is SAFe and when do I need to know it?
SAFe (Scaled Agile Framework) is a framework for applying Agile and Lean principles at enterprise scale — when hundreds or thousands of people need to work in coordinated Agile ways across multiple teams and products. You need to know SAFe if you work at, or want to work at, a large organisation that has adopted SAFe — and increasingly, large Indian IT services firms and their enterprise clients fall into this category. TCS, Infosys, Wipro, HCL and Accenture all have SAFe practices. The entry-level SAFe certification is Leading SAFe (SAFe Agilist), a 2-day programme and exam. Aapvex's Agile & Scrum programme covers SAFe concepts in depth sufficient for exam and interview preparation, and advises on whether pursuing the full Leading SAFe certification makes sense for your specific career path.
Can I join the Agile course if I have no IT background?
Yes — Agile is increasingly adopted beyond IT, and the Agile & Scrum course is valuable for HR, marketing, operations and business professionals whose organisations are adopting Agile ways of working. The core Agile concepts — iterative delivery, customer collaboration, responding to change — apply to any knowledge work, not just software development. That said, the course does reference software development as the primary context for examples because Agile originated there and most certification questions are framed in software contexts. Non-IT professionals typically find the course accessible and highly applicable to their own work contexts after an initial adjustment to the software-centric examples.
How is Agile different from traditional project management and which is better?
Neither approach is universally better — the right choice depends on the nature of the work. Traditional waterfall project management works well when requirements are stable and well-understood from the start, when the technology is well-proven and carries low implementation risk, and when contractual or regulatory requirements mandate detailed upfront planning and formal approval processes (infrastructure projects, construction, certain government contracts). Agile works better when requirements are evolving or uncertain, when early delivery of value is important, when stakeholder feedback during development is feasible and valuable, and when the team has the skills and maturity to self-organise effectively. Most real projects benefit from a hybrid approach — rigorous governance and planning where it is genuinely needed, iterative delivery where flexibility improves outcomes. Both PMP and Agile skills make a project professional more capable than either alone.
What is a Product Owner and how is that role different from a Project Manager?
The Product Owner and Project Manager serve fundamentally different purposes, though both are involved in delivering projects. The Project Manager manages the project — the timeline, the budget, the resources, the risks, the stakeholder communication, the change control process. The Project Manager's job is to deliver the project successfully. The Product Owner manages the product — the backlog, the features, the priorities, the business value decisions. The Product Owner's job is to maximise the value of the work the development team does. In a Scrum team, there is no formal Project Manager role — the project management responsibilities are distributed between the Product Owner (priority and scope decisions), the Scrum Master (process and impediment management) and the Development Team (how and how long). In hybrid environments, a Project Manager might also perform Product Owner duties, or the two roles might be held by different people with clear boundary definitions.
How do I enrol in the Agile & Scrum course at Aapvex?
Call or WhatsApp 7796731656. Our counsellor will ask about your current role, experience level and certification goals to recommend the right preparation strategy — whether to target CSM first, PSM I, PMI-ACP, or a combination. A free orientation session is available where you can experience the teaching style and ask questions before committing. You can also fill out the contact form at aapvex.com and we will reach you within 2 hours.