agile for pms

Let me save you three months of confusion. Most PM courses teach Agile as a methodology — a set of ceremonies, roles, and artifacts you follow by the book. Scrum Guide in one hand, Jira in the other, sprint planning on Monday, retro on Friday, story points for everything.

That is not how Agile works in real product teams. Not in Bangalore, not in Gurgaon, not anywhere that ships real products to real users.

What actually matters for PMs is not whether you run “correct” Scrum. It is whether your team can move fast, learn from users, and change direction without everything falling apart. That is the entire point. Everything else is implementation detail.

The PM is not the Scrum Master

This is the first confusion to clear up. In Agile orthodoxy, three roles exist: Product Owner, Scrum Master, and Development Team. The PM role does not appear in the Scrum Guide at all.

In practice, here is how it works at most Indian product companies:

Here is the actual division of responsibility in teams that work well:

Product Manager — Owns the what and why. Defines the problem, prioritizes the backlog based on user and business value, writes clear requirements, and makes trade-off decisions. The PM exists across Talvinder’s 5D model — Discovery, Decide, Design, Develop, Deploy — but their primary weight is in the first three.

Product Owner — In many Indian companies, this is the same person as the PM. When it is a separate role, the PO handles the day-to-day sprint-level decisions: acceptance criteria, story-level prioritization, answering developer questions during the sprint. The PO takes direction from the PM and delivers at the iteration level.

Scrum Master — Owns the how of the process. Removes blockers, facilitates ceremonies, protects the team from scope creep mid-sprint. This is often the engineering manager or a senior developer. It should almost never be the PM.

If you are a PM running daily standups, stop. Hand that to the EM or a senior engineer. Your job is to make sure the team is building the right thing, not to check whether they updated their Jira tickets.

What Agile actually means for your daily work

Strip away the ceremony names and role titles. Agile, for a PM, comes down to four principles that change how you work:

1. Ship small, learn fast.

Instead of spending three months writing a spec, three months building, and three months testing — you ship something usable every two weeks. Not because two weeks is magic, but because shorter cycles mean faster feedback. You find out you are wrong in two weeks instead of nine months.

2. Embrace changing requirements.

This is the one that traditional project managers hate. In waterfall, a change in requirements is a failure of planning. In Agile, it is expected. Your users will tell you something you did not anticipate. The market will shift. A competitor will launch something. Your job is not to prevent change — it is to make change cheap.

3. Working software over documentation.

This does not mean “no documentation.” It means a working prototype that users can touch is worth more than a fifty-page PRD that nobody reads. Write enough to align the team. Then build and validate.

4. Respond to reality, not the plan.

The sprint backlog is a plan. The retrospective is where you confront whether the plan was right. If your team treats sprint commitments as sacred and never adjusts, you are doing waterfall in two-week increments. That is not Agile. That is a costume.

Scrum vs Kanban: when to use which

Most teams default to Scrum without thinking about whether it fits. Here is a simple heuristic:

Use Scrum when you have a defined set of features to build, clear sprint goals, and a team that benefits from the rhythm of plan-build-review cycles. Scrum works well for product teams building new features where you need to protect focus — the sprint boundary stops stakeholders from changing priorities every day.

Use Kanban when you have continuous flow work — bug fixes, operational tasks, support engineering, or platform teams where priorities shift daily. Kanban has no sprint boundaries. Work flows through columns (To Do, In Progress, Done) with a limit on how many items can be in progress at once. The WIP limit is the entire point of Kanban — without it, you just have a to-do list on a board.

Use neither dogmatically. Most good teams run a hybrid. Scrum for feature development sprints, Kanban for the operational work that runs alongside. The teams I have seen fail are the ones that pick a methodology and follow it religiously even when it does not fit their context.

That Slack thread captures a pattern I see constantly. The fix is almost never “bigger sprints” or “more story points.” It is separating work types so each has the right process.

The ceremonies that actually matter

Scrum prescribes five ceremonies. In practice, three of them drive most of the value. Two of them are frequently done so badly they waste everyone’s time.

Sprint planning — make it count. This is where the PM’s preparation matters most. Come with prioritized stories, clear acceptance criteria, and context on why each story matters. If the team is asking “what does this story mean?” during planning, you have failed your prep. One sprint of investment into grooming stories before planning saves you hours of confusion during the sprint.

Retrospective — the only ceremony you cannot skip. Retros are where teams get better. If your retro is “what went well / what went badly / action items” and the action items never get done, your retro is theater. A good retro picks one thing to change next sprint and actually changes it. One real improvement per sprint compounds into a fundamentally better team within a quarter.

Daily standup — keep it under ten minutes or kill it. Standups are status updates. If they run longer than ten minutes, people are problem-solving in the standup instead of taking it offline. The format is: what I did, what I am doing, what is blocking me. If nothing is blocking anyone, the standup can be async on Slack. Many good teams have moved to async standups and reclaimed thirty minutes a day.

Sprint review / demo — useful, often skipped. This is where you show stakeholders what the team built. When it works, it creates alignment and builds trust. When it is skipped, stakeholders lose visibility and start asking for status updates in other meetings, which wastes more time than the demo would have.

Backlog grooming — the PM’s real job. Not a ceremony in the original Scrum Guide, but the most important PM ritual. Spend two to three hours a week refining the next sprint’s stories: writing acceptance criteria, splitting stories that are too large, adding context, and pre-answering questions. Teams that groom well plan fast. Teams that do not groom spend their entire sprint planning meeting writing stories on the fly.

Story points, velocity, and estimation theater

Story points are the most misunderstood concept in Agile. Here is what you need to know:

Story points measure effort and complexity, not time. A 3-point story is not “3 days of work.” It is “roughly twice as complex as a 1-point story and half as complex as a 5-point story.” The Fibonacci sequence (1, 2, 3, 5, 8, 13) exists because humans are bad at precise estimation but decent at relative estimation.

Velocity is a planning tool, not a performance metric. If your team’s velocity is 20 points per sprint, that helps you plan how much to commit next sprint. It does not mean anything about whether the team is “good” or “bad.” The moment a manager starts comparing velocity across teams or using it in performance reviews, the team will inflate their estimates and velocity becomes meaningless.

Estimation is guessing. Accept this. The purpose of estimation is not accuracy — it is to surface disagreements. When one developer says “this is a 2” and another says “this is an 8,” the valuable conversation is not about the number. It is about the different assumptions they have about scope and complexity. That conversation is the point.

If your team spends more than five minutes estimating a single story, something is wrong. Either the story is too vague (go groom it) or the team is over-thinking it (use t-shirt sizes and move on).

When to break the rules

Agile is a set of principles, not commandments. Here are the situations where experienced PMs deviate:

Skip the sprint structure for exploration work. If your team is in early discovery — prototyping, validating hypotheses, talking to users — forcing a sprint structure adds overhead without value. Use time-boxed experiments instead. “We have two weeks to test three hypotheses” is more useful than “Sprint 14 goal: validate market fit.”

Use deadlines when they are real. Agile purists will tell you that sprints should not have hard deadlines. This is naive. If you are launching before Diwali because that is your sales window, the deadline is real and the team needs to know it. Work backward from the deadline, cut scope aggressively, and be honest about what is achievable. Pretending the deadline does not exist is not Agile — it is denial.

Ditch story points for senior teams. Teams that have worked together for more than a year often have enough shared context that they can eyeball whether a sprint is overloaded. Estimation ceremonies become low-value. Some of the best teams I have seen use a simple count of stories (with a rule that no story is larger than a certain size) instead of story points.

Run without a Scrum Master. If your engineering team is disciplined and your EM is competent, you do not need a dedicated Scrum Master. This role exists to coach teams that are new to Agile. Mature teams self-organize. Paying someone full-time to facilitate ceremonies for a team that already knows how to run them is a waste.

The cargo cult problem

The biggest risk with Agile in India is cargo cult adoption. A company reads the Scrum Guide, buys Jira licenses, renames the project manager to “Scrum Master,” and declares itself Agile. Nothing changes about how decisions are made, how priorities are set, or how the team learns from users. The ceremonies exist, but the principles do not.

You can spot cargo cult Agile by three signs:

1. Sprints end, but nothing ships to users. The team completes stories and moves tickets to “Done,” but the work sits in staging for weeks. This is waterfall with Jira boards.

2. Retros happen, but nothing changes. The team lists problems, writes action items on sticky notes, and forgets them by Tuesday. The same problems appear in every retro for six months.

3. The backlog is a graveyard. There are 400 stories in the backlog, half of them six months old, none of them groomed. Nobody prunes it because that would mean making hard prioritization decisions. The backlog is not a plan — it is an anxiety list.

If this describes your team, the fix is not “better Agile.” The fix is going back to first principles: What problem are we solving? Who are we solving it for? How will we know if we solved it? Those questions do not need Scrum. They need product thinking.

Test yourself

Where to go next

• The specs that drive sprint work: Writing PRDs
• How to decide what goes into the sprint: Prioritization Frameworks
• The bigger picture Agile serves: Product Vision & Strategy
• Measuring what your sprints produce: Metrics & KPIs