WWW Retrospective: Worked Well, Kinda Worked, Didn't Work

The WWW retrospective (Worked Well, Kinda Worked, Didn’t Work) introduces a nuanced middle ground that many retrospective formats lack. Instead of forcing items into binary “good” or “bad” categories, this format acknowledges that many things partially work—creating opportunities for refinement rather than wholesale change.

If your team finds themselves debating whether something belongs in the positive or negative column, the WWW format provides the nuance you need.

What Is the WWW Retrospective?

The WWW retrospective uses three categories with clear gradations:

Category	Symbol	What It Captures
Worked Well ✅	Green	Things to keep doing
Kinda Worked 🟡	Yellow	Things that need adjustment
Didn’t Work ❌	Red	Things to stop or fix

The “Kinda Worked” category is what makes this format special—it captures practices that showed promise but need refinement.

Why the WWW Format Works

The Power of the Middle Ground

Most retrospective formats force binary choices:

Good vs. bad
Keep vs. stop
Positive vs. negative

Reality is more nuanced. The WWW format acknowledges:

Partial successes that could become full successes
Good intentions with imperfect execution
New practices still finding their footing
Context-dependent things that work sometimes

Encourages Experimentation

The “Kinda Worked” category:

Reduces fear of trying new things
Creates space for iteration
Acknowledges learning curves
Prevents premature abandonment of good ideas

Simple Yet Effective

The WWW format is:

Easy to understand and explain
Quick to set up
Intuitive for team members
Suitable for any experience level

The WWW Categories Explained

Worked Well ✅ — Keep Doing

The Worked Well category captures things that should continue unchanged.

What belongs here:

Effective practices to maintain
Successful experiments to adopt
Team wins to celebrate
Processes that delivered value

Examples:

“Daily standups at 9:30 AM—everyone attends and they’re focused”
“Pair programming on complex features”
“Sprint planning with story mapping”
“Clear Definition of Done prevented scope creep”
“New deployment checklist caught issues”

The standard: Items here should be things you’d confidently recommend to another team.

Prompts:

What should we definitely keep doing?
What worked exactly as intended?
What made you feel productive this sprint?

Kinda Worked 🟡 — Needs Adjustment

The Kinda Worked category captures things with potential that need refinement.

What belongs here:

Practices that worked in some situations but not others
New things with promise but rough edges
Good ideas with imperfect implementation
Processes that achieved partial results

Examples:

“Code review process—good for quality but taking too long”
“Slack channel for async standups—worked for remote folks but local team forgot to post”
“Two-week sprints—better than one week but still feel rushed at the end”
“New testing framework—powerful but learning curve is steep”
“Daily demos—valuable but attendance is inconsistent”

The standard: Items here show promise but aren’t ready for “Worked Well” status yet.

Prompts:

What almost worked?
What had good intentions but poor execution?
What shows promise but needs tuning?
What worked sometimes but not always?

Didn’t Work ❌ — Stop or Fix

The Didn’t Work category captures things that failed or caused problems.

What belongs here:

Practices to stop
Experiments that failed
Processes causing friction
Things making work harder

Examples:

“Afternoon standups—conflicted with focus time”
“Feature branch that lived too long—merge was painful”
“Skipping code reviews when rushed—caused production bugs”
“Estimation in hours—took forever and wasn’t accurate anyway”
“Group email threads for decisions—important info got lost”

The standard: Items here should clearly be stopped or significantly changed.

Prompts:

What should we stop doing immediately?
What made work harder than necessary?
What experiment clearly failed?
What caused frustration this sprint?

When to Use the WWW Retrospective

Situation	Why WWW Works
Teams experimenting with new practices	”Kinda Worked” captures learning phase
Nuanced discussions needed	Three categories allow more precision
Teams fatigued by black/white retros	Middle ground feels more realistic
Process improvement focus	Clear action implications per category
Mixed experience teams	Simple enough for all levels
Regular sprint retrospectives	Works well for routine use

When to Choose Other Formats

Need specific actions: Use DAKI or Starfish
Emotional processing: Use Mad Sad Glad
Future-focused: Use Futurespective
Visual learners: Use Sailboat or Hot Air Balloon

How to Run a WWW Retrospective

Before the Meeting

Preparation:

Schedule 30-45 minutes
Prepare board with three columns
Use traffic light colors (green/yellow/red)
Review previous retrospective action items
Consider what experiments were tried this sprint

Step-by-Step Facilitation

Step 1: Set the Stage (3 minutes)

Introduce the format:

“Today we’re using the WWW format. We’ll sort our experiences into three categories:

✅ Worked Well — Things to keep doing as-is

🟡 Kinda Worked — Things that show promise but need adjustment

❌ Didn’t Work — Things to stop or significantly change

The ‘Kinda Worked’ category is for things that aren’t quite ready for either extreme.”

Clarify the middle category: “If you’re debating where something goes, ‘Kinda Worked’ is probably right.”

Step 2: Silent Brainstorming (7 minutes)

Have team members add items to each column:

One idea per sticky note
Place in appropriate column
It’s okay to have more items in one column than others

Facilitator tip: Remind team that “Kinda Worked” items are valuable—they represent opportunities for improvement.

💡 RetroFlow makes retrospective setup easy—free, no signup required.

Go through each column:

Recommended order:

Worked Well — Start positive, celebrate wins
Kinda Worked — Most discussion happens here
Didn’t Work — Address problems

For “Worked Well” items:

Brief acknowledgment
Note if we should share with other teams
Confirm it should continue

For “Kinda Worked” items:

Author explains what worked and what didn’t
Group discusses: “What would make this fully work?”
Identify specific adjustments needed

For “Didn’t Work” items:

Author explains the issue
Group discusses: “Stop entirely or try differently?”
Avoid blame, focus on learning

Step 4: Prioritize (5 minutes)

Use dot voting focusing on:

“Kinda Worked” items with highest improvement potential
“Didn’t Work” items causing the most pain

Step 5: Create Action Items (5-10 minutes)

Different actions for each category:

Category	Item	Action
Worked Well	Daily standups at 9:30	Document in team charter
Kinda Worked	Code reviews taking too long	Implement 24-hour SLA, use smaller PRs
Didn’t Work	Afternoon standups	Move back to morning; try 9:15

Action framework:

Worked Well: How do we maintain or share this?
Kinda Worked: What specific adjustment do we try?
Didn’t Work: Stop entirely or propose alternative?

Step 6: Close (2 minutes)

Summarize action items
Thank the team
Note any items to revisit next sprint

WWW Retrospective Template

┌──────────────────────────────────────────────────────────────────────┐
│                       WWW RETROSPECTIVE                               │
├────────────────────┬────────────────────┬────────────────────────────┤
│   ✅ WORKED WELL   │   🟡 KINDA WORKED  │      ❌ DIDN'T WORK        │
│                    │                    │                            │
│   Keep doing       │   Needs adjustment │      Stop or fix           │
│                    │                    │                            │
│                    │                    │                            │
│                    │                    │                            │
│                    │                    │                            │
│                    │                    │                            │
│                    │                    │                            │
│                    │                    │                            │
│                    │                    │                            │
└────────────────────┴────────────────────┴────────────────────────────┘

Traffic Light Visual

For a more visual approach:

    ┌─────────┐
    │  ✅     │  WORKED WELL
    │  GREEN  │  → Keep as-is
    └─────────┘
         │
    ┌─────────┐
    │  🟡     │  KINDA WORKED
    │ YELLOW  │  → Adjust & try again
    └─────────┘
         │
    ┌─────────┐
    │  ❌     │  DIDN'T WORK
    │   RED   │  → Stop or change
    └─────────┘

Sample Items for Each Category

Worked Well Examples

Sprint planning sessions are well-facilitated
Daily async standups in Slack
Automated testing catching regressions
Sprint backlog was right-sized
Product owner available for questions

Kinda Worked Examples

Pair programming—valuable but hard to schedule
New branching strategy—cleaner but learning curve
Weekly team demos—good content but low attendance
Estimation poker—fun but still inaccurate
Documentation in Notion—organized but not updated

Didn’t Work Examples

Multitasking on three features at once
Long-lived feature branches
Skipping retrospective action item follow-up
Evening deployments
Synchronous meetings for status updates

For discussion prompts that pair well with this format, see our retrospective questions guide.

Tips for Facilitating WWW

Embrace the Middle Ground

The “Kinda Worked” category is the heart of this format:

Don’t rush through it—most actionable items live here
Ask “What would make this fully work?”
Use it to rescue good ideas with poor execution
Recognize that new practices often start here

Use Color Coding

Traffic light colors make the format intuitive:

Green sticky notes for Worked Well
Yellow sticky notes for Kinda Worked
Red sticky notes for Didn’t Work

Watch for Overcrowded Columns

If “Worked Well” is empty:

Team might be too self-critical
Prompt: “What got us through this sprint?”

If “Kinda Worked” is empty:

Team might be thinking too binary
Prompt: “What almost worked?”

If “Didn’t Work” is empty:

Team might be avoiding hard topics
Check psychological safety

Connect to Experiments

Reference previous retrospective actions:

“We tried X last sprint—where does it land?”
Items in “Kinda Worked” become next sprint’s experiments
Track progression from Didn’t Work → Kinda Worked → Worked Well

Variations on WWW

WWW + Actions

Add a fourth column for immediate actions:

Worked Well	Kinda Worked	Didn’t Work	Actions
Items	Items	Items	Commitments

Percentage WWW

Add percentage indicators:

“90% Worked Well” (almost perfect)
“50% Kinda Worked” (real mixed results)
“20% Kinda Worked” (barely worked)

WWW with Root Causes

For “Didn’t Work” items, add “Why?” exploration:

What didn’t work?
Why didn’t it work?
What should we try instead?

Common Mistakes to Avoid

Mistake 1: Ignoring “Kinda Worked”

Problem: Rushing through the middle category Fix: Spend the most time here—these are your improvement opportunities

Mistake 2: Binary Thinking

Problem: Everything lands in Worked Well or Didn’t Work Fix: Actively prompt for “What almost worked?”

Mistake 3: No Specific Adjustments

Problem: “Kinda Worked” items stay vague Fix: For each, define exactly what adjustment to try

Mistake 4: Celebrating Too Soon

Problem: Moving items to “Worked Well” after one success Fix: Require consistent success before graduating items

If your team likes WWW, also try:

Start Stop Continue — Similar simplicity, binary categories
DAKI — Drop, Add, Keep, Improve for action focus
Plus Delta — Two categories with change focus
4Ls — Liked, Learned, Lacked, Longed For

See all options in our sprint retrospective formats guide.

Try This Format in RetroFlow

RetroFlow has a built-in WWW template. Here’s why teams pick it:

✅ Anonymous input for honest feedback
✅ Built-in voting to prioritize what matters
✅ Completely free — no signup required

Start Free Retrospective →

Summary

The WWW retrospective uses three categories:

✅ Worked Well — Keep doing
🟡 Kinda Worked — Needs adjustment
❌ Didn’t Work — Stop or fix

The “Kinda Worked” category is what makes this format special—it captures practices showing promise that need refinement. This nuanced approach helps teams iterate on good ideas rather than abandoning them prematurely.

Run it in 30-45 minutes with focus on the middle category where most improvement opportunities live.

Sprint Retrospective Formats Guide - 30+ formats
Start Stop Continue Retrospective - Similar simplicity
DAKI Retrospective - Action-focused alternative
How to Facilitate a Retrospective - Facilitation tips

Retrospective Formats Templates Retrospectives