In this article, I will address What changes when you AI empower a Product.

When an Agile Professional thinks about AI, it is often as a “productivity enhancer”. We look at AI as something that can reduce our effort. AI indeed does that job. But more importantly, AI is rapidly changing  the products we use every day. For example, search engines summarize answers instead of simply displaying links. Business applications recommend actions instead of just presenting dashboards. Streaming platforms recommend what show you can watch next. Development tools generate code.  And now in addition, AI agents are beginning to execute tasks on our behalf.

It is tempting to look at this as simply another technology shift—similar to moving applications to the cloud or making them mobile-enabled.

But I believe the change is more fundamental.

When we add AI to a product, we don’t just change the technology behind the product. We often need to change entire product behavior

Traditional software was largely designed to follow predefined instructions. AI-empowered products can interpret, generate, recommend, reason, and, increasingly with Agentic AI coming in picture, these products can act.

As Agile Professionals or even Product Specialists, we need to understand how AI-empowered products transition from traditional data crunching and display to understanding impact. Read on the article to understand this shift better

From Executing Commands to Understanding Intent

Traditional software expects users to understand how the application works. The user performs action, and the Product or Software responds

Imagine booking a holiday using a conventional travel application. (Think MakeMyTrip or something similar) You, as the user, have to select a destination, enter dates, apply filters for price and hotel category, compare options, and gradually build your itinerary.

The application is very good at executing the instructions you provide. But it does not customize the itinerary for you.

Now imagine telling an AI-empowered travel application:

“We have five days in Sri Lanka. We enjoy wildlife and history, don’t want long drives and would like two days near a good beach. Suggest an itinerary.”

The user has expressed an intent, not provided a sequence of commands.

The AI needs to interpret that intent, understand the constraints, consider alternatives and generate an appropriate response.

This represents an important shift:

Traditional products ask: “What does the user want to do? / what steps will help the user”

AI-empowered products can increasingly ask: “What is the user trying to achieve?”

With this shift from user actions to user intention, we now need to rethink entire customer journeys rather than simply adding AI to existing screens.

From Deterministic to Probabilistic Behavior

This is another fundamental difference.

Traditional software is predominantly deterministic.

If a banking system is programmed to calculate interest using a particular formula, we expect the same inputs to produce the same output every time. Even if we make a mistake in the formula, the same wrong answer will be displayed every time

We can broadly describe this as:

Input → Rules → Expected Output

Generative AI does not always behave this way.

Ask an AI system to summarize a customer complaint twice, and you may receive two slightly different summaries. Both could be perfectly acceptable.

Ask it to recommend the next best action for a salesperson, and there may be several reasonable answers.

And occasionally, AI hallucinates. This means that the AI may produce an answer that sounds convincing but is simply wrong.

AI product behavior therefore looks more like:

Input + Context + Model → Probable Output

This has a huge shift in product behavior.

For many AI capabilities, we cannot simply ask:

“Did the system produce the correct answer?”

We also need to ask:

“How good was the answer?” (Was the itinerary suitable ?/Was the new show recommended by the streaming service relatable? / Did the AI-based customer agent really help the complainant)

This shift will eventually impact the entire product life cycle. It will change

• How we write requirements. – Now we will have to write requirements that capture how do we know if user intent was met?
• How we test the product.   –
• How we measure quality
• How we decide what is an acceptable range of correctness?
• Last but not least, how do we decide our feature is ready for release?

AI empowered Intent driven products will not be merely right or wrong – we need to find a way to capture if the user intent was fulfilled

From Fixed Expectations to Context-Aware Experiences

For decades, we have designed digital products with fixed expectations. You navigate a certain menu, click a certain button – each time same action happens. This is a fixed expected behavior. We discussed above that Intent makes a key shift from expected behaviors for AI – But Context is an equally important factor to consider

Imagine a project manager opening a portfolio dashboard. With a traditional, fixed-expectations product, she expects to scan each of his 20 dashboards daily. Maybe she even has an alert built in to highlight dashboards with “red” items. But in the end, that alert is based on a fixed set of rules

But when working with an AI-empowered, intent-driven dashboard, instead of examining twenty charts, the manager might ask:

“What has changed since last week, and which three things need my attention?”

For the product to answer well, however, it needs context.

What projects does this person manage? What happened last week? Which risks were previously discussed? What does this organization consider critical? What information is this person permitted to access?

We can now see that context is becoming an increasingly important part of product design.

The quality of an AI experience may depend not only on the model being used but also on what the product Context – What the Product knows, remembers and retrieves at the right moment.

From Providing Features to Providing Intelligent Capabilities

Consider a traditional sales application.

It may provide customer records, reports, dashboards, filters and alerts. These features help a salesperson understand what is happening. And using the information, the salesperson then makes a decision about which customers are likely to turn to a competitor product this month

Instead, an AI-empowered version of the sales application could possibly answer:

“Which of my customers are likely to turn to a competitor product this month and why? What can I do to reduce the impact?

The product is no longer simply retrieving or representing information.

It analyzes information, identifies patterns /trends and/or anomalies , and then recommends possible action.

We can see similar changes across industries.

A traditional HR product stores employee information. An AI capability may help managers identify recurring themes in employee feedback.

A project management product tracks tasks and dependencies. An AI capability may identify emerging delivery risks and suggest possible interventions.

A customer-support product displays previous interactions. An AI capability can summarize the customer’s history and recommend a response.

The conversation when we think about AI products moves beyond: “What features should our product provide?”

To Goes towards “What intelligent capabilities should our product have?”

From Assistance to Increasing Autonomy

AI products are also changing in another significant way: they can increasingly act.

Imagine an expense-management product. If we want to limit AI use to analytics, AI could identify unusual expenses. If we want to go ahead and provide recommendation abilities, AI could explain why an expense appears unusual. It could then recommend an action.

But an AI agent takes this even further. It could potentially investigate supporting documents, contact the employee for missing information, update the case and route it for approval.

The products are now going from providing intelligence to taking coordinated action toward an objective.

The difference between an AI that says “Here is what I recommend” and an AI that says “I have done it” is often the differentiator.

As products move along this spectrum, autonomy itself becomes a product-design choice. We need to decide what action an AI agent should be allowed to take and where we need to insist on human intervention. For example, it may be OK to have AI approve a standard insurance claim, but you may want AI to flag any unusual claims to human or maybe you want all rejections to be vetted by a human.  Going further you may want AI to suggest a possible diagnosis to a physician but never to a lay person.

The decisions on where AI acts and when it recommends… Or even what it can recommend what to whom are now the Product Design decisions

Products Can Now Fail in New Ways

Perhaps the most important shift in behavior appears when AI fails. Traditional software certainly fails. Applications crash, integrations break and calculations contain defects.

But AI introduces different kinds of failure. An AI system may misunderstand a perfectly valid request. It may generate information that doesn’t exist. (Hallucinations!).It may use outdated or inappropriate context. It may make a poor recommendation while sounding extremely confident. An autonomous agent may correctly execute an action that it should never have been allowed to take.

This creates an unusual situation: The software may be functioning exactly as designed, while the product is still producing an unacceptable outcome. Data – availability /correctness and retrieval will now impact a lot of outcomes . With data, we now have to worry about the data security / ethics

Concepts such as trust, uncertainty, boundaries, human oversight and acceptable failure increasingly important product considerations.

Snehamayee’s Perspective – Empowering your product with AI is more than adding an AI patch

The most common way people try to adopt AI is to see how it can make current work more productive. How can AI automate my MoM? Can we use AI write user stories / acceptance criteria or even code for me? How can AI write test cases and analyze test coverage?

A few people go ahead and try to incorporate AI in their products- what they do is to take an existing product and ask: “Where can we add AI?”

People may add a chatbot to their Product. Sometimes they add data summarization or trend analytics. They may even add recommendations. These certainly add value to the product.

But the more interesting question is:“If this product had access to intelligence from the beginning, would we design the product differently?”

Would users still navigate through ten screens? /Would they still analyze the dashboard themselves? /Would they still manually coordinate five different activities?

Or could the product understand their objective, assemble the necessary context, recommend an approach and—with appropriate safeguards—take some of those actions for them?

That is where AI stops being merely another feature and starts changing the product.

And this leads to an important question for those of us working in Agile product development.

If our products are becoming probabilistic, context-aware, adaptive and increasingly autonomous, can we continue building them exactly as we built deterministic software?

• Do our requirements need to change?
• What does “Done” mean?
• How should we test something when there isn’t always one correct answer?
• What new risks should teams consider?

And what does all of this mean for Product Owners, Scrum Masters and Agile teams?

Those are the questions I will explore next. while I do that please refer to this document for the design guideline when we build AI empowered Products

Because when the nature of the product changes, the way we build the product must evolve too.

The post What changes when you AI empower a Product appeared first on World Of Agile.

 Project Management for Traditional, Scrum or Kanban work

PMI says, Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements. For best outcomes, we need to vary our Project Management techniques by work type. Traditional work Vs Scrum or Kanban, all require different approaches

When people hear the word “Project Management”, they often think only about creating plans, tracking schedules, managing risks, coordinating teams, and ensuring that projects get delivered successfully. But should every type of work be managed in the same way? I believe that the answer is a clear “No”. Delivering a project with stable, well-understood requirements is fundamentally different from developing an innovative product where the solution emerges through experimentation. Both are different again from operational work where requests arrive continuously. This is why effective project management starts with understanding the nature of the work. Traditional project management, Scrum, and Kanban do not simply provide three different ways of organizing tasks. They address different types of work and therefore Project Management for Traditional, Scrum or Kanban work requires different approaches to planning, risk management as well as progress tracking. The role of the Project Manager changes for each approach.

Understand the Nature of the Work

Traditional project management works well for defined work, where requirements are relatively stable, and outcomes are known upfront. Usually, established practices already exist. Examples could include a server upgrade, hardware rollout, or SAP security patching. Because uncertainty is relatively low, detailed planning is both possible and useful. Scrum is designed to help with Complex or empirical work. When requirements are unstable or not clear, teams cannot know everything at the beginning. In such situations, requirements evolve through feedback. Trial and error helps to iterate to the right solution. Developing an AI-based demand forecasting solution or a new digital product are examples. Instead of attempting to eliminate uncertainty through more detailed planning, Scrum manages uncertainty through short iterations, feedback, inspection, and adaptation. Kanban is particularly useful for flow-based or operational work. Production support, incident management, service requests, and supplier tickets are some examples. In such work, we usually do not have a defined beginning and end. Work arrives continuously, and priorities do change frequently. Fast response to the changing priorities and incoming work is important. Deciding a Sprint Goal becomes quite difficult. The challenge is therefore to keep work flowing smoothly while avoiding bottlenecks and excessive Work-in-Progress (WIP). A simple way to remember the distinction is:

If the work can be is stable and can be predicted, plan it; if you need to learn while doing it, use empiricism; if work continuously arrives, optimize the flow.

Planning as per work type: Traditional, Scrum or Kanban work

Planning is necessary in all three approaches, but the purpose and horizon of planning change. In a traditional project, the primary planning question is: What work must we complete, and how do we deliver it on time and within budget? The Project Manager typically creates a detailed project plan covering scope, milestones, dependencies, resources, schedule, and budget. Tools such as the Work Breakdown Structure (WBS), Gantt charts, and milestone plans support this predictive approach. When we plan for predictive work, focus is on efficiency and optimization Scrum asks a different question: What is the most valuable thing we should build next, and what can we learn? Planning is adaptive and focuses on feedback. In such an environment, planning happens at multiple levels through the product roadmap, Product Backlog, release planning, backlog refinement, and Sprint Planning. Scope can and often does evolve as customer feedback and learning provide new insight. The objective is not simply to deliver everything originally requested, but to maximize customer and business value. When we are working with  flow-based or operational work, the planning  question is: What work should we pull next to ensure smooth flow and meet service expectations (SLA/KPIs)? In the flow based work, we continuously prioritize work based on demand, urgency, available capacity, and service expectations. Kanban boards, WIP limits, service request queues, and classes of service help while planning Kanban kind of work.

Thus, Traditional planning optimizes for predictability, Scrum focuses on planning for experimentation with focus on continuous outcomes and Kanban plans for optimizing the flow and removing bottle necks.

Risk Management: The Risk Itself Changes when work type changes

Risk management also differs as per the nature of the work. Traditional projects primarily face risk of execution not going as per plan. The concern is whether the team manages to deliver the agreed scope according to the plan. Schedule delays, missed dependencies, budget overruns, and scope creep are common risks. Project Managers rely on risk registers, dependency analysis, mitigation plans, contingency reserves, and formal change control. In Scrum, the dominant risk is uncertainty and rapidly evolving requirements. Are we building the right features? Will our customers user our prouduct? What if an assumed technical solution does not work? Scrum reduces these risks through short iterations, prototypes, rapid feedback, backlog reprioritization, and continuous learning. Kanban faces operational risk  . Growing queues, SLA breaches, excessive WIP, capacity constraints, and bottlenecks can quickly affect service. Teams use patterns like WIP limits, SLA monitoring, flow metrics, and bottleneck management.  These patterns help the teams to establish the flow.  

To summarize, Traditional approaches try to predict the risk and then analyze and control it.  Scrum emphasizes on learning based on feedback and then adapting and pivoting as needed. While Kanban focuses on detecting problems quickly, restoring flow, and continuously improving.

Tracking Progress differs for each work type: Are We on Plan, Creating Value, or Flowing?

Perhaps the clearest difference is visible in how progress is measured. In a Traditional project, the key question is: Are we on plan? Measures such as milestone completion, percentage complete, schedule variance, cost variance, Earned Value, SPI, and CPI help compare actual performance against the baseline. In Scrum, the more important question is: Are we creating value effectively? Sprint Goal achievement, working product increments, customer feedback, quality, value delivered, burndown, and velocity can provide useful information. Importantly, completing more work does not automatically mean creating more value. For Kanban, the question is: Is work flowing? Lead time, cycle time, throughput, WIP, work-item age, cumulative flow, and SLA compliance help teams understand whether work is moving efficiently through the system.

Success itself looks different for each work type: Traditional projects emphasize delivering scope, Scrum emphasizes delivering value, and Kanban emphasizes delivering flow.

With Changing work types, The Project Manager’s Role Must Change Too

One major misconception about Agile is that Agile does not need Project managers – well if the work needs managing, we need someone to manage the work. Read this article to understand why we still need a manager in Agile Projects. If planning, risk, and tracking change, the Project Manager cannot operate in exactly the same way either. In Traditional projects, the PM naturally spends significant effort planning, coordinating dependencies, monitoring schedules and budgets, managing risks, communicating status, and controlling deviations from the agreed plan. In an Agile environment, these responsibilities do not disappear—they are redistributed. The Product Owner, Scrum Master, team, technical leaders, and Project Manager may share responsibilities that traditionally sat with one PM. This requires an important mindset shift. Instead of focusing primarily on following the plan, focus on achieving the desired outcome. Instead of controlling change, respond effectively to change. We need to move from managing individual tasks to enable high-performing teams. Rather than measuring activity, we should measure customer value and outcomes. And instead of directing execution, facilitate collaboration and learning.

Snehamayee’s recommendation — Choose the Approach Based on the Work

Project Management for Traditional, Scrum or Kanban work is very different. Which is why, Traditional, Scrum, and Kanban should not be viewed as competing methods where one must always be better than the others. The better question is: What is the nature of the work we are trying to manage?

When work is predictable and well defined, detailed planning and control can provide tremendous value. On the other hand, when the work contains significant uncertainty and learning, Scrum’s empirical approach enables teams to inspect, adapt, and discover better solutions. Lastly in situations where work arrives continuously, Kanban helps teams optimize flow and responsiveness. Great project management is therefore not about rigidly following one methodology. It is about recognizing the type of work in front of us and adapting how we plan, manage risk, measure progress, and lead teams accordingly.

When we work at enterprise level Agile, it becomes important to recognize that often we will need to employ all 3 approaches within same large multi team Agile Project or Program based on what each specific team does – I explore this idea with more depth in World Of Agile Agile PM Skill Badge

The post Project Management for Traditional, Scrum or Kanban work appeared first on World Of Agile.

How to prepare for PI Planning: A Practical Guide from the Trenches

How to  prepare for PI planning? In Other words, do you have a checklist for PI Planning Readiness

When I help organizations with their SAFe journey, I often get a request, do you have a PI Planning Readiness checklist? That is the question I am planning to answer with this article

 Introduction: Why Preparing for Your First PI Planning feels overwhelming (and why it doesn’t have to be)

Getting ready for your first PI Planning often feels like tackling a mountain of scary and unclear work There are multiple teams that will participate, So many senior senior stakeholders to take care of , A lot of people have big expectations from SAFe  They are expecting measurable business outcomes from this PI and they want PI planning to ensure the magic.

Somewhere in the middle of all that, you’re expected to help “align everything.” It’s not surprising most people are a little (or a lot) overwhelmed.

I remember my first PI planning—I thought the challenge was ensuring that the two days go smoothly. It wasn’t. The real challenge was everything that what we should have done before those two days.

I am here to make that part clear…. Once you see PI Planning as a time and opportunity to get ready for the upcoming PI and not just an event. It then to starts to feel a lot more manageable. And honestly, a lot more valuable.

Common mistakes first-timers make as they Prepare for their First PI planning

The biggest mistake I see? Treating PI Planning as a two-day activity. By the time those two days begin, has already to be done already be done. PI planning is a time for Agile Teams , ART leadership, Management and Stakeholders to align their thoughts on what work we will do in the PI and how we will do it. It is not the time to start thinking fresh for the first time on what work we will do in the PI? Some other patterns tend to show up:

• People walk in without a clear sense of priorities  and the Goal
• Not considering Architecture Runway and having no idea about their percentage capacity allocation….
• Backlogs that are either over-detailed or completely unclear
• Major Dependencies only get discovered during breakout sessions
• There’s an expectation that the plan will be “final” and perfect

I’ve been in a PI where everything looked well-prepared on paper. We were so sure of our success in the PI . But on the ground, once the PI started, we realised we had not accounted for some day-to-day maintenance work we had to do… That kind of thing slows everything down.

PI Planning Preparation starts weeks before (not days before)

If you take away one thing from this article, let it be this: PI Planning wins or loses before it begins. Here is a simple checklist Few  weeks before: You focus in shaping the direction of the PI

• What is the business impact we are trying to achieve this PI?
• What are our top priorities for this PI?
• Who are the key stakeholders? Are they roughly aligned?

You don’t need all the answers—but you need a strong starting point. 1–2 weeks before: Now you start sharpening things.

• Understand  the top backlog items
• Start identifying dependencies
• Begin early conversations across teams

This is where most of the real alignment work happens. Final week: You’re not “building”—you’re checking.

• Are there any major gaps?
• Are stakeholders aligned enough?
• Do teams understand what’s coming?
• Any major dependencies

If you have been focusing in earlier week, it actually starts to feel easier at this time

Clarity on Vision, Priorities, and Outcomes is the Key To Success in PI Planning

A lot of PI Planning issues come down to one thing: unclear priorities. Not lack of effort. Not lack of tools. Just unclear direction. It is really not about detailing everything. It’s about being clear on what matters most. I’ve seen backlogs with 40 “top priorities.” That doesn’t work. Teams don’t need more items—they need clarity:

• What are the few things we really care about this PI?
• Why do they matter?
• What does success look like?

When the “why” is clear, teams make smarter calls during planning. When it isn’t, they fill in the gaps themselves—and that’s where misalignment creeps in.

 Get the Backlog Ready (without over-engineering it)

Many teams tend to overprepare the backlog. They want every story refined. Every detail thought through. Every i dotted and every t crossed.It feels responsible. It’s not always useful. What you actually need is a backlog that’s good enough to have a conversation. That means:

• The top items are clear
• There’s enough context to discuss
• Priorities are visible

That’s enough! Over-refinement can backfire. I’ve seen teams spend days breaking work down, only to rework everything once cross-team conversations begin. Also, don’t try to eliminate uncertainty. You won’t be able to do that. The goal is to surface it early, not pretend it doesn’t exist.

The fine line: Prepared enough vs over-prepared

There’s a point where preparation stops helping and starts getting in the way. You’ll notice it when teams spend more time polishing stories than actually talking about what needs to be built. It feels like progress—but it’s not always the kind that helps during PI Planning. I’ve seen teams walk in with extremely detailed backlogs—everything estimated, everything broken down neatly. And then within a few hours, half of it gets reworked because priorities shift or dependencies come up. Worse still, you notice people are not having conversations – they are merely ticking off the checklist… Assuming that things are already planned and “frozen!!”… That’s a dangerous assumption. It leads to people not speaking up even when they do notice something ….. Over-preparation usually shows up as:

• Too much detail too early
• Refining things that aren’t even top priority
• Trying to “lock” the plan before alignment actually happens

The intent is good—you want things to go smoothly. But PI Planning isn’t about validating a pre-built plan. It’s about building it together. Prepared enough means you’re ready for meaningful discussions—not that you’ve removed the need for them.

Align Stakeholders before the PI Planning

If there’s one thing that will derail your PI Planning quickly, it’s stakeholder misalignment. When Business, Product, and Architecture aren’t on the same page, it shows up fast—and publicly. Try to get ahead of that:

• Are priorities agreed upon?
• Are there known trade-offs?
• Is there any major disagreement that hasn’t been addressed?
• Last but not least – do they understand what PI planning is about?

You don’t need perfect alignment—but you do need enough alignment to move forward. The worst place to discover fundamental disagreements is in the middle of planning.

Prepare Teams (and not just the Product Owner) Before PI planning

A common pattern: Only the Product Owner is doing all the preparation work. The teams are waiting to hear from “somebody” to tell them what they will do next PI That does not help…. Teams need context. Without it, they’re starting the PI Planning in the dark. Before PI Planning:

• Share the vision and priorities
• Talk through key constraints
• Highlight known dependencies
• Explain high level stories /items
• Think about what other type of work team has to do (Build Architecture runway/deal with technical debt? / Handle some defects?) – a discussion about % capacity allocation goes a long way

This doesn’t have to be heavy. A short briefing, a walkthrough, even informal conversations go a long way. Also, make roles clear:

• Product  Manager sets direction
• Teams plan how to deliver and how much they can deliver
• Facilitators keep things moving
• Business validates alignment

When everyone knows their role, the event feels a lot less chaotic.

Logistics matter more than you think

This is one of those things you only appreciate after it goes wrong. If tools don’t work, if breakout rooms aren’t ready, if people can’t access boards—it drains energy fast. Check the basics:

• Tools are working and accessible
• You have set up the board 
• Breakouts are planned
• Considered the timebox

It sounds simple, but smooth logistics make a big difference to how the session feels.

 What “good preparation” actually looks like

Good preparation isn’t about having everything figured out. It’s about having enough context to plan…. Having the right people to Plan You’re in a good place when:

• Priorities are clear
• Stakeholders are mostly aligned
• Dependencies are visible
• Capacity  allocation and availability is understood
• Teams feel prepared—neither in dark  nor ready with a “frozen” plan.  If everything feels completely locked before PI Planning even starts, that’s usually a red flag—not a sign of readiness. You should still need the conversations.

Final checklist: Are you ready?

Before you start, do a quick check:

• Are the top priorities clear?
• Do you understand the high level business imperative for PI
• Is the backlog ready enough?
• Are stakeholders aligned?
• Have key dependencies been identified?
• Do teams have context?
• Are tools and logistics sorted?

If you’re ticking most of these, you’re in good shape.

Closing: PI Planning is a leadership moment

PI Planning very quickly exposes how things really work in your organization. It shows how well you align. How realistic your plans are. How clearly you communicate. It’s also a moment where leadership becomes appreant—not just in decisions, but in how well teams are set up to succeed. You don’t need a perfect plan. That’s not the goal. What you need is shared understanding, realistic direction, and teams that feel confident about what they’re committing to. Get that right, and PI Planning stops feeling overwhelming—and starts becoming genuinely useful

The post How to prepare for PI Planning appeared first on World Of Agile.

Does Agile Need Project Managers? A Reality Check

Introduction: Agile and Project Managers

“Agile doesn’t need Project Managers.” Or “Project Managers are getting obsolete”

I often hear this statement. People often say this with conviction, sometimes with relief, and occasionally with confusion.

Over the last decade or so frameworks like Scrum and Kanban have become more famous. And that brought a shift away from traditional roles. Scrum, in particular, explicitly defines only three accountabilities: Product Owner, Scrum Master, and Developers. Scrum Guide does NOT mention a project manager at all.

And just like that, many organizations concluded: the Project Manager role is obsolete. We do not need Project Managers any longer…..

But is that the right conclusion ? — Or have we misunderstood what Agile is actually trying to change?

I do not plan to defend job titles in this article. Instead, I want to discuss and examine the ground reality. I want to talk about what actually happens in Agile projects beyond theory, certifications, and frameworks.

Where Did This Question Come From?

To understand the confusion, we need to go back to traditional project management.

In a traditional setup, the Project Manager was the central authority. This person was responsible to plan, track, report, manage the risk management, communicate with team and stakeholder and above all ensure value delivery.

With so much to do, project managers often became a bottle neck.

Agile challenged this model.

Instead of centralized control, Agile emphasized:

• Self-managed teams
• Collaboration over hierarchy
• Adaptability over rigid planning

In doing so, Agile (more specifically Scrum) didn’t explicitly include the Project Manager role.

Many interpreted  this as “no need for project managers.”

That’s a dangerous assumption and a myth!

While Agile removed the role as a command-and-control authority, it did not eliminate the responsibilities that ensure delivery.

What Agile Frameworks Actually do Say about Project Management

Now Let’s separate the myth from reality.

We saw that Scrum did not specifically ask for Project Managers

What Does Scrum Say about Project Managers?

Scrum defines accountabilities clearly—and Project Manager isn’t one of them. But Scrum operates at the team level. It assumes a relatively contained environment where a single team can deliver value incrementally.

It does not address:

• Cross-team dependencies
• Complex stakeholder landscapes
• Organizational constraints

Kanban and the Project Manager
Kanban goes even further. It doesn’t mandate specific roles at all. Kanban focuses on evolutionary change, improving  the flow via work visualisation, and limiting work in progress.

But again, it assumes a system where flow can be managed effectively. Someone still needs to ensure alignment, remove bottlenecks, and manage expectations. These days, roles emerge for flow management in kanban. Some common  roles are  the Service Delivery Manager (SDM)(who manages workflow and removes bottlenecks – similar to a Scrum Master), and the Service Request Manager (SRM) (who manages the backlog and prioritizes customer requests – like a Product Owner)

SAFe (Scaled Agile Framework) and the Project Manager

SAFe also does not have a designated role called a Project manager. However,  SAFe does include roles like  the Release Train Engineer, the  Product Manager, and the System Architect.

Question is Why?

Because at scale, coordination and alignment is critical. Dependencies multiply. Stakeholders increase. Complexity grows.

And suddenly, the need for overarching thinking becomes undeniable.

The Reality of Agile Projects on the Ground

In real organizations, Agile projects today rarely operate in isolation. They involve:

• Multiple teams working on shared outcomes
• Dependencies across systems and functions
• Stakeholders with competing priorities
• Pressure to deliver faster, with quality

Now ask yourself:

• Who ensures that all of this comes together?
• Who aligns teams when priorities conflict?
• Who manages risks that span across teams?
• Who communicates with stakeholders beyond the team level?
• Who takes accountability for multi team integrated delivery outcomes?

Self-organizing teams are powerful—but they are not designed to solve organizational complexity on their own.

 So Who Actually Does this Work?

Even in Agile environments, the following responsibilities don’t disappear:

• Stakeholder Management – Aligning expectations, managing communication
• Dependency Management – Coordinating across teams and systems
• Risk Management – Identifying and mitigating delivery risks
• Planning at Scale – Beyond sprint-level planning
• Delivery Accountability – Ensuring outcomes, not just outputs

What happens on ground? These responsibilities are often:

• Distributed
• Unclear
• Or silently pushed onto Scrum Masters, Product Owners, or senior team members

This creates confusion—and sometimes, burnout. Read this article to understand the Scrum Accountabilities and what happens when we ask people to wear multiple hats  

The Emergence of the Agile Project Manager

In many organizations, something interesting happens. The role doesn’t disappear—it evolves. The title may not be “Project Manager” anymore. Instead, the new title can be:

• Delivery Manager
• Program Manager
• Agile Project Manager
• Release Train Engineer

But the essence remains the same:
Someone is responsible to connect the dots.

When you assume the title of an Agile e Project Manager, you do not assume a command-and-control authority.

Instead, you become a

• A Facilitator of alignment
• A Enabler of flow
• A Manager of complexity

and

• An Influencer without formal authority

When Agile Projects Fail Without Project Management

Let’s be honest—many Agile transformations struggle.

Not because Agile doesn’t work, but because critical responsibilities are ignored.

Common patterns include:

• Teams delivering increments that don’t align with business outcomes
• Dependencies causing delays and frustration
• Stakeholders feeling disconnected and dissatisfied
• Lack of clear ownership for delivery risks

In such cases, Agile doesn’t feel empowering—it feels chaotic.

And often, the missing piece is not process—it’s project-level thinking and coordination.

What Makes an Agile Project Manager Different

If Agile still needs project management, then what changes?

Everything.

The Agile Project Manager is not:

• A task assigner
• A status tracker
• A gatekeeper

Instead, they:

• Enable flow, not control work
• Facilitate decisions, not impose them
• Influence stakeholders, not manage them through authority
• Focus on outcomes, not just timelines

It’s a shift from control to alignment and orchestration.

Snehamayee’s Thoughts

So do you need an Agile Project Manager? The answer is: it depends.

You may not need a dedicated Project Manager when:

• You have a single, small, co-located team
• Dependencies are minimal
• Stakeholders are closely aligned

But as complexity increases—

• Multiple teams
• Distributed environments
• High uncertainty
• Organizational constraints

—project-level coordination becomes essential.

Call it what you want, but the capability must exist.

The Bigger Problem: We’re Asking the Wrong Question

“Do Agile projects need Project Managers?” is the wrong question.

The better question is:

Do Agile projects need strong project management capabilities?

The answer is clearly yes.

Organizations don’t fail because they have Project Managers.
They fail because they lack clarity on how the role should evolve in Agile.

Conclusion: A Project Manager for an Agile Project is still relevant – You just have to align the work for Agile Realities

Agile didn’t eliminate the need for project management.

It redefined it.

The role is no longer about control—it’s about enabling alignment, managing complexity, and ensuring delivery in dynamic environments.

Whether you call it a Project Manager, Delivery Manager, or something else doesn’t matter.

What matters is this:

If no one is taking ownership of project-level responsibilities, your Agile setup is incomplete.

Reflection for you:
In your Agile projects today—who is actually handling project-level responsibilities?

The post Does Agile Need Project Managers? appeared first on World Of Agile.

User Story Anti Patterns

The Incomplete Story Antipattern

• Be specific about which platforms (e.g., Google, Facebook).
• Add the goal or benefit (e.g., to avoid creating a new account).

“System User” Anti Pattern

Anti Pattern: Should be An Epic Instead Of Story

• Break this into smaller, focused stories (e.g., sales reports, user activity).
• Define what data is needed and why.

Too Much Detail Anti Pattern

• Focus on the user need, not the solution (e.g., setting preferences).
• Let the team decide how to build it (e.g., dropdown, XML).

Lack of Clarity Anti Pattern

• Define what “faster” means (e.g., page loads in under 2 seconds).
• Break into specific stories (e.g., improve search speed, reduce load time).

Anti Pattern :: Multiple Actions in One User Story

• Split into smaller stories: register, log in, update profile, update address.
• Make each one deliver value independently.

Technical Story Anti Pattern

• Write tech work as a task under a user-facing story.
• Use user types who benefit from the change (e.g., ops, admins).

User Story Anti Pattern – Confusion with the Definition Of Done

• Validate if this is really a user need or a branding/design requirement.
• If important, combine into a larger user experience/story for consistent branding.

Focus on Solution Anti Pattern

• Focus on the goal (e.g., finding products quickly).
• Leave design/building to the team.

Too Many Users Anti Pattern

• Split into two stories: one for user, one for admin.
• Keep persona goals clear and separate.

Some Tips to Write Good User Stories

Write from the end user’s perspective (real persona).

Clearly state the goal or benefit (“so…”).

Keep stories small and focused on one thing – split if necessary.

Avoid tech or building details.

Make stories testable with clear acceptance criteria.

Use simple, clear language (no jargon).

Separate different roles/user types into separate stories.

Avoid vague terms like “better” or “faster” — be specific.

Ensure each story delivers user value.

Defer solutioning to the team — talk about what, not how.

The post Typical Antipatterns seen in a User Story appeared first on World Of Agile.

Product Backlog Refinement Techniques

we will discuss Product Backlog Refinement Techniques in this article.

Scrum Guide says, “Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items.” This activity ensures that the product Backlog remains structured, prioritized, and ready for upcoming sprints. It is an ongoing Activity where Scrum Team and Stakeholders collaboratively review, refine, and adjust backlog items to ensure they are well-defined and actionable.

 In this article, we will explore various techniques to refine the product backlog effectively. To read about how scrum master can help with refinement, please read this article

Why Product Backlog Refinement Matters

Backlog refinement serves multiple purposes, including:

• Reducing ambiguity: Ensuring that backlog items are well-defined and ready for development.
• Enhancing estimation accuracy: Allowing teams to make better effort estimates.
• Ensuring alignment with business goals: Keeping the backlog focused on delivering value.
• Preventing last-minute surprises: Reducing the likelihood of unplanned work during a sprint.
• Facilitating collaboration: Engaging the Product Owner, Scrum Team, and stakeholders in a shared understanding of work items.

How does a Good Product Backlog Look?

 The DEEP Model

The DEEP acronym, common in industry, outlines key attributes of a well-maintained product backlog:

• Detailed appropriately: Items should be progressively elaborated.
• Emergent: The backlog should evolve based on changing requirements.
• Estimated: Items should have an effort estimate.
• Prioritized: Items should be ranked based on business value.

Using this model ensures that the backlog remains dynamic, relevant, and actionable.

INVEST Criteria

To ensure that item are well-formed and actionable, teams can apply the INVEST criteria:

• Independent: Each Item should be self-contained.
• Negotiable: The scope should be flexible based on discussions.
• Valuable: The story should deliver clear business value.
• Estimable: The team should be able to estimate the effort.
• Small: Items should be small enough to be completed in a sprint.
• Testable: Acceptance criteria should be well-defined.

Applying INVEST ensures high-quality Items that are easier to develop and test.

Some Challenges to Anticipate During Product Backlog Refinement

• Scope Creep and Evolving Requirements
• Estimation Inaccuracy
• Lack of Stakeholder Engagement
• Over-Refinement or “Analysis Paralysis”
• Technical Debt and Dependencies
• Prioritization Conflicts
• Communication Barriers
• Large Backlog Management

Some Techniques for effective Product Backlog Refinement

Now, let us discuss into specific techniques that will help with this activity.

User Story Mapping

User Story Mapping is a visual technique. This technique helps teams understand the bigger picture while breaking down features into smaller, manageable backlog items. It involves:

1. Identifying key user activities or workflows.
2. Breaking them down into high-level steps.
3. Further decomposing them into detailed user stories or Items
4. Prioritizing based on customer value and dependencies.

Benefits:

• Helps teams visualize the user journey.
• Ensures a customer-centric approach.
• Provides a structured way to prioritize backlog items.

 Adopt Three Amigos Approach For All Items

This technique involves representatives from three key perspectives:

• Business (Product Owner): Provides clarity on requirements and priorities.
• Programmers (Coders/Engineers): Ensures technical feasibility.
• Testing (QA/Testers): Identifies potential edge cases and acceptance criteria.

Benefits:

• Reduces misalignment between business needs and technical feasibility.
• Helps in writing better acceptance criteria.
• Fosters cross-functional collaboration.

Spikes for Research-Based Refinement

Sometimes, backlog items require additional research before they can be estimated or implemented. In such cases, teams use Spikes—time-boxed research or investigation tasks—to explore unknowns. Spikes can be technical (exploring a new framework) or functional (understanding user behavior).

Benefits:

• Reduces uncertainty and risks.
• Provides clarity before committing to implementation.
• Helps in accurate estimation of effort.

Story Splitting Patterns

When Items are too large (epics), breaking them into smaller Items (stories) helps manage scope effectively. Common splitting techniques include:

• Workflow steps: Splitting based on different steps in a process.
• Variations: Breaking down based on different user roles.
• Complexity: Separating basic functionality from advanced features.
• Data variations: Handling different types of data separately.

Breaking down Items ensures that work remains manageable and can be completed within a sprint.

Refinement Poker

Inspired by Planning Poker, this technique gamifies backlog refinement. Team members use numbered cards to vote on the clarity and readiness of Items . If there is disagreement, discussions follow to refine the story until consensus is reached.

Benefits:

• Encourages engagement and discussion.
• Highlights ambiguous requirements early.
• Leads to clear items 

Just-in-Time (JIT) Refinement

Rather than refining all backlog items at once, Just-in-Time refinement involves reviewing only the most immediate Items (e.g., those likely to be worked on in the next 1–2 sprints). This approach:

• Reduces wasted effort on items that may change later.
• Keeps the backlog lightweight and relevant.
• Allows for evolving requirements to be addressed at the right time.

Acceptance Criteria Definition Workshops

A dedicated workshop where teams collaborate to define acceptance criteria ensures that Items are clear and testable. Techniques like Given-When-Then (from Behavior-Driven Development) can be used:

• Given a precondition
• When an action is performed
• Then an expected outcome should occur

Benefits:

• Reduces ambiguity in requirements.
• Ensures all scenarios are considered.
• Facilitates better testing and validation.

Regular Backlog Refinement Meetings

Holding regular backlog refinement sessions (at least once per sprint) keeps the backlog in good shape. These meetings should:

• Include the Scrum Team and Product Owner.
• Focus on the highest-priority items.
• Ensure that Items are well-defined and estimated.

Best Practices:

• Keep sessions time-boxed (e.g., 60–90 minutes).
• Avoid refining too many items at once.
• Maintain a balance between discussion and decision-making.

Conclusion

Product backlog refinement is an essential Activity for Scrum Teams, This Activity ensures that backlog items are well-defined, prioritized, and ready for development. By leveraging techniques like User Story Mapping, INVEST, Three Amigos, and Refinement Poker, teams can improve collaboration, reduce ambiguity, and enhance sprint predictability. Regular and structured refinement helps Scrum  Teams remain adaptable, efficient, and focused on delivering value to customers.

The post Product Backlog Refinement Techniques appeared first on World Of Agile.

Product Owner Core Competencies Framework

Product Owner is accountable for maximizing value. The article discusses core competencies a person must develop in order to become a great Product Owner.

The following diagram is created by our Certified Scrum Trainer, Amit Kulkarni based on his knowledge of delivering large products in various banks and financial institutions. This diagram in no way represents the exact view of how a Product Owner may be implemented in various organizations. This diagram is an attempt to visualize the knowledge areas one must focus on while one shapes his/her career in Product Management.

The above diagram is divided into three major areas

Must Have Competencies for the Product Owner

These are the necessary knowledge areas for a Product Owner. A product Owner must necessarily know about the product he or she is owning. Which means, the person should know about the Product Lifecycle, Managing Product Strategy Roadmap as well as the Product Backlog .

Should Have Competencies for the Product Owner

The knowledge areas which Product Owner should aspire once the “Must” areas are in place. These competencies deal about specific techniques which will help the Product Owner excel in the Product Management. A successful Product owner should definitely target to acquire many of the competencies and have a plan for where he and she can get help for areas where they do not have expertise them selves.

Could Have Competencies for the Product Owner

These are areas where the Product Owner may have some skills based on the work that the Product Owner has done before he/she has become a Product Owner. We can consider these as icing on the cake once the Product Owner has acquired the “Must” and “Should” categories of the competencies

Product Owner Core Competencies Framework © 2023 by Amit Kulkarni is licensed under Attribution-ShareAlike 4.0 International 

The post Product Owner Core Competencies Framework appeared first on World Of Agile.

Product Strategy Canvas

This canvas is built by our Certified Scrum Trainer, Amit Kulkarni. This canvas gives a glimpse of what fields could be included in a Product Strategy. This canvas is in no way the only way to document a product strategy. Each organization may have different canvas or templates to document the same. This Product Strategy Canvas is an attempt to give an overview of the fields one might use while documenting Product Strategy

Product Strategy Canvas © 2023 by Amit Kulkarni is licensed under Attribution-ShareAlike 4.0 International 

The post Product Strategy Canvas appeared first on World Of Agile.

Product Owner is the accountability in Scrum which Maximizes the value to the stakeholders using the bandwidth available to him/her via the Developers.
While the requirements can never be finalized in empirical work, one of the fundamental aspects of reducing wastage in Agile is to get the requirements ready for the developers “just in time” – not to early and not too late.
Product Owner’s role is to engage with the stakeholders and understand their needs and expectations. This involves

• Requirement elicitation techniques
• Need Analysis techniques
• Requirements classification techniques
• Collaborative Gaming techniques
• Requirements classification techniques
• Requirement Documentation techniques

Who does requirement elicitation in Scrum?

While the Product Owner remains accountable for requirements elicitation, rarely would a Product Owner have enough time to elicit it by himself/herself. Generally, Business Analyst does this (Business Analyst is called as Developer in Scrum) for the Product Owner. Elicitation techniques help people to understand the thoughts and feelings of participants, and to probe for more information.

Why is requirements elicitation different in Scrum?

In Scrum, requirement elicitation is an ongoing job. The Product Backlog emerges throughout the project. Therefore, doing too much of upfront elicitation is a lot of wastage. However, doing the requirements elicitation should ensure that the process is quick, and bureaucracy involved with signoffs and baselines should be avoided. At the same time, the process has to be fast. You cannot have huge documentations done in the form of a Functional Specification or Business Requirements Specification.

Requirements Elicitation Techniques

• Brainstorming technique
• Focus Groups
• Interviews
• Prototypes, simulations, demonstrations
• Wireframes
• Nominal group techniques
• Voting techniques
• User story splitting

Requirements Classification Techniques

• Idea / Mind mapping
• Affinity Diagrams
• Multi-criteria decision analysis
• Wideband Delphi

Collaborative Gaming Techniques

• Remember the future
• Prune the product tree
• Sailboat technique

User Role Modeling Techniques

• User Proxies
• User Persona
• Extreme Persona

Need Analysis Techniques

• Five Why techniques
• Cause and effect diagram
• Cause and effect matrix
• SWOT analysis
• Value Stream Mapping

Process Flow Techniques

• Process flow diagram
• User Cases
• Spaghetti diagram
• Swimlane flowchart
• SIPOC diagram

Requirements Documentation Techniques

• User Story
• Context Diagram
• Use Case Diagrams

Business Rules Formats

• Business Rules Catalogue
• Decision Trees

Data Formats

• Entity Relationship Diagrams
• Data Flow Diagrams
• Data Dictionary
• State Table and State Diagrams

Interface Formats

• Report Table
• System Interface Table
• User Interface Flow diagram

The post Generally Accepted Product Management Practices appeared first on World Of Agile.