Flocci Projects

Home › Agile answers › How do I run sprint planning for a small team?

How do I run sprint planning for a small team?

Effective small-team sprint planning takes about 30 minutes: review last sprint's velocity, groom the top of the backlog, estimate un-pointed stories, pull items until points reach velocity, write a one-sentence sprint goal, and start the sprint. Commit to less than feels comfortable — velocity will correct you soon enough.

Step by step

  1. Groom before the meeting. One person spends ten minutes ordering the backlog top-down and checking the top fifteen items have clear titles and enough description to estimate. Planning meetings die when they turn into writing meetings.
  2. Read your velocity. Open the velocity trend and take the average of your last three completed sprints. That number is the sprint's budget, and it is not negotiable by enthusiasm.
  3. Estimate what is un-pointed. Walk the top of the backlog and size anything without points using simultaneous reveal. Discuss outliers only; re-vote once and move on.
  4. Pull to the budget. Drag stories into the sprint until the point sum reaches the budget, then stop. The last item you leave out is the proof the budget is real.
  5. Write the sprint goal. One sentence a non-engineer would understand — 'customers can pay with UPI'. If you cannot write it, the sprint is a list of chores rather than a coherent outcome.
  6. Start the sprint. Set the start and end dates and begin. From this point scope is fixed: anything urgent that enters must displace an equivalent number of points.

Before the meeting (10 minutes, one person)

The facilitator orders the backlog by priority and checks the top items are estimable. Arriving with a groomed top-of-backlog turns the meeting into a selection exercise rather than a drafting session, which is the single biggest determinant of whether planning takes 30 minutes or two hours.

The two classic failures

Over-commitment: pulling 30 points on a velocity of 20 because this sprint feels different. It never is, and failed commitments demoralise a team faster than small ones. Ambiguous stories: anything the room cannot estimate in two minutes is not ready, so push it back to grooming instead of burning the meeting on it.

Doing this in Flocci Projects

Create Sprint captures the name, goal, start date and end date; the sprint planner drags issues in from the backlog with points summing live; the velocity trend from completed sprints sits alongside. Complete Sprint rolls unfinished work back to the backlog and updates the analytics, so the retrospective reads a chart instead of memories.

Try it on a free Flocci Projects board

Related questions

How long should a sprint be?

Two weeks is the default for good reason: one week amplifies estimation noise, four weeks delays feedback. Very small teams shipping continuously sometimes prefer one week — pick a length and keep it constant so velocity stays comparable.

What if urgent work lands mid-sprint?

Swap, do not stack. If the urgent item must enter, remove roughly equal points from the sprint. A scope that only grows is not a budget, and a sprint without a budget cannot teach you anything.

Does a 2-person team need sprint planning at all?

A lightweight version, yes. Fifteen minutes weekly to pick a scope and a goal beats pure reactive flow, because it creates the one moment where you explicitly say no to something.

More agile answers