How to run sprints with a small team of five: three meetings, two numbers, no story points

The short answer: three meetings and two numbers

A sprint is a fixed period in which a team commits to a chosen set of work. For five people, the useful parts are the commitment and the fixed end date. Both force a conversation about what matters this fortnight, and both make slippage visible early.

What a team of five does not need is a process designed for coordinating several teams, a dedicated Scrum Master, or a forecasting system built on estimates. The Scrum Guide itself describes Scrum teams as typically ten or fewer people and allows up to eight hours of planning for a one-month sprint. At five people and two weeks, that budget is far more than the work needs.

So the method keeps:

• One length, fixed. Two weeks unless you have a reason. Changing length every sprint destroys every comparison you might make.
• One goal per sprint. A sentence, not a list. "Customers can pay by invoice" is a goal; "work on billing" is not.
• Three meetings. Planning, mid-point, demo. About 90 minutes of meetings in ten working days.
• Two numbers. Throughput (issues finished) and carry-over (issues that roll into the next sprint).

Why full Scrum is too much for five people

Scrum's events exist for good reasons, and the Guide's timeboxes are maximums, not targets. The problem for a small team is the fixed cost. A daily stand-up of 15 minutes costs a five-person team 75 person-minutes a day, which is about six person-hours per two-week sprint before anyone has run over. A retrospective every sprint, a refinement session and a review add more.

At five people, most of what those meetings surface is already visible. Everyone can see the board, everyone is in the same chat, and the person blocked on an API decision usually says so within the hour. The meetings that still pay are the ones that force a decision nobody would otherwise make: what we are committing to, whether we are still on track, and whether what we built is any good.

In our own work, the meetings we dropped were the ones that repeated what the board already showed: the daily round of updates and the estimation argument. The ones we kept are the ones where the team has to choose something together.

The minimum sprint for a team of five

Here is what we keep from each Scrum event, and what replaces the rest.

Total meeting time lands between about 90 minutes and two and a half hours per sprint, compared with the eight or more hours a by-the-book version costs.

How to run a two-week sprint, step by step

The steps below assume two weeks, ten working days, and a backlog that is already roughly ordered. If your backlog is a mess, spend one hour sorting the top 20 items before the first planning session; it is the best hour you will spend.

Day 1: planning (45 minutes)

1. Look at last sprint's numbers (5 minutes). How many issues finished, how many carried over. This is your capacity guide.
2. Write the goal (10 minutes). One sentence that says what will be true at the end. The person who owns the product proposes it; the team argues with it.
3. Pull work that serves the goal (20 minutes). From the top of the backlog, take issues until you reach roughly last sprint's throughput. Anything that does not serve the goal needs a reason to be there.
4. Assign an owner to every issue (5 minutes). One person each. Shared issues are unowned issues.
5. Name the risk (5 minutes). The one thing most likely to sink the goal. Write it under the goal.

The sprint planning template has this agenda, a capacity table and a place for the goal, and works whether you call it a sprint or a cycle.

Every day: async check-in instead of a stand-up

Each person writes two or three lines in a team chat thread by mid-morning: what they finished, what they are on, and anything blocking them. It takes two minutes to write and two to read. Blockers get a reply in the thread or a quick call between the two people involved, not a meeting for five.

Day 6: the mid-point check (15 minutes)

This is the meeting Scrum does not have and small teams need most. Halfway through, look at the board and ask one question: will we hit the goal? If the answer is no, decide now what to cut, not on day ten. Moving two issues out on day six is a plan. Discovering on day ten that four issues did not happen is a surprise.

Day 10: demo and close (30 minutes)

Show what shipped, in the product, not in slides. Then close the sprint: finished issues are done, and every unfinished issue either rolls into the next sprint or goes back to the backlog. Decide which on purpose. Spend the last five minutes on one question, "what should we do differently next time?", and write down at most one change.

What to measure: throughput and carry-over

Two numbers are enough for a team of five.

Throughput is the count of issues finished in the sprint. Counting issues is cruder than points, but it is hard to game and needs no estimation meeting. Over three or four sprints it settles into a range, say 18 to 24 issues for a five-person team, and that range is your capacity for the next plan. It works best when issues are roughly similar in size, so split anything that would take more than three or four days.

Carry-over is the count of issues that were in the sprint and did not finish. A little is normal. A lot, or the same issue carried three sprints running, is the signal that matters: the team is over-planning, the issue is too big, or it is blocked by something nobody has named. We look at carry-over before throughput in every planning session.

If you want a third number, track how often the sprint goal was met. A team that hits its goal four sprints out of five, while carrying over a few issues, is working well.

What to skip: story points, velocity and most charts

Story points exist to forecast how much work fits in a time box. At five people, the forecast they produce is rarely better than counting issues, and the estimation meetings cost real time. Points earn their place when you must quote delivery dates to a client from historical data, or when issue sizes vary wildly and you cannot split them. Otherwise, skip them.

Velocity charts follow from points, so they go too. Cumulative flow diagrams and similar charts are useful for teams of twenty; at five, the board itself shows where work is stuck.

A burndown of open issues is the one chart worth keeping, because it answers the mid-point question at a glance.

Linear, Jira and Atrix for small-team sprints

All three run sprints well for a small team. They differ in what they decide for you. Facts below are from each vendor's documentation and pricing pages as of October 2026.

Linear is the closest to the method above. Its cycles documentation describes automatic rollover, an optional cooldown between cycles, and capacity estimated from the previous three completed cycles. For a team of five, the Linear pricing page shows a free plan that covers small teams until they pass 250 issues.

Jira gives you the most control. When you complete a sprint, the Jira documentation offers three destinations for unfinished work: the backlog, an existing future sprint or a new one. That is the right choice if you want the carry-over decision made by a person every time, and Jira's free plan covers up to 10 users.

Atrix is the tool we build, so here are its limits first. It has cycles of one to four weeks per product, each with a goal and a burndown that counts open issues, and completing a cycle rolls unfinished work into the next one or back to the backlog. Coloured labels and milestones sit alongside. It deliberately has no story points, no velocity reports and no cooldown setting; if your process depends on any of those, use Linear or Jira. Atrix makes sense when the team also wants docs, chat, a CRM and hiring in the same workspace. The project management page lists what it does, and our comparison with Linear is honest about where Linear is better.

Common ways small-team sprints fail

• No goal, just a list. Without one sentence of intent, every issue looks equally important and nothing gets cut at the mid-point.
• Planning to hope, not to history. If you finished 20 issues last sprint, planning 35 is not ambition, it is carry-over you have scheduled in advance.
• Skipping the mid-point. The end-of-sprint surprise almost always existed on day six.
• Issues too big to finish. One issue that takes the whole sprint tells you nothing until the last day. Split it.
• Changing the length. A one-week sprint after a three-week one makes every number meaningless.

For the difference between the words sprint and cycle, and why some tools roll work forward without asking, see cycles vs sprints.

FAQ

How long should a sprint be for a small team?

Two weeks suits most small product teams: long enough to finish something worth demoing, short enough that a bad plan costs little. One week works for teams shipping daily; three or four weeks for research-heavy work. The Scrum Guide caps sprints at one month.

Do small teams need a daily stand-up?

Usually not as a meeting. A written check-in in a chat thread gives the same information in a few minutes and does not interrupt anyone's focus. Keep a live stand-up only if blockers keep going unspoken in writing.

Should a team of five use story points?

Usually not. Counting finished issues gives a capacity range that is close enough for planning, with no estimation meeting. Points help when you must forecast delivery dates for clients or when issue sizes vary too much to split.

What should happen to unfinished work at the end of a sprint?

Decide once, then apply the rule. Either everything unfinished rolls into the next sprint, as Linear does automatically, or each item is reviewed and sent to the next sprint or back to the backlog, as Jira asks you to choose. Watch for any issue that carries over twice.

Is Scrum suitable for a team of five?

The Scrum Guide's team size of ten or fewer includes five, so yes in principle. In practice, most teams of five keep Scrum's time box, goal and review, and replace the daily scrum and full retrospective with lighter versions.

Next step

Copy the sprint planning template for your next planning session, and read the sprint entry in the glossary for the Scrum terms in one place.