What is Scrum?
Scrum is a lightweight framework that helps people, teams, and organisations generate value through adaptive solutions for complex problems. Rather than prescribing detailed processes, Scrum provides a minimal set of rules — three roles, five events, and three artefacts — within which teams self-manage to deliver working product increments every two to four weeks.
At its core, Scrum is built on empiricism — the idea that knowledge comes from experience and decisions should be based on what is observed. The three pillars of empiricism in Scrum are transparency (making the process visible to all), inspection (regularly checking progress and artefacts), and adaptation (adjusting course when something is not working). These pillars are supported by five values: commitment, focus, openness, respect, and courage.
Unlike traditional project management approaches that attempt to plan everything up front, Scrum acknowledges that requirements change and that the best way to manage complexity is through short feedback loops. Teams deliver small, usable increments of the product and use feedback from stakeholders to steer what they build next.
The 3 Scrum Roles
A Scrum Team is a small, cross-functional, self-managing unit. The Scrum Guide 2020 defines exactly three accountabilities within the team. There are no sub-teams, no hierarchies — just three distinct responsibilities that together cover everything needed to deliver a valuable product increment each Sprint.
Scrum Team Accountabilities
| Role | Primary Responsibility | Key Activities |
|---|---|---|
| Product Owner | Maximises the value of the product resulting from the work of the Scrum Team | Manages the Product Backlog, defines and communicates the Product Goal, orders backlog items, ensures the backlog is transparent and understood |
| Scrum Master | Serves the team as a servant-leader, ensures Scrum is understood and enacted | Removes impediments, coaches the team in self-management, facilitates Scrum events, helps the organisation adopt Scrum practices |
| Developers | Create any aspect of a usable Increment each Sprint | Self-manage daily work, create a plan for the Sprint (Sprint Backlog), hold each other accountable, adapt the plan each day toward the Sprint Goal |
Source: The Scrum Guide 2020 — Ken Schwaber & Jeff Sutherland
The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. While each role has distinct responsibilities, success depends on collaboration and shared ownership of the outcome. The recommended team size is 10 or fewer people — small enough to remain nimble, large enough to complete meaningful work within a Sprint.
Where is the Project Manager?
There is no project manager role in Scrum. The responsibilities traditionally held by a project manager are distributed across the three Scrum roles. The Product Owner handles scope and priorities, the Scrum Master handles process and impediment removal, and the Developers self-manage the execution of work. This deliberate design empowers the team and eliminates bottlenecks caused by single points of decision-making.
The 5 Scrum Events
Scrum prescribes five formal events, each designed to enable the inspection and adaptation that sit at the heart of the framework. Every event is an opportunity to review and adjust something — the plan, the product, or the way the team works. Skipping events weakens the empirical process and leads to reduced transparency.
The Scrum Events
| Event | Purpose | Time-Box |
|---|---|---|
| Sprint | The container event for all other events. A fixed-length iteration during which a usable, potentially releasable Increment is created. | 2–4 weeks (consistent length) |
| Sprint Planning | The team selects what can be delivered in the Sprint and creates a plan for how the work will be done. Defines the Sprint Goal. | Max 8 hours for a 4-week Sprint |
| Daily Scrum | A short daily sync for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary. | 15 minutes |
| Sprint Review | The team inspects the Increment with stakeholders and collaboratively decides what to adapt in the Product Backlog going forward. | Max 4 hours for a 4-week Sprint |
| Sprint Retrospective | The team inspects how the last Sprint went with regard to people, relationships, process, and tools, and identifies improvements. | Max 3 hours for a 4-week Sprint |
Source: The Scrum Guide 2020 — Ken Schwaber & Jeff Sutherland
All events are time-boxed, meaning they have a maximum duration that cannot be extended. This ensures efficiency and forces the team to focus on what matters most. However, events can end early once their purpose has been achieved — the time-box is a ceiling, not a target.
Why Time-Boxing Matters
Time-boxing is one of Scrum's most powerful disciplines. It prevents meetings from dragging on indefinitely, creates a rhythm and cadence that the team can rely on, and forces prioritisation. If Sprint Planning is limited to 8 hours, the team must focus on the highest-value items first. If the Daily Scrum is 15 minutes, there is no room for status updates to management — only focused conversation about reaching the Sprint Goal.
The 3 Scrum Artefacts
Scrum's artefacts represent work or value. They are designed to maximise transparency of key information so that everyone has the same understanding of the work being done. Each artefact contains a commitment that provides focus and a measurable target against which progress can be inspected.
Scrum Artefacts and Their Commitments
| Artefact | Description | Commitment |
|---|---|---|
| Product Backlog | An ordered list of everything that is known to be needed in the product. It is the single source of work for the Scrum Team. Owned and managed by the Product Owner. | Product Goal — the long-term objective for the Scrum Team, describing a future state of the product |
| Sprint Backlog | The set of Product Backlog items selected for the Sprint, plus the plan for delivering them and achieving the Sprint Goal. Owned by the Developers. | Sprint Goal — the single objective for the Sprint that provides coherence and focus |
| Increment | The sum of all Product Backlog items completed during the Sprint and all previous Sprints. Each Increment must be usable and meet the Definition of Done. | Definition of Done — the formal description of the state of the Increment when it meets the quality standards required for the product |
Source: The Scrum Guide 2020 — Ken Schwaber & Jeff Sutherland
The relationship between artefacts and commitments is critical. The Product Goal gives the team a long-term direction. The Sprint Goal provides focus for each iteration. The Definition of Done ensures that everyone agrees on what "finished" means, preventing half-done work from being called complete. Without these commitments, the artefacts lose their purpose.
The Definition of Done is Non-Negotiable
Every Scrum Team must have a clear Definition of Done (DoD). It typically includes criteria such as code reviewed, unit tests passing, documentation updated, and acceptance criteria met. If an item does not meet the DoD, it cannot be released or presented at the Sprint Review. A weak or missing DoD leads to technical debt, rework, and a product that is not truly "done" — one of the most common causes of Scrum failure.
Your First Sprint: A Step-by-Step Checklist
Moving from theory to practice can feel daunting, but the best way to learn Scrum is to start doing it. The following checklist walks you through the ten practical steps to go from zero to your first completed Sprint. Each step builds on the one before it.
10 Steps to Your First Sprint
| Step | Action | Key Details |
|---|---|---|
| 1 | Get leadership buy-in | Scrum changes how teams are managed. Ensure leadership understands the framework, supports self-management, and is prepared for a transition period where velocity may initially dip before improving. |
| 2 | Form the Scrum Team | Assemble a cross-functional group of 5–9 people who collectively have all the skills needed to deliver the product. Avoid part-time team members — full dedication is essential for flow and accountability. |
| 3 | Appoint the Product Owner and Scrum Master | The PO must have authority to make product decisions and access to stakeholders. The SM should understand Scrum deeply — consider sending them on a certified Scrum Master course before the first Sprint. |
| 4 | Create the initial Product Backlog | The PO collaborates with stakeholders to create an ordered list of features, fixes, and improvements. Each item should have a clear description and acceptance criteria. Start with 20–30 items to give the team enough to plan from. |
| 5 | Establish the Definition of Done | The whole team agrees on what "done" means. Include quality criteria such as code reviewed, tests written, documentation updated, and deployed to a staging environment. Write it down and make it visible. |
| 6 | Run Sprint Planning | Select a Sprint length (2 weeks is common for new teams). In Sprint Planning, the team selects backlog items, defines a Sprint Goal, and creates a plan for how they will deliver the selected work. |
| 7 | Execute the Sprint with Daily Scrums | Developers work on Sprint Backlog items each day. Hold a 15-minute Daily Scrum at the same time and place every day. Focus on progress toward the Sprint Goal, not individual status updates. |
| 8 | Hold the Sprint Review | At the end of the Sprint, demonstrate the completed Increment to stakeholders. Gather feedback, discuss what went well, and collaborate on what to work on next. This is not a sign-off gate — it is a conversation. |
| 9 | Run the Sprint Retrospective | The team reflects on how they worked together during the Sprint. Identify one or two concrete improvements to implement in the next Sprint. Keep it safe, honest, and action-oriented. |
| 10 | Repeat and refine | Start the next Sprint immediately. Apply lessons from the Retrospective. Refine the Product Backlog continuously. Remember that Scrum improves with practice — your tenth Sprint will look very different from your first. |
Do not try to make your first Sprint perfect. The whole point of Scrum is continuous improvement. Your first Sprint will feel uncomfortable — that is normal. What matters is that you follow the framework, inspect what happened, and adapt. Each Sprint will get better as the team builds its rhythm and understanding of Scrum.
Start with Two-Week Sprints
For teams new to Scrum, two-week Sprints are the most common starting point. They are short enough to provide fast feedback and limit the impact of planning mistakes, but long enough to deliver meaningful work. Once the team is comfortable with the framework, you can experiment with different Sprint lengths to find what works best for your context.
Common Scrum Anti-Patterns
Implementing Scrum is straightforward in theory, but many teams fall into patterns that undermine the framework's effectiveness. These anti-patterns are common, especially in organisations transitioning from traditional project management. Recognising them early allows you to course-correct before they become embedded habits.
Scrum Anti-Patterns and How to Fix Them
| Anti-Pattern | What Happens | What to Do Instead |
|---|---|---|
| Zombie Scrum | The team goes through the motions of all Scrum events but delivers little real value. Stakeholders are disengaged. There is no sense of urgency or purpose. | Reconnect with stakeholders. Ensure every Sprint delivers something a real user can see and use. Make the Sprint Goal meaningful and outcome-focused. |
| Absent Product Owner | The PO is unavailable, part-time, or delegates decisions to others. The team lacks clear priorities and wastes time building the wrong things. | The PO must be a single, empowered individual who is available to the team daily. If the PO cannot commit, escalate to leadership — this role is critical. |
| Scrum Master as Project Manager | The SM assigns tasks, tracks progress, and manages the team rather than coaching and facilitating. Developers lose self-management and become dependent. | The SM should coach, not control. Help the team learn to self-organise. Step back from task assignment and let Developers pull work themselves. |
| Skipping Retrospectives | The team treats Retrospectives as optional or cancels them when under pressure. Without reflection, the same problems repeat Sprint after Sprint. | Never skip the Retrospective. It is the primary mechanism for continuous improvement. Keep it short if needed, but always hold it. Act on at least one improvement each Sprint. |
| Extending Sprints | When work is not finished, the team extends the Sprint deadline rather than descoping. This destroys the cadence and predictability Scrum provides. | Sprints are fixed-length. Unfinished items return to the Product Backlog and are re-prioritised. Use this as data to improve estimation and planning in the next Sprint. |
| No Definition of Done | Without a clear DoD, "done" means different things to different people. Incomplete work is called complete, technical debt accumulates, and quality suffers. | Create a written DoD that the whole team agrees on. Review it every few Sprints and raise the bar as the team matures. Make it visible and non-negotiable. |
| Mini-Waterfall Within Sprints | Work flows sequentially through analysis, development, and testing phases within the Sprint, with testing crammed into the final days. Items are not truly done until the last moment. | Encourage the team to work on fewer items simultaneously and complete them end-to-end. Testers and developers should collaborate from day one of the Sprint, not hand off sequentially. |
Source: Common patterns observed in Scrum implementations — Scrum.org
The most important thing to remember is that Scrum is designed to surface problems, not hide them. If your team is struggling, that is Scrum working as intended — it is showing you where to improve. The Retrospective is your primary tool for addressing these anti-patterns, which is precisely why skipping it is so damaging.
Continuous Improvement is the Goal
No team implements Scrum perfectly on the first try. The framework is deliberately simple so that it is easy to understand, but difficult to master. Expect to encounter anti-patterns, and use the Retrospective to address them one at a time. Focus on making each Sprint slightly better than the last. Over time, these small improvements compound into significant gains in delivery, quality, and team satisfaction.
Master Agile & Scrum
Ready to take your Scrum knowledge further? Our accredited Agile & Scrum course covers the complete framework in depth — roles, events, artefacts, scaling patterns, and real-world implementation strategies. Get certified and lead your team's Agile transformation with confidence.
Explore Our Agile & Scrum Course