A scrum team is a small, cross-functional, self-managing group that works toward one Product Goal. It consists of one Product Owner, one Scrum Master and Developers. The current official Scrum Guide says the team is typically 10 or fewer people.
For a CTO, the key idea is ownership. A strong team has enough skills and authority to turn a product priority into a usable Increment without sending every decision, test or deployment to another department.
That is where Scrum becomes more than a meeting schedule. The team owns a result, inspects working software and changes its plan when new evidence appears.
What is a scrum team in software development?
A scrum team is the core delivery unit in Scrum, responsible for the product work needed to create value during each Sprint.
The current Scrum Guide defines three accountabilities inside the team: Product Owner, Scrum Master and Developers. It also says there are no sub-teams or hierarchies within the Scrum Team.
Two other terms matter.
Cross-functional means the members collectively have the skills needed to create value. A backend engineer does not need to become a designer. The group needs the combined skills to finish meaningful work.
Self-managing means team members decide internally who does what, when and how.
The Scrum Guide gives the team broad product responsibility. That can cover stakeholder collaboration, verification, maintenance, operations, experimentation, research and development.
For software leaders, that creates a useful test.
If engineers finish code but must wait days for another department to test, deploy or approve every change, the company may follow Scrum ceremonies. The delivery system still contains costly handoffs.
A better team boundary contains enough capability to finish valuable work, not merely start it.
The three accountabilities inside the team
A Scrum Team contains one Product Owner, one Scrum Master and Developers, with each accountability covering a different part of delivery.
| Accountability | Main responsibility | Core question |
| Product Owner | Maximise product value and manage the Product Backlog | What should we prioritise? |
| Scrum Master | Improve the effectiveness of Scrum | What is stopping the team from working well? |
| Developers | Create a usable Increment | How should we build it? |
Product Owner
The Product Owner is accountable for maximising the value created by the team.
The role includes developing and communicating the Product Goal, ordering Product Backlog items and making sure the backlog is visible and understood. The Product Owner can delegate some backlog work but remains accountable for it.
The difficult part is prioritisation.
Imagine a payments company has four requests:
- customers report duplicate payment attempts
- sales wants a reporting dashboard
- a control requirement needs changes to transaction records
- engineers want to replace an unstable API integration
All four may matter.
The Product Owner must decide what comes first. If every backlog decision requires approval from several managers, the Product Owner becomes a messenger rather than an owner.
Scrum Master
The Scrum Master is accountable for establishing Scrum and improving the team’s effectiveness.
The role includes coaching self-management, helping remove impediments and making Scrum events useful. A Scrum Master does not exist to assign Jira tickets or supervise developers.
Code & Pepper’s August 2026 guide to what a Scrum Master does and how the role differs from a project manager explores that distinction in more detail.
The difference matters in practice.
QA may be blocked by an unstable test environment. An engineer may lack access to a payment-provider sandbox. A stakeholder decision may stop progress toward the Sprint Goal.
Those are delivery problems worth solving.
Running another meeting is not.
Developers
Developers are the people committed to creating a usable Increment during each Sprint.
In Scrum, “Developers” describe accountability. It does not mean every person needs the job title software developer. The skills required depend on the product.
A software product may need expertise in:
- frontend and backend engineering
- QA and test automation
- UX/UI
- DevOps and cloud
- data or machine learning
- security
A HealthTech platform may need strong data and integration skills. A payment product may need backend engineers who understand API failure states, transaction processing and observability.
The team needs the combination that lets it meet its Product Goal and Definition of Done.
How big should a Scrum Team be?
A Scrum Team is typically 10 or fewer people in total, including the Product Owner and Scrum Master.
This comes directly from the current Scrum Guide. Older articles can cause confusion because Scrum changed its terminology in 2020.
The official revision notes explain that the 2020 guide removed the idea of a separate Development Team inside the Scrum Team. There is now one team with three sets of accountabilities: Product Owner, Scrum Master and Developers.
The number alone does not make a good team.
A five-person group may lack a skill needed to finish work. A ten-person group may still depend on several external teams.
For example, a product group could contain:
| Capability | Example |
| Product Owner | 1 |
| Scrum Master | 1 |
| Software engineers | 3-5 |
| QA, design, DevOps or specialist skills | Based on product needs |
That is an example, not a Scrum requirement.
When a group becomes too large, the Scrum Guide recommends considering multiple cohesive teams focused on the same product. Those teams should share the same Product Goal, Product Backlog and Product Owner.
For a CTO, the better question is:
Can the group produce a usable Increment without spending much of the Sprint waiting for people outside the team?
A Sprint turns priorities into working evidence
A Sprint gives the team a fixed period to pursue a Sprint Goal, create an Increment and learn from the result.
The official Scrum Guide sets the maximum Sprint length at one month.
Four formal Scrum events happen within the Sprint:
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
Backlog refinement also happens in many teams, but the Scrum Guide treats refinement as an ongoing activity rather than a formal Scrum event.
Sprint Planning defines the outcome
Sprint Planning establishes why the Sprint matters, what can be done and how the selected work may be approached.
The useful output is a coherent Sprint Goal.
Compare:
Weak: Finish PAY-144, PAY-152 and PAY-158.
Better: Prevent repeated client requests from creating duplicate payments.
The second goal gives Developers room to change implementation details while keeping the business outcome stable.
Daily Scrum checks the plan
The Daily Scrum is a 15-minute event for Developers to inspect progress toward the Sprint Goal and adapt their plan.
It is not a daily report to a manager.
Suppose an external API sandbox blocks two pieces of work. Developers may change the plan. One engineer could build a controlled mock while the Scrum Master helps resolve provider access.
The meeting led to action.
Five people listing yesterday’s tasks without making a decision does not provide the same value.
Sprint Review checks the product
The Sprint Review inspects the outcome with stakeholders and considers what should happen next.
A user may misunderstand a workflow. Product data may challenge an assumption. An external API may behave differently from its documentation.
The Product Backlog can change as a result.
The benefit is simple. The company learns before spending several more months building around a bad assumption.
Sprint Retrospective checks how the team works
The Sprint Retrospective identifies changes that could improve quality and effectiveness.
Useful retrospectives produce specific actions.
“Testing takes too long” describes a problem.
“Run payment-provider contract tests in CI before release” describes a change the team can implement and measure.
Scrum should improve the delivery system. Otherwise, the retrospective becomes another recurring meeting.
The Definition of Done is an engineering control
The Definition of Done describes the quality conditions an Increment must meet before the team considers the work complete.
For a CTO, this is one of the most useful parts of Scrum.
Consider a new withdrawal API.
The endpoint works locally. Unit tests cover the happy path. The engineer moves the ticket to Done.
Is the feature finished?
For a financial product, the team’s Definition of Done might also require:
- peer review completed
- unit and integration tests passing
- retry behaviour tested
- authentication and permissions checked
- logs and metrics added
- API documentation updated
- database migration verified
- agreed security checks completed
- deployment to the required environment
The exact controls depend on the system and its obligations.
The technical lesson is simple:
Code complete and product complete are different states.
The Scrum Guide states that work cannot form part of an Increment unless it meets the Definition of Done.
That rule matters in FinTech, HealthTech and InsurTech. Access control, testing, auditability, data handling and operational visibility may be part of the feature rather than work left for release week.
Code & Pepper’s July 2026 guide to quality assurance in software development makes the related engineering point that QA starts with requirements and risk, rather than only with testing at the end.
A concrete example: duplicate payment retries
Scrum becomes valuable when technical evidence proves that the original implementation plan is unsafe.
Imagine a payment service receives a transaction request. The provider accepts it, but the network times out before the application receives the response.
The client retries.
Without safe retry handling, the system may submit the payment twice.
The Product Owner gives the defect high priority because duplicate financial operations create customer and operational risk.
During Sprint Planning, Developers identify likely work:
- add an idempotency key
- persist request state
- distinguish a timeout from a confirmed failure
- test repeated requests
- log duplicate attempts
- expose transaction state to support staff
The Sprint Goal could be:
Prevent a repeated client request from creating a second payment.
Then an engineer finds an edge case.
The provider can accept a transaction before the timeout occurs. Retrying every timed-out request is therefore unsafe.
The original implementation plan must change.
The team may need reconciliation logic that checks the provider’s transaction state before issuing another payment instruction. Developers adapt the plan while preserving the Sprint Goal.
That is an important technical distinction.
Agility means changing the plan when evidence invalidates an assumption. It does not mean changing priorities every day.
The example also shows why cross-functional capability matters. One problem can touch API design, persistence, concurrency, automated testing, logs, metrics and support workflows.
Scrum, Agile and Kanban are different concepts
Scrum is a specific framework, Agile is a broader set of values and principles, and Kanban is a method focused on managing flow.
| Approach | Main idea | Work cadence | Defined Scrum accountabilities |
| Scrum | Iterative delivery around goals | Fixed-length Sprints | Yes |
| Kanban | Manage continuous flow and work in progress | Continuous | No |
| Agile | Broader values and principles | Varies | No |
| Traditional project model | Delivery against a planned scope and milestones | Milestone-based | No |
When Scrum fits better than Kanban
Scrum often fits complex product development when a team can pursue a stable short-term goal and learn from frequent increments.
Imagine a group building digital onboarding.
The work includes identity verification, UX, backend services, external APIs, analytics and automated tests. The team can set a Sprint Goal and inspect a working result after a short cycle.
Scrum can fit that work well.
Now consider an operations team handling production incidents. A critical outage arriving at 10:30 cannot wait for the next Sprint.
A continuous-flow approach may fit that workload better.
Many engineering organisations use both.
The process should match the nature of the work. Forcing every engineering function into identical Sprints can add ceremony without improving delivery.
Where Scrum helps and where it fails
Scrum can shorten feedback loops and clarify ownership, but it cannot compensate for missing skills or weak decision-making.
Four useful benefits
Short feedback loops. A bad assumption can surface after a Sprint rather than after months of development.
Clear accountability. Product value, Scrum effectiveness and implementation have named owners.
Visible quality. The Definition of Done makes unfinished work harder to hide.
Adaptive planning. Developers can change the implementation when new evidence appears.
Five common failure modes
Ceremony without autonomy. Daily meetings achieve little when another department controls every meaningful decision.
A powerless Product Owner. Conflicting stakeholder requests destroy backlog priority.
Too many dependencies. Waiting for QA, security, infrastructure or architecture support makes Sprint forecasts weaker.
Velocity used as a target. Story points can help one team forecast its own capacity. Comparing teams by points encourages gaming and does not measure customer value.
Done means “coding finished.” Testing, security and deployment then become hidden queues.
These problems rarely need another ceremony.
They need a clearer decision right, a missing skill or a better team boundary.
What tools does a Scrum Team need?
A Scrum Team needs tools that make work, quality and delivery state visible, but Scrum does not require a specific software product.
Jira is common. It is not part of Scrum.
A software delivery team will usually need systems for:
- backlog management
- source control and code review
- automated testing
- CI/CD
- documentation
- team communication
- observability and incident response
The exact stack matters less than the information it exposes.
A CTO should be able to ask: What is the Sprint Goal? What threatens it? Which work is blocked? Which Increment has met the Definition of Done?
Infrastructure can also become a team dependency. Code & Pepper’s guide to Platform Engineering vs. DevOps explains how reusable CI/CD templates, infrastructure provisioning and observability can reduce repeated work as an engineering organisation grows.
AI coding tools do not remove these controls.
If AI increases the amount of code entering review, testing and verification need to keep pace. Faster code generation has limited value if the team cannot prove what the software does in production.
How much does a Scrum Team cost?
There is no reliable universal price for a Scrum Team because the cost comes from its people and required skills, not from Scrum itself.
A team building a basic SaaS application has a different cost base from one building payments, insurance or clinical software. Geography, seniority, employment model and specialist skills also change the budget.
For an in-house US benchmark, the latest Occupational Employment and Wage Statistics available from the US Bureau of Labor Statistics put the May 2024 median annual wage for software developers at $133,080. The median for software quality assurance analysts and testers was $102,610.
Those are employee wage benchmarks, not contractor rates or complete employer costs.
A simple illustration shows the scale. Four software developers at the US median equal about $532,320 in annual base wages before a Product Owner, Scrum Master, QA specialist, benefits, payroll taxes, recruitment, equipment or other overhead.
That is not a recommended team budget. It shows why a credible “Scrum Team costs $X per month” claim needs much more context.
UK buyers face the same issue. Salary, contractor and nearshore models have different cost structures.
A useful budgeting model is:
delivery cost = engineering + product + QA/design/specialist capacity + Scrum facilitation + employment or supplier overhead
Then examine dependencies.
A lower-cost group that spends each Sprint waiting for external QA, DevOps or architecture support can be more expensive per usable Increment.
How long does Scrum software delivery take?
A Scrum Team can produce a usable Increment every Sprint, but Sprint length is not the same as product delivery time.
A Sprint lasts one month or less.
A two-week Sprint gives the business a two-week feedback interval. It does not guarantee a complete MVP in two weeks.
Consider a financial product with:
- authentication and permissions
- onboarding and identity checks
- payment or banking APIs
- transaction state management
- reconciliation
- administration
- monitoring
- automated tests
Those capabilities may take many Sprints.
Architecture, external integrations, security work, data migration, technical debt and regulatory constraints can all affect the schedule.
The useful planning distinction is:
Sprint length measures the feedback cycle. It does not estimate the whole project.
That keeps Sprint cadence from becoming a false delivery promise.
Real Scrum delivery
Code & Pepper’s LUSID and Nimbla projects show how Scrum can work across real product, engineering and infrastructure constraints.
LUSID: Scrum across UK and Polish teams
FINBOURNE needed web development and product design skills for LUSID, its asset management platform.
According to Code & Pepper’s verified LUSID case study, Code & Pepper initially provided product design and Product Ownership, then expanded the work to include Angular development and UI/UX design.
The teams worked across the UK and Poland. Scrum provided a common delivery process while the product, team composition and requirements changed.
Code & Pepper’s Scrum team management service reports more than 60 two-week Sprints and more than 1,000 completed tasks from the LUSID engagement.
Those figures are useful because they show Scrum used over sustained product development rather than as a short workshop or isolated process change.
Nimbla: cross-functional delivery in InsurTech
The Nimbla InsurTech case study gives a more technical example.
Code & Pepper reports a six-person team containing full-stack and frontend developers plus DevOps and cloud expertise. The team worked on the application’s architecture and code, with technologies including React, Node.js, TypeScript, GraphQL and Google Cloud.
The project also used Scrum practices including daily updates, Sprint Planning and retrospectives. Jira and Slack supported the communication flow.
The architecture decisions are more interesting than the tools.
For example, reusable React components were kept in a separate repository with a defined API to reduce hard dependencies between applications. The project also used GraphQL instead of a REST API and TypeScript instead of plain JavaScript.
Those are product engineering decisions. Scrum provided the feedback and coordination structure around them.
When should you augment the team?
Team augmentation makes sense when the existing product team has clear ownership but lacks a skill or capacity required to produce Done Increments.
Look for a repeated constraint.
Backend work finishes, but QA cannot keep up. One engineer owns all deployment knowledge. A frontend specialist blocks several features. Nobody has enough experience with critical payment integration.
Adding another general-purpose developer may not solve the bottleneck.
Add the capability that limits delivery.
Code & Pepper’s software team augmentation service covers both individual specialists and larger software delivery units. The service includes role, stack and seniority matching, onboarding and ongoing team support.
For financial products, Code & Pepper’s FinTech software development services also use LUSID as an example of team augmentation combined with Scrum management.
The buyer question should therefore be precise:
Which missing capability prevents the team from turning a high-priority backlog item into a Done Increment?
The answer might be backend capacity.
It might instead be QA, DevOps, Product Ownership, architecture, cloud expertise or specialist API knowledge.
Build the team around delivery, not ceremonies
A strong Scrum Team is defined by its ability to turn a Product Goal into usable, verified software.
Give the Product Owner real authority over priorities. Make sure Developers collectively have the skills needed to finish work. Use the Scrum Master to improve the delivery system rather than manage tickets. Define “done” in technical terms.
For high-trust products, bring security, access control, data handling, testing and operational requirements into normal delivery when the system requires them.
The final test is practical.
If your team keeps missing Sprint Goals, identify the constraint before adding headcount. More developers will not fix weak Product Ownership. Another stand-up will not fix a QA bottleneck. A new board will not fix an unsafe deployment process.
When the constraint is missing engineering capacity or specialist expertise, add that capability inside the product team. Avoid creating another handoff around it.
What is a Scrum Team?
A Scrum Team is a small, cross-functional and self-managing group focused on one Product Goal. Scrum defines three accountabilities inside the team: Product Owner, Scrum Master and Developers.
How many people should be on a Scrum Team?
The official Scrum Guide says a Scrum Team is typically 10 or fewer people in total. That number includes the Product Owner and Scrum Master.
What are the three Scrum roles?
The three Scrum accountabilities are Product Owner, Scrum Master and Developers. The Product Owner focuses on value, the Scrum Master on Scrum effectiveness, and Developers on creating the Increment.
Who leads a Scrum Team?
Scrum does not define one traditional team leader. The Product Owner has authority over product value and backlog ordering. Developers manage how the work gets done. The Scrum Master is accountable for helping the team use Scrum effectively.
Does a Scrum Team need a project manager?
Scrum does not define a project manager accountability. A company can still use project or delivery management outside the Scrum framework when its operating model requires it.
Can QA and DevOps engineers be part of the team?
Yes. Scrum requires cross-functional capability rather than a fixed set of job titles. QA, DevOps, design, data, security and other specialists can contribute when their skills are needed to create a usable Increment.
How long is a Sprint?
A Sprint lasts one month or less. Teams often choose shorter cycles, such as two weeks, to create more frequent feedback.
Is Scrum the same as Agile?
No. Agile describes broader values and principles for adaptive product development. Scrum is a specific framework that teams can use to apply those ideas.
What is the difference between Scrum and Kanban?
Scrum uses fixed-length Sprints and Sprint Goals. Kanban focuses on continuous flow and limiting work in progress. Scrum often fits goal-based product development, while Kanban can fit work with frequent and unpredictable incoming requests.
How much does a Scrum Team cost?
There is no fixed price. Team cost depends on location, seniority, team size and specialist skills. For context, the US Bureau of Labor Statistics reported a May 2024 median annual wage of $133,080 for software developers and $102,610 for software QA analysts and testers. Full employer or supplier costs are higher and vary by model.