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.

Why Removing Blockers Isn’t Enough: How a Scrum Master Causes Real Impediment Removal

This article will discuss Why Removing Blockers Isn’t Enough: How a Scrum Master Causes True Impediment Removal. It is a part of an ongoing series of articles where I talk about Scrum masters’ common roles and responsibilities 

When most teams talk about impediments, they are usually referring to issues that surface in the Daily Scrum—someone is waiting for access, a dependency is stuck, or a requirement is unclear. Tracking these is not wrong. But it is not enough. Over years, I have seen one consistent pattern. What teams call “impediments” are often just symptoms of deeper systemic issues. When a Scrum Master limits their role to removing day-to-day blockers, they may help the team in the short term. But that  rarely improves how the system works. Then these issues keep on repeating. Which means recurring delays and wasted efforts to sort the blockers out True effectiveness lies in seeing beyond blockers and causing impediment removal at the system level.

Reframing Impediments: More Than What Shows Up Daily

A blocker is immediate and visible. Some examples can be A missing requirement or a dependency causing a delay.  On the other hand, an impediment is often persistent and structural. Some examples of impediments are Chronic unclear requirements and A dependency-heavy architecture Most teams operate in a loop of fixing blockers while they leave impediments untouched. The cost? Reduced flow, poor predictability, and increasing frustration. A mature Scrum Master learns to ask: “What keeps causing this problem to reappear?”

A Practical View: Types of Impediments

Not all impediments are equal. Treating them the same leads to ineffective actions. A useful way to think about them:

1. Team-Level

• Skill gaps
• Poor collaboration
• Unclear acceptance criteria or poorly written requirements

2. Organizational

• Approval bottlenecks and long tedious workflows
• Functional and/or Technical silos
• Traditional HR processes like appraisals /appreciation structures
• Misaligned Legal Contracts

3. Technical

• Legacy systems
• Fragile or Patchwork architecture
• Poor tooling

4. Flow-Related (Kanban lens)

• Too much work in progress
• Context switching (Parallel work)
• Bottlenecks in specific stages

This classification helps because each type requires a different intervention strategy The Scrum Master’s True Accountability There is still a persistent myth that Scrum Masters are facilitators who “help run ceremonies.” (even though the word “ceremony” was retired from Scrum Guide a long time back!) Facilitating the Scrum Events is a very small part of what Scrum Master should do Scrum Guide says that The Scrum Master is accountable for the Scrum Team’s effectiveness. This requires:

• Ability to influence without authority
• Challenging organizational constraints
• Enabling better ways of working

This is where many struggle—not because they lack intent, but because they underestimate the organisational dimension of impediment removal.  

How to Detect Impediments Early: Signals to Watch

Impediments rarely appear suddenly. They leave signals. Some of the most reliable ones:

• Stories repeatedly spill over sprints – we think we will complete and then figure out we can not. Reasons can be many – estimation issue/skills issue / adhoc work or poorly written stories. But if your Developers often struggle with story completion,  you should look into the underlying reason
• Work items often age without progress  /Cycle time Increases- Many times, the Scrum Team starts a piece of work only to find that the work is getting stalled. Again, there can be many immediate factors – conflicting priorities/dependencies / too big a piece of work, but if we do not show measurable progress and we have too much work-in-progress, items staying too long, it warrants further study. Studying Kanban and Flow principles can be a good idea
• Teams avoid difficult conversations – Teams not having any conflicts may seem good on the surface. You believe they are working in harmony. However, healthy conflict is necessary for progress in an uncertain or complex environment
• Dependencies become “normal”  –  When teams say things like  “long dependency tracking meetings are usual” or “we should add a dependency buffer to the timeline,”  it usually signals a need to simplify.

  The Kanban principle of Visualizing the work and tracking the progress via Flow Metrics provides a clear way to identify many of these signals early. The Kanban boards allows to see bottlenecks and the flow metrics help to capture flow efficiency (how much time gets wasted “waiting” / Cycle time (end to end time) are specifically helpful

Interpret the Signals ( Symptoms )to identify Root Causes

The signals we discussed above are often just  the  symptoms. A good doctor usually does not focus all his energy on symptoms, but they look at all symptoms in totality. The analyze the situation and identify the root cause. We, the Scrum masters, should do the same. Use the symptoms to think about the patterns. Quick fixes are tempting. They make progress visible. Working on pattrens and fixing the root cause often takes time, commitment , patience and most importantly fixing the root cause often needs courage. However, quick fixes almost always will guarantee recurrence. Whereas, fixing the root cause will lead to lasting relief. Effective Scrum Masters invest time in understanding root causes: They think Why does this dependency exist?  Or Why is this approval needed? Or Why does work get stuck at this stage? Techniques like 5 Whys or Fishbone diagrams help—but more important is the mindset of systems thinking. The goal is not to fix the issue. Rather, the goal is to remove the condition that creates the issue.

Create Safety to Surface Real Issues

One of the biggest barriers to impediment removal is not process—it’s psychological safety. When team members do not feel safe to raise issues, transparency suffers. Teams often hide impediments because  they fear blame or worse still because they believe “nothing will change anyway” A Scrum Master’s role here is subtle but critical:

• Stay neutral, avoid being judgmental
• Unless critical, try not step in with ready made solutions for immediate problems.
• Instead,ask questions that allow people to find out their own answers, asking right questions is the top trick a scrum master should learn.
• Observe patterns, not just listen to words

When teams don’t feel safe to expose problems, you’ll only ever deal with surface-level issues.

Choosing the Right Removal Strategy

Not every issue should be solved by the Scrum Master. I use the below quick dipstick to see if I as a Scrum Master should be involved. Let the team solve their blockers or impediments when:

• It’s something they can control
• It builds ownership
• It strengthens capability

I step in when:

• The issue spans multiple teams and my team does not have the necessary connects yet
• It requires facilitation or negotiation
• The team is stuck
• Issue is recurring and the team is doing quick fixes

 Escalate when:

• The issue is systemic or a symptom of a large organizational inefficiency or impediment
• It requires policy or structural change

The mistake many Scrum Masters make is becoming a “resolver of everything”, which creates dependency rather than capability.

Making Impediments Visible

If impediments are not visible, they will not be addressed. Simple practices can make a big difference:

• Maintain an impediment board or log
• Track aging of unresolved issues
• Review impediments regularly with stakeholders

This shifts the conversation from: “Do we have problems?” to “what we can do to solve these?” Visibility creates accountability.

Leveraging Scrum, SAFe, and Kanban Together

Scrum guide says Scrum master is accountable to make the Scrum team more effective. It does not ask the Scrum Master to limit them selves to Scrum Guide. In fact the guide encourages the Scrum Teams (and Scrum masters) to improve their own development practices. A good Scrum Master will often combine practices from Scrum /Kanban/SAFe or even the Lean philosophy Scrum

• Retrospectives provide a built-in opportunity for structured reflection. Good Scrum Masters use this time to
• Sprint reviews expose stakeholder-related impediments

Kanban

• Visualisation makes bottlenecks transparent
• Flow metrics provide objective signals

SAFe

• Escalation paths exist for systemic impediments
• ART-level coordination addresses cross-team constraints

Lean

• Mapping the Value Stream – Identify real value and understand how the team(or teams) delivers the value
• Eliminate waste – Identify steps that are not adding value

  The real impact comes when we integrate these perspectives. We do not need to choose one over the other. For example:

• Use Kanban metrics to identify a bottleneck
• Use Scrum retrospective to explore root causes
• Use SAFe forums to escalate systemic issues

Working with Leadership

Many impediments are outside the team’s control. This is the area where  Scrum Masters must step into a different role: They now just also put on hat of an organizational influencer. Some things that help are

• Translating team issues into business impact
• Using data instead of opinions
• Building relationships with decision-makers

For example: Instead of saying “dependencies are slowing us down”, say: “Our cycle time has increased by 30% due to cross-team dependencies, impacting release predictability.”   Leaders respond to impact, not frustration.

Measuring Impact

I always believe that what is measured gets improved. The principle applies to Impediment removal also. Impediment removal should lead to measurable outcomes: Some examples of these measurable outcomes are

• Reduced cycle time
• Improved flow efficiency
• Better predictability
• Increased team ownership

If these are not improving, it’s worth asking: Are we really removing impediments—or just managing them?

Closing Thought on How a Scrum Master Causes Real Impediment Removal

 Impediment removal is not about clearing obstacles faster. It is about changing the system so that fewer obstacles exist in the first place. That’s where Scrum Masters move from being facilitators…to becoming true enablers of transformation.

Scrum Masters evolution from Impediment Removal to a person who causes Impediment removal is the key to success

The ultimate evolution of the Scrum Master role is from someone who removes impediments to to someone who enables the system to remove those impediments continuously This means:

• Coaching teams to solve their own problems
• Building awareness of system constraints
• Shifting from reactive to proactive

At this stage, impediment removal is no longer an activity. It becomes part of the team and organizational culture.

The post Why Removing Blockers Isn’t Enough: How a Scrum Master Causes True Impediment Removal appeared first on World Of Agile.

Shared Roles in Scrum Teams: Real-Life Challenges and What Works

In this section, we will look focus on Shared Roles in Scrum Teams: Real-Life Challenges and What Works. We will explore how the value delivery gets impacted when one person takes on more than one Scrum Role within a Scrum Team. This article is part of an ongoing series on real-life scenarios that many Scrum Teams face.

“We are a small team, so one person needs to take up multiple roles. We do not have a budget for a dedicated Scrum Master (or a dedicated Product Owner)”

This is one of the most common statements I hear. Especially when organizations start their Agile journey. On the surface, it does sound practical. Why not optimise for efficiency? Why not reduce overhead? After all, if someone has the bandwidth, why not let them wear multiple hats?

However, in reality, role sharing in Scrum often creates more challenges than it solves. The issue is not a matter of capability—it is a conflict of accountability.

How do the three Roles (or Accountabilities as stated in the Scrum Guide) Interact

The people in the boat in the above diagram represent a Scrum Team. The rowers symbolize the developers. They work in sync to move the product forward through their collective effort.

The Product Owner stands at the back with the rudder, setting direction and ensuring the team is heading toward the right outcomes. His focus is always on the Value

At the front, the drummer, represents the Scrum Master. He is maintaining rhythm and helping the team stay aligned and effective. He is the facilitator who helps the Scrum Team become more effective

Success for the Scrum Team depends on coordination among the three roles. Success comes when direction, facilitation, and execution come together, the team moves faster and with greater purpose.

Below, I have described some common questions around role sharing—and what typically unfolds.

1. Can the Scrum Master and Product Owner Be the Same Person?

In one organization, I worked with a team where the same individual was acting as both Scrum Master and Product Owner. Initially, it seemed efficient—one person managing both delivery and process.

However, during Sprint Planning, this person consistently pushed the team to take on more work. In Retrospectives, when the team raised concerns about overload, the same person facilitated the discussion.

Over time, the team stopped speaking openly.

Snehamayee’s perspective

While the Scrum Guide does not explicitly forbid this, in practice, this combination rarely works well. The accountabilities of a Scrum Master and a Product Owner are fundamentally different. The Scrum Guide says that

• The Product Owner is accountable for maximizing product value
• The Scrum Master is accountable to help the Scrum Team become more effective

When the same person plays both roles, they need to balance conflicting priorities.

Impact:

• Reduced transparency
• Limited psychological safety – Product Owner is the Value Mximizer. In that role the often
• biased decision-making.

What can be done?
Keep these roles separate. Even in smaller setups, this separation creates balance and enables better team dynamics.

2. Can the Scrum Master Also Act as a Developer?

In another team, the Scrum Master was also a senior developer. During the Sprint, he was deeply involved in coding critical features.

When impediments arose, they often remained unresolved for days—not because they were complex, but because the Scrum Master was busy with delivery work.

Daily Scrums became quick updates rather than meaningful conversations.

Snehamayee’s perspective
This setup is more workable than combining Scrum Master and Product Owner roles, but it still creates tension.

The Scrum Master role requires availability and focus. When combined with development work, facilitation and coaching often take a back seat.

Impact:

• Delayed impediment resolution
• Reduced focus on team improvement
• Scrum events becoming less effective

What we can do?
This model can work temporarily, especially in smaller teams. However, it requires conscious effort to ensure that Scrum responsibilities are not neglected.

3. Can the Product Owner Also Act as a Developer?

I once worked with a technically strong Product Owner who also contributed to development. Initially, this helped speed up delivery.

However, over time, a pattern emerged. Backlog refinement became less structured, stakeholder conversations were delayed, and priorities were not always clear.

The Product Owner was simply too busy writing code to focus on product direction.

Snehamayee’s perspective
While this setup may seem efficient, it often impacts the quality of product ownership.

The Product Owner’s role requires continuous engagement with stakeholders, clarity on priorities, and proactive backlog management.

Impact:

• Backlog items lack clarity
• Stakeholder alignment weakens
• Product decisions get delayed

What can be done?
A Product Owner with technical skills can support the team when needed, but their primary focus should remain on product value and direction.

4. One Person Supporting Multiple Teams as a Scrum Master or a Product owner

In a scaled setup, I worked with a Product Owner who managed the backlog for three teams working on the same product. Initially, there were concerns about bandwidth.

However, over time, this setup created better alignment across teams. Priorities were clearer, and duplication of work reduced.

Similarly, a Scrum Master supporting two teams helped bring consistency in practices and improved cross-team collaboration.

Snehamayee’s perspective
This approach is often more effective than combining roles within a team.

When one Product Owner supports multiple teams, it strengthens product-level thinking. A Scrum Master across teams can identify systemic issues and address them more effectively.

Impact:

• Improved alignment across teams
• Consistent prioritization
• Better coordination

Some Points to keep in mind

• Beware of a too busy Scrum Master (or Product Owner). If we ask one person to be the Scrum Master (or the Product Owner) for too many teams, they become mere coordinators. It limits the value they add and the bandwidth they have for team members.
• Position an Experienced Person with proven credentials, Scrum Master and Product Owner, both are senior leadership roles – People take time to grow in these roles. If we ask someone inexperienced to function as a Scrum Master (Or a Product Owner) of multiple teams, we risk the role getting diluted
• Empower and Cross Train The Developers

Final Thoughts about  Shared Roles Among Strum Teams

Role sharing in Scrum is often driven by practical constraints. While some combinations may work temporarily, others introduce deeper challenges that impact team effectiveness.

From my experience, a few principles stand out:

• Avoid combining Scrum Master and Product Owner roles
• Be cautious when mixing Scrum roles with delivery responsibilities
• Prefer sharing roles across teams rather than combining them within a team

Ultimately, it is not about rigidly following rules, but about ensuring that each accountability is fulfilled effectively.

When roles are clear, teams collaborate better, decisions are more balanced, and delivery becomes more predictable.

The post Shared Roles in Scrum Teams: Real-Life Challenges and What Works appeared first on World Of Agile.

Real-Life Scenarios in Product Backlog Refinement

1. Refinement Becomes a Status Meeting

Snehamayee’s Perspective

• Establish Proactive Status Reporting Mechanisms – Help the Scrum team to have the discipline to provide regular updates on the team collaboration space. Regular updates to the project management tool, such as JIRA, or even a message in a team space ( for example, a Slack channel) will help. What matters is the discipline to give regular updates.
• Use Daily Scrum wisely– Coach the team to review the status before the Daily Scrum and get their questions answered in the Daily Scrum. This helps to establish Transparency and have clarity about current items. Which, in turn, will help to protect the sanctity of the Refinement meeting
• Establish a Parking lot system – If discussions do digress during refinement, teach teams to leverage a parking lot system – where we “park” unrelated but important items. Revisit the parking lot post the refinement and/or during the next Daily Scrum

2. Endless Debates Derail the Session

Snehamayee’s Perspective

3. Too Many Items, Too Little Depth

Snehamayee’s perspective

4. Wrong People in the Room (or Missing the Right Ones)

Snehamayee’s Perspective

Final Thoughts about Product Backlog Refinement and the common real-life scenarios seen

• Lack of focus on refinement – Teams often treat refinement as just something to do
• Poor participation – not having the right participants. Either too many people or the wrong people make refinement less effective than it can be

The post Product Backlog Refinement – Real Life Scenarios appeared first on World Of Agile.

Scrum Master Role in Product Backlog Refinement

We will discuss the Scrum Master Role in Product Backlog Refinement in this article. This article is a part of our series about a deep dive in Scrum Master Role and responsibilities.

As per the Scrum Guide, Product Owner is accountable for the Product Backlog. But the Product Owner alone cannot decide all details about the Product Backlog. They need to work collaboratively with the Developers as well as Stakeholders. Scrum Master helps the Product Owner to refine the Product Backlog. Some of the ways the Scrum Master can do help the Product Owner for the Product Backlog refinement Activity are as below

Tools and Techniques for the Product Backlog Refinement

Product Owners usually have good knowledge of the Product and Business Domain. However, they often struggle with the tools and techniques. These tools and techniques can be help to

• Different formats to write requirements – User stories is ONE way to write requirements. But there are other possible ways to express requirements. Some of these are Use-cases, workflows, BDD scenarios, spike stories. etc. Scrum Master can help the product Owner to choose right techniques to express the requirements
• Prioritization Techniques Technics to decide the priority and Order for the items in Product Backlog. Some of the famous prioritization techniques are MoSCoW, Kano Model, WSJF etc.
• Decomposition Techniques – These techniques help to break down the items in smaller manageable pieces of work. Some of the common techniques are explained in this article – How to split user stories
• Estimation Techniques – These techniques help the Developers to estimate the size of the work items in the Product Backlog. Some of the common techniques are Tshirt sizing / Planning Poker.

Facilitate the Product Backlog refinement sessions

Refining the product backlog will involve with Developers as well as Stakeholders. It is often difficult to build consensus amongst the large array of people. Some things to consider are

Coach Stakeholders and Developers as necessary

Often Stakeholders and Developers both are reluctant to take out time for the Product Backlog Refinement. They might need to be coached. Some areas to coach may be

• If Developers do not spend time on Product Backlog Refinement, some of the impacts may be
  • Dependencies are not identified
  • Developer input will not be considered while deciding estimates
  • Developers do not understand the functionality well and that may hinder their ability to deliver good quality product on time
  • Sprint Planning May suffer
• If Stakeholders do not spend time on Product Backlog Refinement, some of the impacts may be
  • Items with lower value might be ranked higher up in Product Backlog, this will lower the final value delivered
  • Developers might choose wrong items in Sprint Planning again impacting the Value delivered
  • Changes will be identified later- impacting the overall costs

The post Scrum Master Role in Product Backlog Refinement appeared first on World Of Agile.

Scrum Master Role in Sprint Retrospective

We will discuss the Scrum Master Role in Sprint Retrospective in this article. This article is a part of our series about a deep dive in Scrum Master Role and responsibilities

Scrum Master Role in Sprint Retrospective is more Involved

Sprint Planning, the daily Scrum and Sprint Review all see the Scrum Master as predominantly a facilitator. However, this changes with Sprint Retrospective. Of course, the Scrum master does participate as a facilitator in the Sprint Retrospective. But in this Scrum Event Scrum Masters role goes beyond facilitator.

Scrum Guide says that “The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.” Elsewhere the guide also says that “The Scrum Master is accountable for the Scrum Team’s effectiveness.” When we consider these two statements, it becomes clear that Scrum Master needs to be much more than a facilitator for this Scrum Event.

Facilitation of Sprint Retrospective

• Set the Stage It helps to clearly state the goal of the Sprint Retrospective at the beginning of the session.
• Manage The Timebox – Track time spend on each segment of the Scrum Event and track over all time spent. This will help with overall effectiveness of the session.
• Create a psychologically safe environment – Establish a safe place for the Scrum Team to share their views. Sprint Retrospective often turn into a blame game or crib session. It is important to keep the discussions polite and focused on improving the process.
• Encourage Active Participation: Make sure everyone has a chance to contribute. Ask open-ended questions to stimulate discussion. Actively engage quieter team members.
• Be an Active Listener – It is very important to be empathetic towards the Scrum Team members. Scrum Master should pay attention to both the verbal/non verbal signals as well as observe the team dynamics
• Follow the Chosen Format: Guide the team through each segment of the retrospective, such as identifying what went well and areas for improvement.
• Dig Deeper: Ask follow-up questions uncover root causes or underlying issues. Some techniques like the “5 Whys” may help for this.
• Help the Scrum team to create an actionable plan – Often the Scrum Teams discuss the same things again and again in every Sprint Retrospective. This makes the team lose interest. It is very important to have action items that can be measured and tracked. One good working agreement can be “at least one action item should be included for the immediate next sprint.” This will help to show ongoing progress. Such an ongoing progress helps to keep the Scrum Team engaged and interested.

The post Scrum Master Role in Sprint Retrospective appeared first on World Of Agile.

Scrum Master Role in Sprint Review

We will discuss Scrum Master role in Sprint Review. This article is a part of the series discussing Scrum Master roles and responsibilities in detail.

Scrum Guide says that, the purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. In order for the Sprint Review to be effective, we need to focus on how to get most useful feedback about the increment. Scrum Master can help the Scrum Team to prepare for and conduct this event in such way that we can get the best feedback.

Scrum Master limitations during the Sprint Review Event

In order to understand Scrum Master Role & Responsibilities in Sprint Review, first we need to understand the limitations a Scrum Master has during Sprint Review.

The Scrum Master is primarily the leader who serves. They are the facilitator and coach for the Scrum Team. They are not a decision-maker about the product or a technical contributor. This means they have to keep their limitations in mind while helping the Scrum team for Sprint Review

• No Direct Authority Over Decisions about the Product – Scrum Master does not have any direct authority over the Product Decisions or Product Backlog contents
• Cannot Force Stakeholder Engagement or the Collaboration between Scrum Team and Stakeholders– For a fruitful Sprint Review, the Scrum team members and Stakeholders need to collaborate – Scrum Master can try to facilitate but they can not enforce the Stakeholder engagement or the Collaboration between Scrum team members and Stakeholders

What Scrum Master does before Sprint Review

Help the Scrum Team to be ready to showcase a Good Quality and “done” Increment

In order to get good feedback, Stakeholders need to know exact state of the Increment. If the Scrum Team showcases some items which are not completely done, this will reduce the transparency. Scrum Master helps the Scrum Team to

• Create as well as follow a well defined and fit for use Definition of done
• Coach Product Owner to spend time with Developers and give some feedback even before Sprint Review – this helps to identify defects/issues earlier. Once the Developers have corrected the issues/solved the defects, during the actual Sprint Review the Scrum Team and Stakeholders can collaborate on the next steps for the product!
• Help the Scrum Team to be ready with the plan for “showcasing the Increment” – its important that the team demonstrates working Increment rather a one way presentation. This will also include helping the Scrum Team be ready with logistics of this event

Help Stakeholders as well as Scrum Team members to understand the purpose of Sprint Review

• Often members as well as developers misunderstand the purpose of sprint review. This scrum event is looked at as an acceptance forum or a sign off forum. Scrum Master coaches people to have the acceptance activity done prior to Sprint Review
• Scrum Master helps the stakeholders understand the purpose behind sprint review no what to expect during this event and come prepared to give constructive feedback

What Scrum Master does during Sprint Review

During the Sprint Review, Scrum Master will usually take a facilitator stance. They will help the Scrum Team and Stakeholders to collaborate.

• The Scrum Master facilitates the Sprint Review. Helps to keep the discussion focused and within the timebox.
• In order to encourage active participation from all attendees, Scrum master works to create a safe and inclusive environment.
• Encourages every one to share their feedback on increment and come up with some constructive action items that can help the Scrum team to meet the Product Goal
• Helps the Product Owner to track and document the suggested changes to Product Backlog

The post Scrum Master Role in Sprint Review appeared first on World Of Agile.

Agile Estimations with Planning Poker

This article discusses how Agile Estimations work with Planning Poker.

Planning Poker is a collaborative estimation technique used by many Agile Team. This technique helps to determine the relative effort required to complete any piece work – A story, Epic or even a Task! Planning poker uses story point estimations as base. To understand more about Story Points, read this article. Planning combines multiple techniques like group discussion, agreement-building, and individual input. This helps the team to ensure more practical and inclusive estimations.

Planning Poker and how its used in Agile Estimations

Planning poker uses a deck of cards with the modified Fibonacci series. All developers have their own copy of this deck. Once the Product Owner explains the functionality, all developers show up a card with their own estimate. Then the team as a whole will engage in a discussion about the estimates. This discussion helps to build a common shared understanding. So its important not to skip.

Some key things to remember are

1. All Developers participate in Planning Poker
2. Product Owner can clarify the functionality and negotiate the scope of the work. They can not “push” the team to change the estimates
3. Scrum Master usually facilitates the session and keeps it on track

Steps for Planning Poker

Get Ready for Agile Estimations With Planning Poker:

1. Gather the team: Ensure all relevant team members, including developers, testers, and product owners, are present.
2. Prepare the deck: Use a standard deck of Planning Poker cards, typically following the Fibonacci sequence: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. You can also use a digital tool for virtual sessions. ScrumPoker is one such tool. Of course, Scrum Teams should decide which tools works best for them!

Actual Planning Poker meeting

Explain the Piece of work (Epic /Feature/Story/Task):

• The Product Owner describes the user story or task to be estimated. This explanation includes acceptance criteria and other relevant details.
• Team members can ask clarifying questions.

Discuss the work:

• Discuss and agree upon assumptions if needed
• The team then discusses
  • potential challenges, risks, or dependencies
  • What are subcomponents to consider – Design/Code/Test/Deploy etc

Select Cards and Reveal Individual Estimates:

• Each team member independently selects a card that represents their estimate of the task’s effort or complexity.
• The estimate considers end to end work needed for all subcomponents discussed above.
• All participants reveal their chosen cards simultaneously to avoid influence or anchoring.

Discuss Variation and Re-Estimate (If Necessary):

• If there’s a significant variation in estimates, the team members then discuss their reasoning.
• Those who chose higher or lower estimates explain their perspectives, leading to a better understanding of the task.
• After the discussion, participants may select a new estimate. This process can repeat until the team reaches consensus or a reasonable estimate. However, what many teams instead do is have one or two open discussions and then have a working agreement on how to proceed. The working agreement can be discussed prior. Some examples of these working agreements are – higher estimate prevails / Team goes for average/ If we know person working on the item –> we respect their choice etc

Advantages of doing Agile Estimations with Planning Poker

• Shared Understanding: Discussions during the Planning Poker exercise bring everybody on a common ground. This helps transparency about work being done. This helps not only in Agile Estimations but also in actual execution. The discussion also helps to make the risks and dependencies visible
• Improved Accuracy: All the Developers (Programmers / testers /analysts and other people in team) participate together in Planning Poker for Agile Estimations. This collaborative approach increases the accuracy of estimations.
• Team Building: Entire scrum team works together for planning poker. Such working and discussing together fosters teamwork and communication.
• Reduced Bias: Each team member independently decides their estimate. Then everybody shows their “number” at the same time. This way of silent voting helps to minimize the bias from dominant people or people with perceived seniority /authority.

Challenges to anticipate while doing Agile Estimations with Planning Poker

• Too Time consuming – Sometimes Planning Poker and its discussions consume a lot of time. This then may make the teams reluctant to participate as they think it does not add value.
• Distributed Teams – Today many Scrum Teams work from more than one location. Sometimes, it is quite difficult for these teams to come to one common location for estimation work
• Resistance to change – good old “we want to do things the way we have been doing them!” is a very common opposition to anything new. Teams often resist any new technique or approach.
• Personality Issues – Some people tend to dominate discussions. While some other people, do not speak up even when necessary.

The post Agile Estimations with Planning Poker appeared first on World Of Agile.

Scrum Master Role in Daily Scrum

In this article, we will discuss Scrum Master Role in Daily Scrum. This article will help you to understand the Daily Scrum better. Some common real life scenarios around daily scrum are explained in this article

If you want to read more about over all day to day Scrum Master Roles and Responsibilities, the linked article series can help

Scrum Guide Says Only Developers are mandatory in Daily Scrum. Then how can Scrum Master help where are not even required? Read on to find out Scrum Master Role in Daily Scrum

Observer

Even though Scrum master is NOT mandatory during the Daily Scrum, they can learn a lot if they can take the role of an unobtrusive oberserver during the Daily Scrum. Scrum Masters can get an insight into many key areas

• Team Dynamics and interaction patterns – Daily Scrum will uncover a lot of communication patterns within the Scrum Team – do some people tend to dominate? Are few people unduly silent?
• Team Skills and Scrum Knowledge – Does the Scrum Team know what Daily Scrum is? Are they able to facilitate the session well? Do they create actionable plan for the next day
• Team maturity in terms of Self management – Self management is a difficult trait to inculcate. Self Managed Scrum Teams will be more independent and will manage their Daily Scrum effectively. However, Scrum Teams that are NOT yet self managing will tend to wait for Scrum Master to run the meeting.
• Any recurring or long persisting impediments. Often impediments recur or go on for a long time because of some underlying issue. If the Scrum Master makes these impediments and patterns visible to everyone, it will help the Scrum Team address the root cause.

These observations will form the basis of coaching/Facilitating and mentoring a Scrum Master can do through out the day

Facilitator (ONLY if /when needed):

Daily Scrum is a Developer forum and NOT a status meeting. Scrum Master should facilitate only when Scrum Team does not know how to do it themselves. As a part of this Facilitation it may be helpful to

• Help to keep the event within the 15-minute time-box.
• Keep the discussions focused around what will be the actionable plan for next working day
• Gently help the Scrum Team to avoid diving into problem-solving right during the Daily Scrum

Coach – Beyond the 15 minutes of Daily Scrum

Scrum Master Observations during Daily Scrum will often form the basis of Coaching through out the day

• Guide the Developers to take ownership of
  • The Daily Scrum.
  • Cause impediment removal
• Encourage collaboration and a self-managed approach.
• Make the anti-patterns visible .Then help the scrum team to address those. Some common Anti-Patterns may be
  • Turning the meeting into a status update for the Scrum Master.
  • Not creating an actionable plan
  • Trying to solve impediments during the Daily Scrum
  • Extending 15 Minute timebox routinely

Teach Formats and Techniques Of Daily Scrum

One key Scrum master Role in Daily Scrum is to teach relevant tools and techniques. Some key areas to consider can be

• Alternative formats other than 3 question format
• Techniques to manage timebox – some examples may be – meeting after and flexible timebox
• Gamification techniques
• Some Techniques for managing Daily Scrum effectively

Read this article to understand more about Formats and techniques of daily Scrum

What the Scrum Master Should Avoid

• Becoming the de-facto leader of the Daily Scrum: The Developers should learn to own and manage the Daily Scrum, not the Scrum Master.
• Turning It Into a Status Meeting: Daily Scrum is not about reporting status to the Scrum Master( or the Product Owner or anyone else for that matter!)
• Problem Solving in Real-Time: Encourage the team to take detailed discussions offline.

Visit Blog Home

Scrum Master Role in Daily Scrum

 

In this article, we will discuss Scrum Master Role in Daily Scrum. This article will help you to understand the Daily Scrum better. Some common real life scenarios around daily scrum are explained in this article

If you want to read more about over all day to day Scrum Master Roles and Responsibilities, the linked article series can help

Scrum Guide Says Only Developers are mandatory in Daily Scrum. Then how can Scrum Master help where are not even required? Read on to find out Scrum Master Role in Daily Scrum

Observer

Even though Scrum master is NOT mandatory during the Daily Scrum, they can learn a lot if they can take the role of an unobtrusive oberserver during the Daily Scrum. Scrum Masters can get an insight into many key areas

• Team Dynamics and interaction patterns – Daily Scrum will uncover a lot of communication patterns within the Scrum Team – do some people tend to dominate? Are few people unduly silent?
• Team Skills and Scrum Knowledge – Does the Scrum Team know what Daily Scrum is? Are they able to facilitate the session well? Do they create actionable plan for the next day
• Team maturity in terms of Self management – Self management is a difficult trait to inculcate. Self Managed Scrum Teams will be more independent and will manage their Daily Scrum effectively. However, Scrum Teams that are NOT yet self managing will tend to wait for Scrum Master to run the meeting.
• Any recurring or long persisting impediments. Often impediments recur or go on for a long time because of some underlying issue. If the Scrum Master makes these impediments and patterns visible to everyone, it will help the Scrum Team address the root cause.

These observations will form the basis of coaching/Facilitating and mentoring a Scrum Master can do through out the day

Facilitator (ONLY if /when needed):

Daily Scrum is a Developer forum and NOT a status meeting. Scrum Master should facilitate only when Scrum Team does not know how to do it themselves. As a part of this Facilitation it may be helpful to

• Help to keep the event within the 15-minute time-box.
• Keep the discussions focused around what will be the actionable plan for next working day
• Gently help the Scrum Team to avoid diving into problem-solving right during the Daily Scrum

Coach – Beyond the 15 minutes of Daily Scrum

Scrum Master Observations during Daily Scrum will often form the basis of Coaching through out the day

• Guide the Developers to take ownership of
  • The Daily Scrum.
  • Cause impediment removal
• Encourage collaboration and a self-managed approach.
• Make the anti-patterns visible .Then help the scrum team to address those. Some common Anti-Patterns may be
  • Turning the meeting into a status update for the Scrum Master.
  • Not creating an actionable plan
  • Trying to solve impediments during the Daily Scrum
  • Extending 15 Minute timebox routinely

Teach Formats and Techniques Of Daily Scrum

One key Scrum master Role in Daily Scrum is to teach relevant tools and techniques. Some key areas to consider can be

• Alternative formats other than 3 question format
• Techniques to manage timebox – some examples may be – meeting after and flexible timebox
• Gamification techniques
• Some Techniques for managing Daily Scrum effectively

Read this article to understand more about Formats and techniques of daily Scrum

What the Scrum Master Should Avoid

• Becoming the de-facto leader of the Daily Scrum: The Developers should learn to own and manage the Daily Scrum, not the Scrum Master.
• Turning It Into a Status Meeting: Daily Scrum is not about reporting status to the Scrum Master( or the Product Owner or anyone else for that matter!)
• Problem Solving in Real-Time: Encourage the team to take detailed discussions offline.

The post Scrum Master Role in Daily Scrum appeared first on World Of Agile.

Scrum Master role in Sprint Planning

We will discuss Scrum Master role in Sprint Planning. This article is a part of the series discussing Scrum Master roles and responsibilities in detail.

Scrum Guide says that entire team creates the plan for the the sprint together. Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. Scrum Master helps them to ensure effective planning

Scrum Master limitations during the Sprint Planning Event

In order to understand Scrum Master Role & Responsibilities in Sprint Planning, first we need to understand the limitations a Scrum Master has during Sprint Planning

• A good Scrum Master does not enforce their decisions about what and how much work the Scrum Team chooses to do in the Sprint.
• They do not micromanage how the Scrum Team conducts the Sprint Planning. Instead they coach the Scrum to Self Manage and plan their work

What Scrum Master does before Sprint Planning

Help to make sure that the Product Backlog is refined enough for Sprint Planning

During the Sprint Planning, the Product Owner has to ensure that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. One of the key Scrum Master Role & Responsibilities in Sprint Planning is to help with this.

• Coach the Product Owner to continuously work on the Product backlog. So that Scrum Team has enough items to choose to work during Sprint
• If needed, help the Product Owner with some tools and techniques to manage the the Product Backlog.
• Coach the Stakeholders to carve out time before the Sprint Planning for Product Backlog refinement. This will help to ensure that only valuable items are placed at the top of the Product Backlog
• Coach the developers to carve out time before the Sprint Planning for Product Backlog refinement. Often the Developers are focused on achieving the current Sprint Goal. This sometimes makes them reluctant to take out time for Product Backlog Refinement. But when the Developers do participate, it ensures that items at the top of the Product Backlog are well understood and broken down in manageable sizes.
• If needed, coach the Scrum Team members in estimation/ work breakdown techniques

Helping The Scrum Team get ready for Sprint Planning

• Teaching the Scrum Team about Sprint Planning and its importance
• Sometimes, the Scrum Master will need to coach the Product Owner on why they should not try to pressurize the Developers during Sprint Planning
• Work with Developers as well as Product Owner to assess if the Scrum Team will need to invite anybody out side the Scrum Team for clarification purposes.
• Work with Scrum Team to identify issues in Past Sprints that the Scrum Team should keep in mind when they plan the upcoming sprint

Facilitating Sprint Planning Event

A Scrum Master can play an important role in ensuring smooth and productive Sprint Planning . Please consider some of the below items to help the Scrum Team during Sprint Planning.

• Help the Scrum Team to manage the timebox
• Facilitate the discussions within Scrum Team to help with productive discussions
• Managing Conflict: help the Scrum Team to manage their disagreements diplomatically . Help the team find common ground.
• Help the Scrum Team to keep the Focus: Redirect discussions that veer off-topic.
• Gently Engage the team to consider
  • the lessons learnt from past Sprints
  • Velocity and Capacity Available
  • Definition of Done
• Ask open ended questions which will help to
  • Identify risks and dependencies
  • Make realistic commitments – Avoid over and under commitment
  • Clarify the Sprint Goal and the selected items

The post Scrum Master role in Sprint Planning appeared first on World Of Agile.