Scrum: Complete Definition and Guide
Définition
Scrum is an Agile framework structured around sprints, defined roles (Product Owner, Scrum Master, development team) and regular ceremonies to deliver software increments iteratively.What is Scrum?
Scrum is the most widely adopted Agile framework in the software development world. Created by Ken Schwaber and Jeff Sutherland in the 1990s, it provides a lightweight yet structured framework for managing complex projects. The term "Scrum" is borrowed from rugby, referring to the huddle where the entire team pushes in the same direction to move forward together.
Scrum rests on three fundamental pillars: transparency (all significant aspects of the process are visible to those responsible for the outcome), inspection (artefacts and progress are regularly examined), and adaptation (if a deviation is detected, the process is adjusted as soon as possible). These pillars are made concrete through clearly defined roles, events, and artefacts.
Why Scrum Matters
Scrum provides structure that is often missing from teams attempting to be agile without a framework. It offers clear answers to "Who does what?", "When do we synchronise?", and "How do we measure progress?".
- Predictable cadence: Fixed-length sprints (typically 2 weeks) create a regular rhythm that facilitates planning and communication with stakeholders.
- Clear responsibilities: The three Scrum roles (Product Owner, Scrum Master, developers) eliminate ambiguities about responsibilities. The PO manages the "what", the team manages the "how".
- Continuous improvement: The retrospective at the end of each sprint is a systematic improvement mechanism that drives the team to constantly progress.
- Rapid value delivery: Each sprint produces a potentially shippable increment, meaning the client can start using the product well before the full project is complete.
- Risk management: By breaking work into small batches and validating regularly, drift risks are drastically reduced.
How It Works
A Scrum cycle revolves around the sprint, a fixed-length working period (1 to 4 weeks, most commonly 2). Each sprint begins with sprint planning, where the team selects product backlog items to complete and defines a sprint goal. During the sprint, the team meets daily for a daily scrum of 15 minutes maximum.
At the end of the sprint, two events follow: the sprint review, where the team presents the completed increment to stakeholders and collects feedback, and the sprint retrospective, where the team analyses its own functioning to improve. The three Scrum artefacts are the product backlog (an ordered list of everything that might be needed in the product), the sprint backlog (items selected for the current sprint), and the increment (the sum of all completed items).
At KERN-IT, we use Scrum as the foundation for most of our custom development projects. We adapt sprint length according to project complexity: 1 week for fast MVP projects, 2 weeks for standard development. Our internal product owner works in tandem with the client-side referent to ensure a consistently relevant and prioritised backlog.
Concrete Example
For the development of a document management platform for a Belgian healthcare player, we set up a 2-week Scrum cycle. The initial product backlog contained over 80 user stories. During the first sprint planning, the team selected the 5 most critical stories: authentication, document upload, automatic classification, full-text search, and dashboard.
By sprint 1, we had a functional prototype with authentication and upload. The client, testing this first version, realised that automatic classification needed to rely on DICOM metadata rather than file names. This early discovery saved us weeks of development in the wrong direction. After 6 sprints (3 months), the platform was in production with essential features, and the team continued enriching the product sprint after sprint.
Implementation
- Define the roles: Identify the Product Owner (responsible for the backlog and prioritisation), the Scrum Master (process guardian and facilitator), and the development team (3 to 9 people).
- Create the product backlog: Write user stories in the format "As a [role], I want [action] so that [benefit]" and prioritise them by business value.
- Define the "Definition of Done": Agree on criteria that determine when an item is done (tests passed, code reviewed, documentation updated, deployed to staging).
- Plan the first sprint: The team estimates stories (in story points or time) and commits to a realistic sprint goal.
- Execute the ceremonies: Daily scrum, sprint review, and sprint retrospective are non-negotiable, even if the team is small.
- Measure and adjust: Track team velocity (number of story points delivered per sprint) and use retrospectives to continuously improve the process.
Associated Technologies and Tools
- Jira: The reference tool for Scrum backlog management, with sprint boards, burndown charts, and velocity reports
- Linear: A modern alternative to Jira, lighter and faster, which we use at KERN-IT for medium-sized projects
- Git + GitHub/GitLab: Version control with feature branches aligned with sprint user stories
- Miro: For planning poker sessions, story mapping, and remote visual retrospectives
- Slack: Real-time communication and integrations with tracking tools for automatic notifications
Conclusion
Scrum is much more than a set of meetings: it is a framework that gives teams the tools to deliver value in a predictable and transparent manner. Its strength lies in its apparent simplicity and the safeguards it installs to detect and correct problems quickly. At KERN-IT, Scrum is our default framework for custom development projects because it offers the best balance between structure and flexibility. If you are new to Agile, Scrum is the ideal entry point: its roles, ceremonies, and artefacts provide a concrete, actionable framework from the very first sprint.
The key to good sprint planning is not overloading the sprint. It is better to deliver 5 completed stories than 8 half-done ones. At KERN-IT, we apply the 80% rule: we only plan 80% of the team's theoretical capacity to absorb the unexpected.