Running Standups & Retrospectives

The Daily Standup Is Not a Status Report

The daily standup (or daily scrum) is a short, time-boxed meeting — usually 10 to 15 minutes — where the team synchronizes on progress and surfaces blockers. It is easy for standups to degrade into a boring status report read aloud to a PM. A good standup instead helps the team coordinate with each other; the PM is there to listen, not to interrogate.

The classic three-question format is a useful starting point:

1. What did I do yesterday?
2. What will I do today?
3. Is anything blocking me?

A team at Paystack shipping a new reconciliation feature might use standup to notice that the frontend engineer is blocked waiting on an API contract from the backend engineer — a five-second fix if caught during standup, versus a full day lost if it surfaces only at sprint review.

---

Facilitating a Good Standup

• Keep it short. If a discussion needs more than two minutes, say "let's take this offline" and move on — do not solve problems live in front of the whole team.
• Focus on blockers, not busywork. The most valuable sentence in any standup is "I'm blocked on X."
• Rotate who leads it. This keeps the meeting from feeling like it belongs to the PM or Scrum Master alone.
• Watch for silent blockers. Someone who says "no blockers" three days running while their ticket hasn't moved is worth a private check-in.

---

Identifying and Removing Blockers

A blocker is anything stopping a piece of work from moving forward — a missing design, an unclear requirement, a broken staging environment, or a dependency on another team. Part of the PM's (or Scrum Master's) job is triaging blockers quickly:

At a company like Konga, a checkout feature blocked on a third-party logistics API might need the PM to escalate directly to the partner's account manager — work that happens outside the standup but is triggered by it.

---

The Sprint Retrospective

The retrospective ("retro") happens at the end of each sprint and asks: how did we work together, and what should change? Unlike the sprint review (which looks at what was built), the retro looks at how the team builds.

Common Retro Formats

• Start / Stop / Continue — what should we start doing, stop doing, and keep doing?
• Mad / Sad / Glad — surface emotional reactions to the sprint, which often reveal real process issues.
• 4 Ls (Liked, Learned, Lacked, Longed for) — a slightly more structured variant popular with distributed teams.
• Sailboat — the boat (goal), wind (what's helping), anchors (what's holding you back), and rocks (risks ahead).

A Scrum Master at a company like Access Bank, running a retro after a difficult release, might use Mad/Sad/Glad specifically because it gives engineers permission to name frustration ("mad that QA found this bug three days before launch") without it feeling like a personal attack.

---

Making Retro Actions Stick

The single biggest failure mode of retrospectives is generating a list of good ideas that nobody follows up on. To fix this:

• Limit each retro to one or two concrete action items, not ten.
• Assign a clear owner and deadline to each action.
• Review last sprint's action items at the start of the next retro — "did we actually do what we said we would?"

Teams that skip this last step tend to have the same complaints resurface sprint after sprint, which is usually a sign the retro has become a venting session rather than a tool for improvement.