Most small teams meet agile the same way. Someone reads a book, someone else has worked at a company that "did Scrum", and suddenly there are ceremonies on the calendar, a wall of sticky notes, and a vocabulary nobody asked for. Three sprints later the team is quietly skipping half of it and wondering whether they were ever doing it right.
Agile is not a certification or a costume. It is a set of habits for delivering work in small pieces, checking that you are building the right thing, and changing course early when you are not. A team of four can do all of it with very little machinery. This guide covers the three ideas that matter most, the backlog, the sprint and Kanban, and how to make them work when you do not have a project manager, a Scrum master and a room full of specialists.
What agile actually means
Strip away the jargon and agile comes down to four practical commitments:
- Work in small batches. Deliver something useful every week or two instead of one big reveal at the end.
- Get feedback early. Show real work to the people who will use it while there is still time to change it.
- Plan just enough. Plan the next couple of weeks in detail and the rest loosely, because the rest will change.
- Reflect and adjust. Regularly ask what is slowing the team down and fix one thing.
Nothing in that list needs software, a title or a training course. The frameworks, Scrum and Kanban above all, are simply agreed ways of putting those commitments into practice so the whole team does it the same way.
When agile is the right choice
Agile shines when the work is uncertain: a product still taking shape, a client who will not know what they want until they see something, a project where the first plan will be wrong. Short cycles let you learn cheaply.
It is less useful for work that is already fully known and repeatable, such as a fixed installation checklist. There a simple task list is enough. Many small teams do both, running some work in sprints and other work as a steady flow, and that is fine.
The backlog is where everything starts
A backlog is an ordered list of everything the team might do next. It is not a graveyard for ideas. It is a queue, and the order matters more than the completeness.
A healthy backlog has a few habits:
- One list, one order. The item at the top is the most important thing to do next. If everything is priority one, nothing is.
- Detail where it counts. The top items are clear enough to start on tomorrow. Items further down can be a single line until they move up.
- Big things broken down. A large piece of work becomes an epic, and the epic is split into tasks small enough to finish in a few days.
- Regular tidying. Once a week, spend twenty minutes reordering, deleting what is stale and clarifying what is coming up. Teams often call this refinement or grooming.
Sizing the work
Sizing helps you decide what fits in the time you have. Two approaches are popular and both suit a small team:
- Story points. A relative score, often taken from a sequence like 1, 2, 3, 5, 8, that reflects effort, complexity and uncertainty together. A 5 is roughly bigger than a 3, not five hours.
- T-shirt sizes. S, M, L and so on. Faster and less arguable than numbers, and good enough for many teams.
Resist the urge to convert points into precise hours. Their value is that they are quick, comparable and honest about uncertainty.
Sprints give the work a rhythm
A sprint is a fixed period of time in which the team commits to a chosen set of work. The Scrum Guide describes sprints as fixed length events of one month or less. For a small team, one or two weeks is usually right. Short enough to keep feedback quick, long enough to finish something real.
The steps that make a sprint work are simple:
- Plan. Choose the work from the top of the backlog that the team can realistically finish. Look at the last few sprints and be honest about how much that is.
- Set a goal. One sentence describing what the sprint is for, such as "customers can pay by card". A goal gives the team something to steer by when tasks change.
- Check in daily. A short daily conversation, fifteen minutes at most, about what is moving and what is stuck. It is not a status report to a manager.
- Protect the sprint. Avoid adding work halfway through. If something urgent arrives, decide what leaves to make room.
- Review. At the end, show what was finished to the people who care. Real feedback belongs here.
- Retrospect. Ask what went well, what did not and pick one thing to change next time. This is the step teams skip first and miss most.
How much should you plan
Small teams often overcommit. A useful rule is to take the points you completed in the last two or three sprints, average them, and plan close to that number. That average is your velocity. It is a planning aid, not a target to push upwards and it is certainly not a way to compare people.
Kanban is the flow alternative
Kanban does away with fixed sprints. Work moves across a board in columns such as To do, In progress, Review and Done, and new work is pulled in when there is capacity. Its core practices are to visualise the work, limit how much is in progress at once, and manage the flow of work through the system.
The limit on work in progress is the part people underestimate. When everyone has five things half done, nothing finishes. Capping how many items can sit in progress forces the team to finish before starting, which makes bottlenecks visible. You can apply that limit as a team agreement even if your software does not enforce it.
Kanban tends to suit work that arrives unpredictably, such as support requests, bug fixes or an operations backlog, where committing to a two week plan makes little sense.
Choosing between Scrum and Kanban
- Choose sprints when you are building something with a clear goal and want a regular cadence of planning, delivery and review.
- Choose Kanban when work arrives continuously and priorities shift daily.
- Mix them if you need to. Plenty of small teams run sprints for planned work and keep a small board for interruptions.
Who does what in a small team
Scrum names three roles: a product owner who decides what matters most, a Scrum master who helps the team follow the process, and the developers or makers who do the work. A team of four will not have all three as separate people, and it does not need to.
What matters is that someone owns the order of the backlog, someone keeps the rhythm going, and everyone doing the work agrees on what done means. One person can hold the first two jobs, ideally not the same person who is also doing the most delivery.
A two week sprint at a glance
- Day one, morning. Plan the new sprint from the top of the backlog and set the goal.
- Days one to nine. Daily check-in, work the board, update the tasks as things move.
- Mid sprint. Spend twenty minutes refining the backlog for next time.
- Day ten. Review the finished work with stakeholders, then the team retrospective.
Common mistakes
- Skipping the retrospective. Without it the team repeats the same problems.
- A backlog nobody orders. A long unordered list is not a plan.
- Tasks too big. If it cannot be finished in a few days, split it.
- Treating velocity as a target. Pushing the number up leads to inflated estimates, not faster delivery.
- Changing the sprint constantly. If the plan changes daily, use Kanban and be honest about it.
- No definition of done. Agree what finished means, including testing and review, before you start.
What this looks like in Wizard Application
Wizard Application's project management is built around exactly these pieces, so a small team can run them in one place without stitching tools together.
Each project has backlogs whose statuses you can customise, and tasks that carry a type, a priority, an assignee, story points or a T-shirt size, labels, subtasks and a due date. Related work can be grouped into epics and milestones, and tasks can depend on one another. When it is time to plan, the sprint planning page lets you drag tasks from the backlog into a sprint and see the story points add up as you go.
A sprint has a name, a goal, start and end dates and a status that moves from planning to active to completed. It tracks total and completed story points, and a burndown chart shows the actual progress against the ideal line so you can see early whether you are on course. Tasks have comments, watchers and attachments, and you can log time against them, which feeds straight into time tracking and, if you bill clients, into invoicing. For teams that write code, tasks can be linked to GitHub so pull requests show up beside the work they belong to.
None of it forces a particular method. Use sprints, use a board, or mix them, and let the backlog stay the single ordered list at the centre.
How to get started this week
- Put everything the team is thinking about into one backlog and put it in order.
- Split anything bigger than a few days into smaller tasks.
- Size the top twenty items with points or T-shirt sizes.
- Pick a sprint length, one or two weeks, and a goal.
- Plan only what you completed last time, or slightly less if this is your first sprint.
- Hold a check-in every day and a retrospective at the end.
- Change one thing next time.
That is enough agile for most small teams. Project management is included on the paid plans, and any paid plan comes with a 7 day free trial, so you can build a backlog and run your first sprint before you commit. Take a look at project management to see how it fits together.
Frequently asked questions
How long should a sprint be?
For a small team, one or two weeks. That is short enough for quick feedback and long enough to finish something real.
Should we use Scrum or Kanban?
Use sprints for planned work with a clear goal and Kanban for work that arrives continuously. Many small teams mix the two.
Do we need a Scrum master?
No. Someone needs to own the order of the backlog and someone needs to keep the rhythm going. One person can do both.
Is project management on the free plan?
It is included on the paid plans, and every paid plan has a 7 day free trial.
