Weekly Retrospective

Purpose

Conduct a structured weekly team reflection during the A3.3 pilot to surface what is working, what is not, and what should change—enabling rapid iteration on both the product and the pilot operation itself. Weekly retrospectives convert 8~weeks of pilot operation from a passive observation period into an active learning cycle where each week's insights improve the next week's execution.

In A3.3, the retrospective serves three functions:

• Product learning: What are users telling us through behaviour and feedback? What should we iterate?
• Operational learning: What support patterns are emerging? What infrastructure issues need attention?
• Team learning: What is our process missing? What tools or practices should we adopt or abandon?

When to Use

Use weekly retrospectives when:

• A3.3 pilot is running (≥4 weeks)—weekly cadence provides enough data per cycle while maintaining momentum
• Multiple team members are involved (Project Manager, customer success, engineering, UX)—alignment requires structured sync
• The pilot is iterative (changes being made during pilot)—retrospective decides what to change
• A3.4 evaluation will need operational learnings —retrospective minutes are primary evidence

Do NOT use when:

• Pilot team is 1–2 people—informal daily check-ins suffice
• Pilot is observation-only (frozen prototype, no iteration permitted)—retrospective has nothing to act on
• Retrospective becomes performative (same complaints weekly, no action items completed)—fix the format or pause

Sample Size and Duration

Team size: 3–8 participants (PM, customer success, engineering, UX researcher)

Session length: 45–60 minutes (strictly timeboxed)

Frequency: Weekly throughout A3.3 pilot (4–8 sessions total)

Total effort: 3–8 person-hours per session (team size × 1 hour)

Prerequisites

• Fixed timeslot: Same day and time weekly (e.g. Friday 2pm); non-negotiable calendar block
• Data available: Week's metrics ready (usage, retention, support tickets, NPS if surveyed) before the meeting
• Facilitator: Rotating or fixed; not the Project Manager for the first few sessions (PM authority inhibits honesty)
• Previous action items: Last week's actions visible for accountability review
• Psychological safety: Team norm established: problems are data, not blame
• Time: 45–60 minutes maximum (longer retrospectives lose energy)

Complete Procedure

Phase~1: Set the Stage (5 minutes)

Facilitator opens: “How are we feeling about the pilot this week?” Quick round-robin (one word or sentence per person). Purpose: gauge energy, surface mood, create space for honesty. If someone says “frustrated”—that is the most important data point of the meeting.

Review last week's action items: completed, in progress, or dropped? Accountability without blame.

Phase~2: Gather Data (15 minutes)

Two data streams:

Quantitative (5 minutes): Project Manager shares week's metrics dashboard:

• New users onboarded this week
• Weekly active users (WAU) and trend
• Support tickets (volume, top categories)
• NPS if surveyed this week
• System performance (uptime, errors)
• Retention cohort update

Qualitative (10 minutes): Team shares observations using a structured format. The classic approach:

Each team member adds 1–3 items per column (sticky notes, Miro board, or shared document). Timebox to prevent over-discussion at this stage.

Alternative formats (rotate to prevent staleness):

• 4Ls: Liked, Learned, Lacked, Longed For
• Start/Stop/Continue: What to start doing, stop doing, keep doing
• Sailboat: Wind (helps), anchor (holds back), rocks (risks), island (goal)
• Mad/Sad/Glad: Emotional response to week's events

Phase~3: Generate Insights (15 minutes)

Cluster related items. Identify patterns:

• Recurring themes: Same issue 3+ weeks systemic problem, not one-off
• Contradictions: Metrics say retention is fine, but customer success reports growing frustration—which is leading indicator?
• Surprises: Unexpected usage pattern, feature request cluster, user segment behaviour

Discuss top 2–3 themes. For each: What is the root cause? Is this a product issue, process issue, or resource issue? What would we need to change?

Phase~4: Decide What to Do (10 minutes)

Convert insights into action items. Each action item must have:

• Owner: One person responsible (not “the team”)
• Deadline: By when (typically “by next retrospective”)
• Definition of done: How we know it is complete

Maximum 3 action items per week. More than 3 means nothing gets done. Prioritise ruthlessly: what has the highest impact on pilot success this week?

Phase~5: Close (5 minutes)

Quick round: “One thing you're taking away from today?” Confirm action items. Thank the team. End on time.

Quality Criteria

1. Weekly cadence maintained: No skipped weeks during pilot (retro is non-negotiable)
2. Data-informed: Metrics reviewed before qualitative discussion
3. Action items produced: ≤3 specific, owned, deadlined items per session
4. Action items completed: ≥70% completion rate week over week
5. Minutes recorded: Themes, insights, and actions documented (A3.4 evidence)
6. Safe environment: “What Didn't Go Well” consistently populated

Theoretical Foundation

Seminal references:

• : The definitive guide to agile retrospectives. Established the 5-phase structure (Set the Stage, Gather Data, Generate Insights, Decide What to Do, Close) that prevents retrospectives from degenerating into complaint sessions. Key principle: retrospectives produce action items, not just observations.
• : Positioned team learning as one of five disciplines of a learning organisation. Retrospectives operationalise team learning: structured reflection shared mental models coordinated action. Without retrospectives, teams repeat mistakes weekly.

Contemporary references:

• : Demonstrated that psychological safety is the prerequisite for effective retrospectives. Team members must feel safe reporting problems without blame. A3.3 retrospectives fail if the Project Manager punishes bad news—the team stops sharing it, and pilot problems go underground.

A3.3-Specific Retrospective Topics

Beyond generic agile retrospective content, A3.3 retrospectives should explicitly address:

• Pilot health: Are we on track for A3.4 success criteria? What is the biggest risk to hitting targets?
• Iteration decisions: Should we change the prototype this week? What is the cost/benefit of the change? Will it confound cohort analysis (the referenced method)?
• Support sustainability: Is current support level scalable? What would break at 10× users?
• User signals: What are users telling us (through behaviour, not just words) about product-market fit?
• Early termination: Should we stop the pilot early? (Only if catastrophic failure—A3.3 needs ≥4 weeks for valid data)

Challenges and Solutions

Challenge 1: Retrospective Fatigue

Symptoms: By Week~4, team says “same issues, nothing changes.” Attendance drops.

Solutions: Rotate format every 2–3 weeks (see alternative formats above). Review action item completion rate—if <50%, the problem is execution, not the retrospective. Bring user quotes or session clips to inject fresh perspective.

Challenge 2: No Psychological Safety

Symptoms: Only “What Went Well” column has items. “What Didn't Go Well” is empty. Team is performing positivity, not reflecting honestly.

Solutions: Have someone other than the PM facilitate. Use anonymous input (digital sticky notes submitted before discussion). PM models vulnerability: “Here's something I got wrong this week…”

Challenge 3: Retrospective Without Data

Symptoms: Team discusses feelings and impressions without reference to metrics. Decisions based on loudest voice, not evidence.

Solutions: Phase~2 starts with quantitative dashboard—always. Numbers first, then feelings. When someone says “I think users are struggling,” respond with “Let's check the data—what does activation rate show this week?”

Relationship to Other Methods

Weekly Retrospective receives input from:

• Cohort Analysis (the referenced method): Retention data reviewed in Phase~2
• Customer Success Management (the referenced method): Support patterns are primary qualitative input
• NPS (the referenced method NPS survey results discussed when available
• Error Monitoring: Technical issues reviewed weekly