Sprint Planning

What is Sprint Planning?

Sprint planning is the meeting where the team decides exactly what will be built in the upcoming sprint. It usually happens on the first day of the sprint and answers two questions: what are we building, and how will we build it. A good sprint planning session for a two-week sprint might take one to two hours; a rushed fifteen-minute version usually means the backlog was not ready, and the sprint will suffer for it.

For a PM at a company like Flutterwave planning the next iteration of a merchant payout dashboard, sprint planning is where months of customer interviews and roadmap thinking get turned into a concrete, shippable slice of work.

Writing Tickets People Can Actually Build From

Most teams track work in a tool like Jira, Linear, or Trello. A ticket (also called a story or issue) is the unit of work an engineer picks up. A well-written ticket includes:

• Title — short and specific, e.g. "Add retry button to failed transfer screen," not "Fix transfers."
• Description / context — why this matters, linked to the problem or customer feedback that triggered it.
• Acceptance criteria — a checklist of what "done" means, written so anyone can verify it without guessing.
• Design links — Figma files or mockups, if relevant.
• Estimate — how big the team thinks the work is (see below).

Example Jira Ticket

Title: Show retry button on failed transfer screen

Context: Support tickets show 12% of failed transfers are retried manually
by users re-entering all details. A retry button would remove that friction.

Acceptance Criteria:
- [ ] "Retry" button appears on the failed transfer confirmation screen
- [ ] Tapping retry re-submits the same transfer details without re-entry
- [ ] If retry also fails, show the standard error message
- [ ] Event "transfer_retry_clicked" logged to analytics

Estimate: 3 story points

Vague tickets ("Improve transfer reliability") waste engineering time on Slack threads asking "what does this actually mean?" A ticket should be specific enough that an engineer at Moniepoint or Konga could pick it up cold and know exactly what to build.

Backlog Grooming (Refinement)

Backlog grooming, or refinement, is the ongoing process of keeping the backlog healthy before sprint planning happens, so planning itself is fast. Most teams run a short grooming session mid-sprint, separate from planning, where the PM and team:

1. Review upcoming tickets and clarify anything unclear.
2. Break large tickets ("epics") into smaller, sprint-sized pieces.
3. Re-estimate or re-prioritize based on new information.
4. Remove or archive tickets that are no longer relevant.

A backlog that has not been groomed in months becomes a graveyard of stale ideas — which is exactly what happens on teams that skip this ceremony.

Prioritizing the Backlog

With more ideas than time, PMs need a repeatable way to decide order. Common frameworks:

A PM at Access Bank rolling out a new savings feature might use RICE to compare it against ten other requests from branch managers, customer support, and compliance — because without a scoring method, the loudest stakeholder usually wins, not the most valuable idea.

Estimation: Story Points, Not Hours

Most agile teams estimate effort in story points (often Fibonacci-like: 1, 2, 3, 5, 8, 13) rather than hours, because points measure relative complexity and uncertainty, not a fixed time commitment. A common technique is Planning Poker, where each engineer privately picks a number and the team discusses any big gaps before agreeing on a final estimate. This surfaces hidden complexity — a ticket that looks trivial to a PM might hide a database migration an engineer immediately spots.