Jira apps for agile teams

TL;DR

Anti-patterns in agile feel familiar, but often quietly undermine progress. In this guide, we explore five common collaboration traps: large user stories, forgotten retro actions, superficial estimation, premature "done" labels, and ceremonial agility. You'll learn how to recognise, understand, and experiment your way out of them.

The Comfort Trap: Why Familiar Agile Habits Hold Teams Back

In agile, anti-patterns don’t announce themselves. They slip in quietly, posing as good practice, often endorsed by experience or habit. Over time, they become the default - until velocity stalls, engagement dips, and retros feel like re-runs.

In our conversations with seasoned coaches and practitioners across finance, government, consumer tech, and consultancy, we realised one thing - anti-patterns aren’t just a team-level concern. They signal deeper structural misalignments in how organisations think about work, feedback, and change.

To protect the privacy of our interviewees, we’ve anonymised company names and individual identities.

Let’s unpack a few of the most pervasive anti-patterns hiding in plain sight, and how to shift them without disrupting momentum.

1. The Giant User Story Illusion

Large User Stories: Oversized tasks that delay feedback and blur team accountability.

"It felt faster to define everything up front. Until we got stuck." - Product Manager, global consumer organisation

Large user stories promise simplicity: one place, one discussion, a broad view stakeholders can get behind. But when delivery starts, the cracks widen:

• Estimations become guesswork.
• Feedback loops stretch.
• Individual contribution becomes unclear.

In many teams, the difficulty isn’t about size alone - it’s about uncertainty. Stories that span multiple behaviours or outcomes often hide assumptions, making them harder to discuss, estimate, or split.

Symptoms

• Stories span multiple sprints.
• Teams lose clarity on progress and ownership.
• Estimation sessions are vague or rushed.

Root Causes

• Pressure to satisfy stakeholder demands quickly.
• Overconfidence in early solution design.
• Lack of shared criteria for 'ready to build'.

Remedy

‍Break stories down by effort, known risks, or team confidence. One team created their own estimation matrix based on effort, complexity, and familiarity—grounding pointing in delivery, not abstraction.

See also: The Ultimate Guide to User Story Mapping

2. Retro Amnesia: Action Items with No Memory

Incomplete Retro Actions: Items raised in retrospectives that quietly disappear, losing learning and team trust.

"We come up with great ideas in retros, but they disappear." - Agility Lead, multinational financial institution

When teams can’t see which actions carried forward, improvement becomes accidental. One coach described manually collecting and prioritising past action items in a Notepad file - because nothing in their tooling surfaced incomplete actions by default.

Worse still, valuable decisions get revisited unnecessarily. Teams forget what they tried and why.

Symptoms

• Recurring issues in retros.
• Incomplete actions vanish from view.
• Team energy for change drops over time.

Root Causes

• Retros run out of time before reviewing past items.
• No tooling or habit for tracking open actions.
• Actions lack owners or timeframes.

Remedy

‍Surface incomplete actions in one place and track progress over time. Revisit context: what triggered the decision? What outcome did we expect?=

3. Estimation Theatre: When Story Points Become Currency

Story Point Anchoring: The habit of assigning consistent points to avoid conflict, not to clarify effort.

"The team got used to anchoring around threes. Everything became a three." - Agile Coach, public sector agency

Story points should guide shared understanding, and not become a measure of performance or predictability. But many teams fall into habits:

• Anchoring to previous estimates.
• Avoiding conflict by picking the middle.
• Gaming velocity for perceived consistency.

Symptoms

• Homogeneous story sizes regardless of work type.
• Few debates or questions during pointing sessions.
• Velocity becomes the focus, not team clarity.

Root Causes

• Misuse of velocity as a performance metric.
• Comfort with consistency over conflict.
• Absence of shared understanding of story complexity.

Remedy

‍Reframe estimation as shared learning. Encourage healthy debate, try effort/risk matrices, and use voting to explore perspective gaps.

4. The "Done Means Done" Shortcut

False Completion: Marking items “done” when no meaningful progress was made.

"We mark items as done, even if we didn’t act on them." - Scrum Master, insurance and data services firm

Marking something "done" in order to move forward can feel pragmatic. But it hides reality. Was the issue resolved? Deferred? Invalidated?

Without clear signals, teams lose the ability to reflect truthfully on what’s working. One team described starting every retro with a conversation about what "done" actually meant, and adjusted their practices based on whether action was taken or just abandoned.

Symptoms

• Completed items have no real impact.
• Teams disagree on whether actions were truly resolved.
• Follow-up problems recur with no reflection.

Root Causes

• Ambiguity in what "done" means.
• Lack of closure or accountability for actions.
• Reluctance to acknowledge when something was dropped.

Remedy

‍Introduce a "no longer relevant" tag for actions. Start every retro by reviewing outcomes of previous actions, even if abandoned.

5. Anti-Patterns in Disguise: Agile vs Agile-Like

Ceremonial Agility: Teams follow agile rituals but avoid meaningful feedback, adaptation, or empowerment.

"We're agile. But we also push work through to meet delivery at all costs." - Project Manager, large enterprise tech team

Many teams operate in agile-like environments: sprints, boards, and standups, but decision-making remains top-down, and trade-offs go unspoken.

This hybrid approach isn't inherently bad - context matters. But when teams inherit agile ceremonies without agile values, collaboration becomes box-ticking, not problem-solving.

Symptoms

• Teams follow agile ceremonies but avoid real collaboration.
• Delivery decisions made outside of sprint reviews.
• Retrospectives focus only on team morale, not system change.

Root Causes

• Agile adoption driven by compliance, not culture.
• Delivery commitments override learning and adaptation.
• Leadership sees agile as a process, not a mindset.

Remedy

Is your agile framework enabling change - or disguising command-and-control? Use retros and sprint reviews to discuss system constraints. Ask what’s driving the way work flows, and who has the power to adjust it. Make trade-offs visible and shared.

Spot the Signs, Shape the Shift

Anti-patterns don’t mean your team is failing. They mean your team is learning. The most resilient teams are the ones that catch unhelpful habits early, and have the safety and support to try something else.

Retrospectives are the perfect place to surface them - as long as they’re structured for memory, not just reflection.

In the end, anti-patterns aren’t the enemy. Silence is.

Want to take action?

Try this in your next retro:

• Surface 1 anti-pattern the team has noticed (e.g. big stories, unfinished actions, silent standups).
• Ask: Why might this have emerged? What need did it originally serve?
• Run a one-sprint experiment to shift it. Keep it small.

The cost of anti-patterns isn’t just inefficiency. It’s losing the opportunity to get better, together.

Retrospectives were meant to be agile’s secret weapon.

In theory, they’re a dedicated space for teams to pause, reflect, and course-correct. A recurring moment of clarity in the blur of sprints. But in practice?

“We show up, we talk about the same problems, we say we’ll fix them... and then we don’t.”
- Jaclyn Smith, Senior Product Manager, Easy Agile

This isn’t just dysfunction. It’s disillusionment. And it’s costing agile teams more than they realise.

In this post, we dive into the hard truths explored by Jaclyn Smith, Senior Product Manager at Easy Agile, and Shane Raubenheimer, Agile Technical Consultant at Adaptavist in:

• 🎙️ Easy Agile Podcast Ep. 32: Why Retrospectives Fail & How to Fix Them
• 🎥 Webinar: Retro Action – Stop Talking, Start Doing
• 📝 The Action-Driven Retrospective Template

Our goal is not just to fix retrospectives, but to reclaim them. If that resonates with you, keep reading.

TL;DR:

• Retrospectives often fail because teams repeat surface-level issues without resolving root causes.
• Action items from retros are rarely followed up, leading to distrust and disengagement.
• The Action-Driven Retrospective Template helps teams focus on fewer, more impactful changes.
• Trust is rebuilt through consistency, accountability, and small wins that compound.
• Real improvement happens not during the retro, but in what the team does afterward.

When we stop believing that change is possible

The quiet failure of retrospectives doesn’t happen in a moment. It happens gradually, invisibly, over the course of sprints where insights are voiced but not acted on. When teams invest time in talking about problems, only to see them persist, they don’t just lose momentum. They lose hope.

In the podcast, Jaclyn Smith, Senior PM at Easy Agile, reflected on retros where participation seemed high, yet nothing stuck:

“We’d have these beautiful, well-facilitated boards. But when we checked in a sprint later, people couldn’t remember what the actions were. Or worse, they remembered, and knew nothing had happened.”

That erosion of trust isn’t always visible. But it’s felt. It manifests as disengagement, short answers, vague observations. When a team feels like retros won’t lead anywhere, they stop offering anything worth leading with.

This is the paradox of failed retros: the form persists, even as its function evaporates. The team is technically “doing the retro.” But the retro no longer does anything for the team.

Normalising dysfunction and agile anti-patterns

In the webinar, Shane and Jaclyn dissect this disillusionment based on their experience of working with hundreds of real teams across industries. Most teams can relate to this problem - they're doing everything “right”: regular standups, retrospectives on the calendar, a backlog that moves. And yet, they somehow feel stuck in the same spot.

That's because of one or more of these anti-patterns, which have become dangerously common:

• Cargo cult agile: Following agile rituals without purpose
• Hero culture: Over-reliance on a few individuals rather than teamwork
• Water-Scrum-Fall: Mixing methodologies without clear boundaries
• Team velocity misuse: Tracking productivity by team velocity alone
• Backlog noise: Long lists of tasks lacking customer value

The issue isn’t awareness. Teams know these patterns exist. What’s missing is a structure that interrupts them - consistently, visibly, and meaningfully.

“The worst retros aren’t chaotic. They’re quiet. No conflict. No depth. Just a board full of things we’ve already said.”
- Shane Raubenheimer, Agile Technical Consultant, Adaptavist

This is why retros don’t just need better facilitation. They need a redesigned relationship with action.

Building action into the ritual

The most fundamental problem Jaclyn and Shane identify is that retros end with “next steps”, but those steps never reappear. Actions get lost in Jira, or exist solely in a facilitator’s notes. They’re rarely revisited. They aren’t owned. And without ownership, there’s no accountability.

That’s why they created the Action-Driven Retrospective Template. It’s not flashy. But it forces a shift in rhythm:

• Every retro begins with last sprint’s actions. Were they completed? What impact did they have?
• Themes are not just grouped - they’re challenged. Why do they keep showing up? What’s beneath them?
• One or two actions are selected - no more. And they are immediately assigned, tracked, and made visible.

“This is about restoring integrity to the retro. If we’re not checking what we did last time, what does it say about what we’ll do this time?”
- Jaclyn Smith

The brilliance here is in the restraint. Rather than generate more insight, the template helps teams create follow-through - the most precious and elusive outcome of any retrospective.

Why teams need fewer actions and more outcomes

In agile culture, it’s easy to mistake motion for progress. A retro that generates 15 sticky notes and 5 action items might feel productive. But it often leads to diffusion of focus and quiet inaction.

Shane is blunt about this:

“I’d rather a team act on one thing really well, than half-act on five.”

The Action-Driven approach discourages long lists. It nudges teams to choose actions that are both impactful and doable within a sprint. It acknowledges capacity. It invites discernment. And in doing so, it cultivates trust.

Because when teams start seeing change happen, even in small ways, they begin to believe again. And belief, more than any tool or process, is what fuels sustainable agility.

Retrospectives as emotional reset, not just process audit

Perhaps the most refreshing part of the conversation was how emotionally honest it was. Neither Shane nor Jaclyn treated retrospectives as an abstract exercise. For them, it’s about what people feel when they leave the room.

“A retro should give people energy. It should help them see that we’re improving, that their voice matters, that something got better because of something they said.”
- Jaclyn Smith

This is what most guides miss. Retros aren’t just functional. They’re relational. They tell a story about whether the team can learn, grow, and improve together. When that story breaks, when people stop feeling heard, or stop seeing results, the damage goes beyond a missed task.

It touches morale. Culture. Confidence.

Tooling and rituals are not the answers, but the amplifiers

In the webinar, Jaclyn goes on to show how Easy Agile TeamRhythm can help teams carry retro actions directly into Jira workflows. It’s not about selling a tool, but rather about shortening the distance between reflection and execution.

Jaclyn’s point is clear:

“The retro isn’t where change happens. It’s where it begins. The real test is whether your sprint backlog tells the same story.”

This is where tooling earns its place - not by replacing conversations, but by preserving context and sustaining visibility. When actions from a retro are visible in the planning session, on the board, and during standup, they don’t disappear. They become culture.

Start with mindset shift. Then build the habit.

What makes this approach so effective is its humility. It doesn’t promise transformation. It promises traction.

Start with one action. Make it visible. Talk about it next time. Build a habit. Trust the compounding effect of small, completed improvements.

“Agile isn’t about doing more. It’s about doing what matters - better, and more often.”
- Shane Raubenheimer

If your retrospectives feel tired, you don’t need a new format. You need a new relationship to action.

And that begins not with a workshop, but with a single, honest question:

“What did we change last sprint, and did it make anything better?”

If you don’t know the answer, start here:

📝 Download the Action-Driven Retrospective Template
🎧 Listen to the full podcast
🎥 Watch the full webinar

You don’t need to fix everything this sprint.

You just need to prove, to your team, and to yourself, that change is possible again.

High-performing teams don't happen by accident. They're built through intentional conversations about how to work together effectively.

Creating alignment isn't about one-off workshops. It's about clarity that sticks. A team charter gives agile teams the shared understanding they need to work better together, especially as teams grow, change, and evolve how they work. Without one, ambiguity creeps in, especially in remote or distributed environments where body language and hallway conversations aren't an option.

TL;DR

• A team charter is a shared agreement that defines how a team works together.
• It helps build trust, align expectations, and reduce friction.
• Creating one involves four stages: define purpose, agree on behaviours, map workflows, and embed the document.
• It evolves with the team and supports onboarding, retros, and continuous improvement.

What is a Team Charter?

A team charter is a living document co-created by the team. It outlines the team's shared understanding around purpose, values, responsibilities, and ways of working. It sets the tone for how people communicate, collaborate, and make decisions.

Think of it as a blueprint for a high-performing team: aspirational, but grounded in the daily realities of team life, and aligned with agile ceremonies like stand-ups, sprint reviews, and retrospectives that reinforce shared understanding. It reduces duplication, limits confusion, and gives structure to how we operate - even when the unexpected shows up.

Benefits of a Team Charter for Agile Teams

At its core, a team charter addresses the fundamental questions that cause most team dysfunction:

• What is our purpose as a team? Why do we exist?
• What is within the scope of our team?
• What outcomes are we accountable for?
• How do we treat each other as team members?
• How do we make decisions and communicate?
• What are our individual roles and responsibilities?
• How do we celebrate success?

What a Well-Crafted Team Charter Can Unlock

1. Clarity and Alignment

A team charter serves as a clear roadmap that defines the team's mission, goals, roles, and responsibilities. It ensures everyone understands how their work contributes to team success.

2. Better Decision-Making

When responsibilities and communication protocols are clear, decisions are made faster and more consistently.

3. Improved Communication

Establishing communication norms upfront ensures smoother knowledge sharing and transparency.

4. Accountability and Ownership

Team members know what they're responsible for, fostering commitment and initiative.

5. Trust and Team Cohesion

The collaborative process of creating a charter builds trust and empathy, and strengthens team dynamics.

6. Continuous Improvement

Team charters encourage feedback and reflection, evolving with your team over time.

7. Streamlined Onboarding

Team charter serves as a vital guide for new team members, offering clear insight into the team's norms, values, and workflows, accelerating their integration and boosting early productivity.

8. Living Reference Document

The charter acts as a reference tool that keeps everyone grounded and aligned as the team changes.

Four Practical Steps to Build a Team Charter

The team charter process is typically split into four interactive sessions. Each phase builds on the last and creates the trust, clarity, and psychological safety needed for the next.

Phase 1: Define Purpose and People

The team's mission refers to the objective or goal that a team is set to achieve. It is a clear and concise statement that defines the team's purpose and the value it aims to deliver.

Start by co-creating the team's mission statement. Team members contribute by answering: "What value do we deliver? What impact do we want to have?"

Everyone shares their input, then the team votes on the mission statements that resonate most. You can even combine parts from several to create the final version.

Once established, the mission should be displayed publicly where everyone can see it and team members can reference it.

Then we go deeper, with Personal Operating Instructions (POIs). This phase focuses on understanding team members as individuals. Each person answers questions like:

• What do you love about your job?
• What motivates you?
• How do you like to work?
• When do you work best?
• What do you want help to look like?

This helps us build empathy and challenge assumptions. It makes team members understand behaviours and uncover ways to support one another.

Phase 2: Create a Working Agreement

A working agreement is a team-designed agreement for an aspirational set of values, behaviours and social norms. Think of it as a vision for how it would be to work in an incredibly safe and powerful team.

This is where the real power lies, where you get specific about operations. Through a mix of guided reflection and group synthesis, the team explores questions like:

• What makes a great team vs. a terrible team?
• How do we communicate?
• How do we make decisions?
• What are our top responsibilities?
• What are our daily rhythms (e.g., stand-ups, reviews)?

And don’t stop at logistics, go deeper:

• How do we give feedback?
• What do we do when someone’s stuck?
• How do we balance collaboration and deep work?
• How do we share knowledge?
• How do we run meetings?
• How do we support remote or hybrid work?
• How do we protect focus time?
• How do we resolve disagreements?

From this, draft short, memorable working agreement statements. For example: "We default to asynchronous communication whenever possible," or "We commit to reviewing pull requests within 24 hours." Themes like "Diverse opinions welcome" or "Refactoring is a first-class citizen" should emerge.

💡 Tip: If your team uses Easy Agile TeamRhythm, you can incorporate these agreements into planning and retro directly.

Here are two examples of working agreements:

Phase 3: Map an Operational Agreement

Next, turn principles into rituals. Visualise your delivery flow using tools like Kanban boards, swimlanes, or service blueprints, whatever format helps your team see the full picture clearly:

• Who leads each stage?
• What’s working?
• What’s broken?
• What needs to be true for work to move forward?

Capture frictions around unclear ownership or ambiguous definitions. This surfaces hidden blockers and leads to better alignment.

💡 Tip: Consider using a collaborative tool like Miro, Easy Agile Programs, or whiteboarding sessions to map your current process together.

Phase 4: Make It Stick

A charter only works if it lives in your team’s daily rhythm. Otherwise, it risks becoming 'shelfware' that gets created once and forgotten. Keep it active, visible, and revisited to maintain its impact.

• Share and communicate: Make it accessible and visible.
• Live by the charter: Role model the behaviours you agreed on.
• Review and update regularly: Revisit and evolve it as your team changes.
• Use as a reference: Ground retrospectives and decisions in it.
• Reflect often: Use it to discuss what’s working and what’s not.

💡 Tip: Add your charter as a living page in your team workspace (like Confluence) and link to it in your planning tools.

Onboarding New Team Members with a Charter

When someone new joins the team, it's time to review the charter. Here’s a step-by-step onboarding process:

1. Initial walkthrough: A team lead introduces the charter and context.
2. Time to absorb: The new member reads and reflects.
3. Team review: The team invites their feedback and updates the charter together.

This creates buy-in and strengthens psychological safety.

💡 Tip: Schedule a 30-minute team check-in with each new hire after their first two weeks to revisit the charter together.

The Foundation of High Performance

A team charter isn’t just a document. It’s a shared commitment to how you work together. It evolves as your team does, helping you navigate change and stay aligned.

If there’s one thing we’ve learned, it’s that culture isn’t declared. It’s designed, together.

Whether forming a new team or elevating an existing one, your charter is a powerful first step toward intentional, aligned collaboration.

Suggested Next Step

Looking to embed your team charter into your team's everyday rhythm? Easy Agile apps like TeamRhythm and Programs help teams turn working agreements into action by aligning daily rituals such as sprint planning, stand-ups, retrospectives, and PI planning.