Scrum basics for small teams: roles, events and a lightweight setup
By Axyra Nova Editorial · 18 October 2026 · 5 min read · Project management
Scrum is one of the most widely used frameworks for organising team work, especially in software development. It gives a team a regular rhythm: plan a short period of work, build something usable, show it, learn from it and improve. For small teams, it can bring focus and predictability without heavy process, as long as it is applied sensibly.
This guide explains Scrum basics for small teams: what the framework includes and how to start.
The source: the Scrum Guide
Scrum is defined in the Scrum Guide, a short document written by its creators. It is worth reading in full; it is only a few pages long. This article summarises the key ideas and offers practical advice, but the Guide is the authoritative description.
The core idea
Scrum is built on empiricism: making decisions based on what is observed rather than detailed upfront plans. It relies on three pillars:
- Transparency: the work and progress are visible to everyone involved.
- Inspection: the team regularly checks progress towards goals.
- Adaptation: the team adjusts when something is not working.
Work happens in short, fixed-length cycles called sprints, typically one to four weeks. Each sprint aims to produce a useful, finished increment.
The three accountabilities
A Scrum team is small, typically ten people or fewer, and includes three accountabilities:
Product Owner
Responsible for maximising the value of the product. They manage the product backlog, decide priorities and make sure the team understands what is most important.
Scrum Master
Responsible for helping the team use Scrum effectively. They coach the team, remove obstacles and help improve how the team works. They are not a traditional manager.
Developers
The people who do the work of creating each increment. In Scrum, "developers" includes anyone building the product: programmers, designers, testers, writers.
In very small teams, people sometimes combine accountabilities, but having one clear person responsible for priorities is important.
The events
Scrum defines five events, each with a clear purpose:
- The Sprint: the container for all the other events, a fixed period in which the team works towards a sprint goal.
- Sprint Planning: at the start of each sprint, the team decides what can be delivered and how.
- Daily Scrum: a short daily meeting, around fifteen minutes, where developers inspect progress and adjust the plan for the next day.
- Sprint Review: at the end of the sprint, the team shows what was built to stakeholders and discusses what to do next.
- Sprint Retrospective: the team reflects on how it worked and agrees improvements for the next sprint.
The artefacts
Scrum uses three artefacts, each with a commitment that adds focus:
- Product Backlog, with the Product Goal: an ordered list of everything that might be needed in the product.
- Sprint Backlog, with the Sprint Goal: the items selected for the sprint, plus the plan for delivering them.
- Increment, with the Definition of Done: the usable result of the sprint, meeting the agreed quality standard.
The Definition of Done is especially important. It describes what "finished" means, such as tested, reviewed and deployed, so there is no confusion about whether something is complete.
Starting Scrum in a small team
1. Read the Scrum Guide together
Make sure everyone understands the basics and the purpose of each event.
2. Choose a sprint length
Two weeks is a common starting point. Short enough to get frequent feedback, long enough to finish meaningful work.
3. Build an initial product backlog
List the work you know about, with the most valuable items at the top. Write items from the user's perspective where it helps: "As a customer, I want to receive a booking confirmation so I know my appointment is confirmed."
4. Agree a Definition of Done
Keep it realistic: for example, "code reviewed, tested on mobile and desktop, deployed to staging, client approved".
5. Run your first sprint
Plan, work, hold short daily check-ins, then review and reflect. Expect the first few sprints to feel awkward. That is normal.
Tools
You do not need special tools. A shared board with columns for To do, In progress and Done works well. Atlassian's guide to agile project management shows how boards and backlogs can support Scrum. Our article on Kanban with Trello explains how to set up a simple board.
Common mistakes
- Treating the Daily Scrum as a status report to a manager, rather than a planning conversation among developers.
- Skipping retrospectives, which removes the main way the team improves.
- Changing sprint scope constantly, which undermines the sprint goal.
- No clear Product Owner, leaving priorities unclear.
- A vague Definition of Done, leading to "almost finished" work piling up.
- Following rituals without understanding their purpose.
Adapting Scrum sensibly
Small teams sometimes adapt Scrum, for example combining review and retrospective or shortening events. The Scrum Guide describes Scrum as a framework that is intentionally incomplete, and teams will add their own practices. However, removing core elements tends to remove the benefits too. If you drop an event, ask what purpose it served and how you will meet that purpose another way.
A worked example
A four-person team building a booking app for salons struggled with constantly shifting priorities. The founder, acting as Product Owner, gathered requests from clients and passed them directly to whichever developer was free.
The team adopted two-week sprints. The founder kept a single ordered backlog and chose a sprint goal for each sprint, such as "salon owners can manage staff availability". Daily check-ins took ten minutes. Sprint reviews included two salon owners, whose feedback shaped the next sprint. Retrospectives led to small improvements, such as writing clearer acceptance criteria.
After a few sprints, the team was delivering features clients could actually use every two weeks, and urgent requests were added to the backlog rather than interrupting work.
Scrum for non-software work
Scrum's ideas can be applied to marketing, content and other team work, though some adaptation is common. The Agile Alliance offers introductory resources on applying agile thinking beyond software.
Learning more
Free courses on our learning platform, such as the Scrum Guide course, explain Scrum in more depth. Our project kickoff checklist helps teams start new projects clearly, whatever framework they use.
Frequently asked questions
Is Scrum only for software teams?
It started in software and is most common there, but its ideas are used in many kinds of team work.
How long should a sprint be?
One month or less, according to the Scrum Guide. Many teams use two weeks.
Do we need a certified Scrum Master?
No. Certification can help some people learn, but what matters is understanding and applying the framework well.
Can one person be both Product Owner and Scrum Master?
It is possible in very small teams, but it can create conflicts of focus. Separate the accountabilities when you can.