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.

Scrum Doesn’t Fail—Organizations Do: What the Mirror Reveals

“We tried Scrum. It just didn’t work for us.” …

Over the years, I’ve heard this statement across industries, teams, and leadership levels. Whether in startups or large enterprises, the conclusion is often the same: Scrum failed.

But in my experience—working across Scrum, SAFe, and Kanban implementations—the pattern is strikingly consistent.

Scrum didn’t fail. It simply showed something the organization wasn’t ready to see.

Think of Scrum as a mirror

We often limit Scrum as a delivery framework—a structured way to build and ship products. But that view is incomplete. Scrum at its core is a system of transparency.

Scrum Events create visibility. Its artifacts make progress transparent, while the cadence enables inspection. When you introduce this level of transparency, and hidden issues like misalignment, inefficiencies, unclear ownership begin to surface.

I’ve seen teams where, before Scrum, everything looked “on track” in status reports. Once these teams introduced Scrum, it immediately highlighted the missed dependencies, unclear priorities, and communication gaps. Scrum didn’t create chaos. It just removed our ability to hide it.

Why Scrum Works Beautifully in Theory

In theory, Scrum is elegant. It is built on Empiricism—Transparency, Inspection, and Adaptation. It assumes self-managing teams. It promotes incremental delivery of value.

In the training room, Scrum works beautifully. Teams quickly understand Scrum Accountabilities and what they do. People are able to grasp that the Scrum Events are meant to help with Transparency and how the Scrum Artifacts help to track the progress. They see the feedback loops clearly.

But theory assumes something critical. In the training we have the luxury of assuming that organizations are aligned to support these principles. Reality is often strikingly different. That’s where the mirror begins to reflect something deeper.

The Moment of Truth

The real test of Scrum doesn’t happen in the transformation workshops or certification Trainings. Scrum gets tested during the first few sprints.

I remember a Sprint Review in one organization. During their first Sprint Review, the Scrum Team presented their work. All Scrum team members had completed the Scrum Training. As such, they expected discussion and feedback during the Sprint Review. Instead, there was a complete silence. Stakeholders nodded politely, referred back to their notes about what was asked / what was there in “requirement docs” and then asked no questions. Instead, they quickly disengaged.

The team walked away thinking they failed. They even wondered if Scrum had failed for their team. But Scrum had just revealed something important. The issue wasn’t delivery—it was the absence of real stakeholder engagement. The solution was to train and educate stakeholders in Scrum – Instead the organization concluded that Scrum did not work for them.  This is the moment many organizations misinterpret. The discomfort they feel is not Scrum failing. It is the mirror reflecting reality.

What the Mirror Reveals

When Scrum is introduced, it begins to surface patterns—organizational habits that have existed for years but were never fully visible. I will give the some of the common patterns below

1. Command-and-Control Culture

In one team I observed, the manager insisted on attending (and controlling) the daily Scrum. People were aware of the authoritative way in which manager worked. As a result, every person addressed only the manager in their Daily Scrum.

“Yesterday I completed…” or “Today I will work on…” No one spoke with each other. Everyone reported the status upwards. This made it difficult to have an actionable plan for the next day

You cannot have self-organizing teams in a culture built on control. The problem was in the command-and-control culture. The mirror didn’t show a Scrum problem. It showed a leadership habit. Scrum Events are easy to implement. Meaningful change is not.

2. Output Over Outcome Thinking

Another team I worked once proudly celebrated their highest velocity sprint. Charts looked impressive. Story points were completed at record pace. When I asked about customer impact, the room went quiet. No one could connect delivery to value.

This is a classic confusion—optimizing for flow of work without understanding flow of value. Scrum had made progress visible. But the organization was measuring the wrong thing. They were holding the mirror at wrong angle. For this team, it helped to introduce Kanban flow principles within the Scrum structure

3. Role Confusion and Lack of Ownership

Scrum defines the Accountabilities quite clearly. In practice, organizations often dilute these. I remember a Product Owner who said, “I’ll need management sign off before we commit to this.”. The title of Product Owner existed. The authority did not.

Similarly, People often think Scrum Masters only the coordinators and MOM takers. Another common example is Scum Teams lack the cross-functional capability to truly own delivery.

Scrum didn’t create this confusion. The mirror exposed the lack of ownership.

4. System-Level Constraints

Perhaps the most powerful reflection Scrum provides is at the system level.

I worked with a team that consistently carried over work between sprints. On the surface, it looked like a planning issue. But a closer look revealed the real problem. External dependencies, approvals, and siloed teams constantly blocked the team’s progress. Scrum had surfaced the constraint. It did not create the constraint!

Planning an Enterprise Level Transformation with a Scaling Framework like SAFe helped the team on the ground

Use Scrum as a Diagnostic Tool

Across organizations, I’ve seen a recurring pattern—a simple loop that explains why Scrum succeeds or fails.

1. Scrum creates transparency
2. Transparency exposes dysfunction
3. The organization reacts—either by resisting or adapting
4. The outcome depends on that response

Scrum does not prescribe solutions. Its value lies in making those problems impossible to ignore.

Why Organizations think Scrum does not work?

So why do so many organizations conclude that Scrum doesn’t work? Because what it reveals is uncomfortable.

In one case, after just a few sprints, leadership decided Scrum was “too chaotic.” What had actually happened was that issues long buried under reporting layers were now visible in real time.

Transparency can feel like chaos when you’re not used to seeing reality clearly. It is far easier to change the framework than behavior.
Many organizations take the easy way out and choose to abandon Scrum rather than address control, ownership, or systemic constraints.
In other words, they look away from the mirror.

What Successful Organizations Do Differently to Make Scrum Work?

Not all organizations reject the reflection. Some learn from it.

I worked with a leadership team that treated every issue surfaced in Scrum as valuable data. They took the Sprint Retrospectives seriously. They empowered their Product Owners and removed the systemic blockers actively.

They didn’t ask, “Why is Scrum not working?” Instead, they asked, “What is Scrum showing us?”

Over time, they shifted from control to enablement, from output to outcomes and from local optimization to system thinking. They didn’t avoid the mirror. They used it the way a mirror should be used. They used Scrum as a diagnostic tool or an continuous improvement forum

Mindset Shift from Scrum Implementation Vs Agile Transformation does the magic

Many organizations believe they are adopting Scrum when they are simply installing it. Events are in place. Accountability titles are assigned. Tools are configured. But they do not fundamentally change their behaviour.

In contrast, I’ve seen organizations where small shifts in decision-making, ownership, and leadership behavior created significant impact—even with imperfect Scrum practices.

The difference is clear. Scrum implementation is a process change. Agile transformation is organizational. The Transformation doesn’t demand better Events. It demands better alignment between structure, behavior, and intent.

Conclusion: Don’t Fix Scrum—Fix What It Shows You

Scrum does not promise comfort. It promises clarity. And clarity, when taken seriously, demands change.

Across every organization I’ve worked with, the outcome was never determined by how well Scrum was implemented. It was determined by how the organization responded to what Scrum revealed.

So the next time Scrum feels difficult, chaotic, or ineffective—pause before blaming the framework. Don’t break the mirror -Look at the reflection.

Because Scrum didn’t fail your organization. It revealed what was broken.

Read this series of articles to understand many such common antipatterns seen in Scrum

The post Why Scrum Often Fails? appeared first on World Of Agile.

Scrum guide does not mention user stories specifically, but they have become the norm to articulate user requirements for the products while working in Scrum. Read this article to understand more details about the concept of user story

Writing user stories helps teams build better software. A clear story shows what the user needs and why it matters. But writing good stories is not always easy. Even skilled teams run into problems. Some stories are too short, too long, or too focused on tech details. These issues, called bad patterns, can slow teams down. They can also confuse people. In this article, we will look at the common problems with user stories. We will also show how to avoid these mistakes. Finally, we will share tips to write stories that help your team and your users.

User Story Anti Patterns

The Incomplete Story Antipattern

As a website visitor, I want to login using social media

What is wrong

Too vague and incomplete — it doesn’t say which social platforms or what should happen after login.

Suggestions

• 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

As a System, I want to log every transaction so we have a trail

What is wrong

System is not a human being – It does not have a value perception! When we write a user story like this it reduces the talk about “human”. It also reduces the possibility of discussion and better approaches to get the same work done

Suggestions

Add the story from perspective of a human being will want the transaction trail  for example,

“As an auditor, I want all transactions to be logged so I can trace activity.”

“As a compliance officer, I want a transaction log so we meet regulatory requirements.”

Anti Pattern: Should be An Epic Instead Of Story

As a user, I want a new reporting module so I can see all company data.

What is wrong

Too big and unclear — “all company data” is too broad and undefined.

Suggestions

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

Too Much Detail Anti Pattern

As a user, I want a dropdown menu with options A, B, and C on the settings page, which upon selection updates the configuration file in XML format, so I can customize my preferences.

What is wrong

Too detailed — includes tech building and screen design design.

Suggestions

• 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

As a stakeholder, I want better performance so the system is faster.

What is wrong

Too vague — “better performance” and “faster” are not measurable.

Suggestions

• 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

As a customer, I want to register for an account and log in with my new credentials so I can access my profile and update my shipping address.

What is wrong

Too large — combines multiple actions in one story.

Suggestions

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

Technical Story Anti Pattern

As a system, I want to upgrade the database to version X.Y so we are on a supported version.

What is wrong

The system is not a real user — this is a tech task. Not everything needs to be a User story

Suggestions

• 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

As a user, I want the company logo to be visible on every page so I know what website I am on.

What is wrong

The value seems weak or obvious — this could be just a design standard.

Suggestions

• 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

As a user, I want a dropdown with autocomplete and API-based search so I can find products quickly.

What is wrong

Prescribes a solution — too focused on how, not what the user needs.

Suggestions

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

Too Many Users Anti Pattern

As a user and admin, I want to be able to log in to manage my preferences and user accounts.

What is wrong

Mixes two user types with different needs in one story.

Suggestions

• 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).

Always write stories from the user’s point of view. Think about what they want to do and why it matters to them.

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

Explain what the user wants to achieve. Add a reason by saying “so” to show the value or goal.

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

Each story should cover one major goal. If it’s too big, break it into smaller stories.

Avoid tech or building details.

Focus on what the user needs, not how the team will build it. Let the team decide the best solution.

Make stories testable with clear acceptance criteria.

List clear steps or checks to know when the story is done. This helps everyone agree on what “done” means.

Use simple, clear language (no jargon).

Choose plain words that everyone can understand. Avoid tech terms or company slang.

Separate different roles/user types into separate stories.

If different users have different needs, write a story for each one. This keeps each story focused and clear.

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

Use exact words. Say how much faster or what “better” means in clear terms.

Ensure each story delivers user value.

The user should gain something useful from each story. If not, rethink the story.

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

Describe what needs to happen, not how to build it. Trust the team to find the best way.

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

Real Life Issues related to Scrum Team Velocity

In this section we are going to discuss about Real Life Issues related to Scrum Team Velocity. Velocity as a concept is not discussed explicitly in Scrum Guide. However, Velocity indeed is a commonly used development practice

The biggest challenge regarding velocity is often inconsistent or reducing velocity: If your teams are seeing a downwards trend in velocity or if the Velocity is inconsistent, some factors to consider could be

1. Inconsistent Workload and Scope Creep:

• Over ambitious Sprint Goals: Setting unrealistic or overly optimistic Sprint Goals can lead decreased productivity. In addition, Product owners often pressurize the Developers to accept more work in their zeal to deliver value. As a result, the Developers are not able to plan well.
• Scope Creep: Often the Product Owners ask the Developers to pitch in to unplanned work outside the sprint. Sometimes, they ask the Developers to accept new stories not planned in the Sprint. In these cases, unplanned work will derail sprint plans and impact velocity.
• A Product Backlog which not designed well: Sometimes, the Product Backlog items are not properly prioritized, or the Items selected in the Sprint are not broken down sufficiently. This makes it difficult for Developers to predict how much work to pull in the Sprint.

2. External Factors and Impediments:

• Technical Debt: Accumulated technical debt can make the system unpredictable. This causes a slowdown in the development work. As a result, we see reduced velocity.
• Organizational Impediments: Bureaucracy, lack of resources, or inflexible processes can create bottlenecks. These bottlenecks usually impact the Scrum Team Velocity.

3. Scrum Team Factors:

• Changes in Scrum Team: New team members can impact velocity as they adapt to the team and processes. If any existing team member moves out of the team, the remaining team members may take some time to adjust to the new reality.
• Team Motivation Levels: Low morale, burnout, or lack of motivation can negatively affect productivity.
• Communication Barriers: Poor communication can lead to misunderstandings, delays. In turn, these delays lead to decreased efficiency.

4. Misunderstanding and Misuse of Velocity:

• Focusing on the Number: Prioritizing just the velocity number over quality may lead to long-term problems. Some examples of these issues are incorrect data reporting and representation. When the Scrum Teams are solely judged on basis of Velocity – they may be tempted to slice and dice the data in order to show a project as “green”!
• Using Velocity as the sole Prediction Tool: Relying solely on past velocity to predict future performance can be misleading. Capacity mis-calulation is a very common reason velocity to appear low. Along with Valocity we should looks for
  • Available Capacity
  • Other planned work (for example, a planned release in previous Sprint may mean more time spent in Production firefights, a planned training will lead to team having less bandwidth)
  • Any widespread cultural events (for example, Diwali in India)

Overcoming the common Real Life Issues related to Scrum Team Velocity

To address these challenges, Scrum Masters can choose several strategies :

• Foster a Culture of Ongoing Improvement: Leverage the Sprint Retrospectives to identify improvement areas and implement changes. These changes then can help the Scrum Team to better Plan their work.
• Prioritize Technical Debt: Work with the Product Owners to Prioritize Tech Debt removal work. This will enable the Developers to allocate time to address technical debt to prevent it from hindering future development. As a result, over all system stability will increase.
• Effective Impediment Removal: Help the Scrum Team to actively identify and resolve impediments that impact the team’s progress.
• Promote Transparency and Open Communication: Encourage open and honest communication within the team and with stakeholders.
• Set Realistic Sprint Goals: Work with the team to set achievable goals that balance productivity and sustainability.
• Focus on Quality over Quantity: Prioritize delivering high-quality work over rushing to meet unrealistic deadlines.
• Use Velocity as a Tool, Not a Target: Use velocity to track trends and identify areas for improvement, rather than as a rigid performance metric.
• Build a Strong Team Culture: Foster a positive and supportive team culture that encourages collaboration and innovation.

Recognizing these challenges and adopting effective strategies will help Scrum Masters to assist their teams in maintaining consistent and sustainable progress, which leads to the delivery of high-quality products and services.

The post Real Life Issues related to Scrum Team Velocity appeared first on World Of Agile.

Common Misconceptions

People think that just by moving to Scrum all their issues will get resolved and magically all timelines will be met, no budgets will ever get overrun, all people will be happy, all customers will be happy, all changes come free and so on….

What Really is Scrum?

Scrum is a framework for solving Complex Adaptive Problems. Complexity means “Unknown-ness”. The Unknowns can be on requirements or on solutions. Where things are unknown, you cannot make detailed plans and just track the plan to closure. In such situations where things are unknown, what you see in front of you can be the only decision factor. Taking decisions based on what you see and constantly Inspect and Adapt based on what you see is called “Empiricism” or “Empirical process Control”. Scrum is a framework which sits on the “Empirical Process Control Theory”. For known problems (requirements known and solutions known), you will not need the inspect-adapt approach. The approach used for known problems is called “Defined Process Control”. Waterfall framework is based on “Defined Process Control”

Recommendations

One must understand that Scrum does not necessarily reduce cost and timelines. In Empirical process control, there will always be a feedback structure since the decisions are taken based on what you see. That means, we think about short-term in detail and long-term at a high level. When we see the results of short-term, we get feedback and then we inspect and adapt based on what we see. Therefore, there may be repetitions due to the feedback structure. Repetitions may mean that some re-work may happen. One must not think that just by doing Scrum, the cost and time will be lesser. If we use Scrum for problem statements which could have been solved using waterfall (or Defined process control), then unnecessary overheads and unnecessary inspect-adapt cycles may increase the cost and timelines. My recommendation is to choose the right framework for the right purposes. Taking a “one-size-fits-all” is not a great idea.

The teams are not necessarily happy doing Scrum. In the Scrum way of doing things, the timeframes are short. Delivery cycles shrink to a few week cycles. There is a constant pressure on teams. Many times, you will notice comments in the team like “Waterfall was better”. Scrum is actually Pervasive. That means people don’t like this drastic change in their lives. This change touches people’s lives. My recommendation is to ensure that every organization first implements a culture which sustains this pressure. The earlier model, where there was “push culture” should change first. Management should not create unnecessary pressure on the teams. Agile principle number 8 should be implemented first “Agile processes promote sustainable development. Sponsors, Developers and Users should be able to maintain a constant pace indefinitely”

The business teams are not necessarily happy doing Scrum. The Business teams were used to pushing accountability conveniently on the technical team’s side under the umbrella of a few terms like “Managed Services” or “Managed Outcomes”. The IT companies also marketed these terms like “Managed Services” to create differentiators for themselves. The Business teams suddenly start feeling the heat when they are held accountable for ensuring that the delivery happens properly and making sure that they have to work with the technical teams on a day-to-day basis. In Scrum, we define the accountability “Product Owner” where participation from a Business perspective is extremely important. My recommendation that the Business Teams must be made to understand that Accountability cannot be outsourced and one cannot toss the accountability on the technical side. The business should be brought in sync with the Agile principle “Business People and Developers must work together daily throughout the project”. Scrum emphasizes that the right people take the right accountability and accountability cannot be outsourced.

The Business teams have conveniently understood that “Changes are free in Agile and Scrum”.  One has to understand that no changes are ever free. There is always a cost associated with a change. It is just differently looked at in Scrum. In Scrum, we tend to give importance to more valuable features. That means, the less valuable features go down the product backlog and may never get implemented. So, pushing the teams to do all requirements may not be a great idea, else the cost will obviously go up. My recommendation is to follow the Agile principle number 10 which says “Simplicity – The art of maximizing the work NOT done is essential”. The business has to know that nothing in this world is free and we need to learn to compromise less-value features for the more valuable ones

Conclusion

Scrum is not a magic-wand solution to solving all problems. In fact, if you do things incorrectly then the problems will multiply. It is better for organizations to understand Scrum and Agile correctly and apply only where required. “One-size-fits-all” is not a great approach.

The post Myth that Scrum is a Magic Wand to Solve all Project Issues appeared first on World Of Agile.

Common Misconceptions

Most people consider Daily Scrum is presumed to be a Status Meeting where Scrum Master takes status from the teams. One of the most common reasons for this is because people have used Project Manager as an entity for years and assume that Scrum Master is a renaming of Project Manager role and Daily Scrum to be a new name for “Status Meeting”.

What is Daily Scrum Really?

• Daily Scrum is not a Status Meeting. Daily Scrum is a inspect-adapt forum for the Developers to make a plan for next 24-48 hours by checking if the Sprint Goal is being met or not
• Developers sync up daily so that the plan for next 24-48 hours is effectively done
• Updating the Sprint Backlog should be the main goal of the Daily Scrum. This optimizes the probability of meeting the Sprint Goal
• Daily Scrum is a effective forum for improving communication and collaborations between Developers

Recommendation about Scrum Master’s Role in Daily Scrum

• Scrum Master may facilitate the Daily Scrum to ensure it gets over in 15 minutes and people do not make it a detailed discussion forum. However, Scrum Master is not considered the compulsory participant of Daily Scrum.
• Scrum Master’s role is to make the team independent and help them becoming self-managed team. Therefore, Scrum Master should teach the Developers to run the Daily Scrum effectively by doing a quick sync up and updating the Sprint Backlog
• Once the team becomes self-managed and know how to get the Daily Scrum completed within 15 minutes, Scrum Master should change his/her stance to an observer stance. That means the team has to talk to each other without Scrum Master’s intervention
• Scrum Master should teach the Developers to keep the status transparent through various tools and techniques such as Burn Up Charts, Burn Down Charts, Scrum Boards. This avoids a lot of wasteful status discussions in the Daily Scrum
• Once the Scrum Master feels that the Developers are managing on their own, the Scrum Master should purposely skip a couple of Daily Scrum and find out if the Developers still keeps doing the Daily Scrum on their own. If the Developers also skip the Daily Scrum, just because the Scrum Master was not there, then Scrum Master should treat this as an opportunity to coach the team again
• If Scrum Master notices that Product Owner is conducting reviews of Product during the Daily Scrum, then, Scrum Master should coach the PO not to do it and create another forum where the review of the product could be done
• Similarly, if Scrum Master notices that the line managers are wasting the time of Developers by taking status, then Scrum Master must intervene and prevent the line managers from doing this
• Sometimes, one of the Developers wastes a lot of time of others during the Daily Scrum trying to dominate the forum by showing off on his/her skills. Scrum Master’s job to facilitate and ensure that everyone gets equal chance during Daily Scrum. There are many facilitation techniques which could be used. For example, tossing the ball every 60 seconds to the next person to speak, introducing friendly penalties (buying a drink for everyone, doing 10 push-ups) for exceeding the time allocated to speak etc.

Conclusion

Thus, Scrum Master is not a mandatory participant of Daily Scrum. “Not Mandatory” does not mean that Scrum Master is always Absent in Daily Scrum. Scrum Master’s role is to make the team independent so that they can manage the Daily Scrum to inspect and adapt and optimize the probability of meeting the Sprint Goal. Once the team becomes independent, it is better for the Scrum Master to take a step back and take observer position.

The post Myth – Scrum Master being the Mandatory participant of Daily Scrum appeared first on World Of Agile.

Common Misconceptions

Most people feel that every Sprint MUST make an Increment which HAS to be sent to production and given to the end-users for using. This is actually not true. Sometimes, it is not possible to produce Incremental “production-ready” outcome every Sprint

What really is the outcome of the Sprint?

Scrum defines the “OUTCOME” of the Sprint as an Increment which is “USABLE”. Usability is associated with getting feedback and not necessarily “Go-Live”

Recommendations

• Sometimes, in a short sprint it may not be possible to create an “Go-Live-Ready” product. However, every Sprint must result in a deliverable where feedback can be received. The feedback may happen from internal stakeholders and not necessarily the end-users
• Sprint should be considered separate from “Release”. While “Release” is not a Scrum term, most teams use the word “Release” to describe “Go-Live-Ready” outcome. Generally, it is observed that multiple Sprint outcomes can be combined together to create a “Release”. However, this is also not a necessary condition. Sometimes, teams may create multiple “Go-Lives” within the Sprint itself. It is important to understand that feedback is necessary every Sprint so that we know as a Scrum Team that we are going to achieve the Product Goal (Long term Goal). The intent of Sprint should be to optimize the probability of achieving the long-term objective and the feedback received should be used to optimize this probability. Now, the feedback may come from internal stakeholders or end-users. Important part is that feedback should come every Sprint.
• While this article says that it is not necessary to create a “Go-Live-Ready” outcome every Sprint, that does not mean that we create “Documentation” as output. We CANNOT be doing a “Requirements Sprint” which creates a “Requirement Document” as an output. We CANNOT be doing a “Coding Sprint” to create a “Code” as output. If we create outputs such as Documents then what we end up doing is “Outputs” (which are of no value) instead of “Outcomes”. “Outputs” do not necessarily result in “Outcomes” which are of business value or feedback-able value. “Outputs” do not necessarily result in feedback where we can check progress towards the Product Goal.

Conclusions

Sprint creates an Incremental outcome which is called Increment. The Increment should get the Scrum Team feedback, which will optimize the probability of meeting the Product Goal. The Incremental outcome may be a “Go-Live-Ready” outcome many times within a Sprint or sometimes over multiple Sprints. The Increment should never be an output which is not a valuable outcome.

The post Myth about every Sprint Output resulting in a go-live to production appeared first on World Of Agile.

Common Misconception

Most people treat Sprint Review as a “gate check” forum to release the product into production. Thus, the Sprint Review ends up being a formal meeting with gate-checking checklists to go through so that the product can be sent to production.

What really is a Sprint Review?

• Sprint Review is an informal forum to seek feedback from the Stakeholders
• Intention of the Sprint Review is for the Scrum Team to find out if they are on track to meet the Product Goal, and if not, inspect and adapt the Product Backlog for future Sprints
• Scrum de-links the “go-live” or “delivery to stakeholders” and “seeking feedback”. Sprint Review’s intent is to seek feedback. The product may be delivered to the stakeholders before or after the Sprint Review

Recommendations

• Sprint Review should be a informal discussion between Product Owner, Stakeholders and Developers to discuss improvements in the product and increase the probability of reaching the Product Goal
• Sprint Review should be more like a working session instead of formalized presentations and checklists to go through
• It is better to create a separate gate check forum other than the Sprint Review. If any gate checking is done in Sprint Review, the real intent of getting feedback may be lost

Conclusions

Sprint Review is not a gate checking forum. It is a working session where Scrum Team and Stakeholders collaborate on how better to achieve the Product Goal

The post Myth – Sprint Review Being a Gate to Releasing Value appeared first on World Of Agile.

Common Misconception

A Product Owner is considered a “Client” or “Customer”. So, most people feel, how can you invite a “Client” for an internal forum to discuss “what went well, what did not?”

Recommendations

• Most Product Owners indeed behave like a “Client” or a “Customer” instead of a Scrum Team Member. Therefore, the Developers do not consider the Product Owner a part of them and consider him/her as an outsider. The Product Owner should be first part of the Scrum Team and then be a “Customer” or “Client”
• Product Owners often ridicule the teams or shout at their teams for not understanding the requirements properly. Product Owners often escalate against the teams to the Line Managers of the Developers. This creates a divide between the Product Owner and the Developers. The Developers then don’t feel comfortable about opening up in front of the Product Owner. The Product Owner’s job should be to get the Developers to feel comfortable and put the “fear-factor” to rest. This means, the Product Owner should be empathetic, calm, show patience and be looked at as a Leader instead of a manager.
• Sprint Retrospective is a forum to see what went well and what did not go well. This increases the effectiveness of the next Sprint. If the Product Owner is not there in the Sprint Retrospective, then effectiveness improvement will be looked at only from the perspective of the Developers. The Developers are doing the technical work for the Product itself. So if the Product Owner is absent in a Sprint Retrospective, the effectiveness improvement cannot be done from the Product perspective
• Sprint Retrospective is a good forum to discuss the DoD (Quality Measure for next Sprint). If the Product Owner does not attend, the Sprint Planning of the next Sprint may be an issue since DoD is not finalized.

Conclusions

As a part of the Scrum Team, the Product Owner is a mandatory participant of the Sprint Retrospective. Sprint Retrospective is an excellent forum to thrash out any opinion differences and plan for improvements and everyone from the Scrum Team must participate.

The post Myth – Product Owner should not be invited in a Sprint Retrospective appeared first on World Of Agile.