What is Scrum?
Simple but difficult
Scrum is the most widespread and well known agile framework developed by Ken Schwaber and Jeff Sutherland. It is what made agile popular as a methodology especially in software development.
Disclaimer: To understand Scrum, the best and maybe most overlooked place to start is the official publicly available and irregularly updated Scrum guide: https://scrumguides.org/ Scrum is described there in its entirety on less than 10 crystal clear pages. We recommend to read it. What we provide here is more of an interpretation and paraphrase.
So why still write about it? A whole library of many books, articles, debates around Scrum proves what an earlier version of the Scrum Guide stated: “Scrum is simple to understand but difficult to master”.
Why is that?
First, Scrum has a wide range of applications far beyond software. It is described as
“a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.”
Scrum Guide (2020)
This makes it open enough to fit almost any situation where people are faced with complexity and need to be adaptive. And which part of modern (work) life does not fall under this description? To make things “worse”:
The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory. Scrum is built upon by the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.
Scrum Guide (2020)
As a framework, Scrum leaves a lot of things open by design and does by definition not function in abstraction from its concrete and real implementations. Hence, many long discussions, opinions, experiences – including frustrations – involved in its many-faceted, virtually unlimited use.
Scrum implementations need such an amount of mastery that one of its defined key roles is that of the Scrum Master whose job is to keep things together, to continuously remind everyone else of the shining north star of what Scrum is in its core and what is needed to make it work and keep it working.
Scrum enables teams to grow by managing their work and owning it with shared accountability, reflecting on their progress as well as on the way how to proceed. It offers a flexible approach to managing complex challenges by breaking the work into iteratively repeating intervals known as Sprints.
Scrum emphasizes teamwork on an equal level free from hierarchy since no role in Scrum is “higher” or “lower” than the other, fostering transparency, openness and adaptability. While traditionally associated with software development, Scrum’s adaptable principles suit various team endeavors. It provides a structured and at the same time open approach through a set of five events (sometimes called “ceremonies”), three roles and three artifacts.
Roles
There are three roles within the Scrum framework: the Product Owner, the Scrum Master, and the Developers. Collectively these roles form the Scrum Team.
In a Scrum Team there is only one Scrum Master and one Product Owner while the number of developers may vary but can still be counted on 1,5 hands.
What cannot be stressed enough since there is frequent confusion about it while it is a critical point for understanding Scrum is that the developers do not form a separate “dev team”. There is only one Scrum team and everyone is part of it.
The Scrum Master acts as a guide, coach, and facilitator for the Scrum team with responsibilities such as e.g.:
Ensures that the whole team understands and follows Scrum principles, practices, and values.
“Causes” (!) the removal of impediments or obstacles that might hinder the team’s progress.
Facilitates meetings and helps the team work effectively together
Protect the team from external distractions, allowing them to focus on their work.
Encourages continuous improvement and fosters a positive environment for collaboration
Works with the organization also outside of the Scrum Team to spread the word and spirit of Scrum
The Product Owner has the main objective to maximize the value of the product and thereby acts as a bridge between the team and stakeholders. Typically she or he:
Defines and prioritizes the items in the Product Backlog (the list of tasks and features).
Works closely with stakeholders and communicates the product vision and goals to the team
Makes decisions about which backlog items are included in the Product Backlog and prioritizes them
Provides clarity on requirements and direction to the Developers…
Developers are the bunch of people who actually get stuff done by creating one or more increments in the course of a Sprint. They typically:
Collaborate to plan and work on tasks from the Sprint Backlog during each Sprint.
Determine how best to complete the work, dividing tasks among themselves as needed.
Work together to create and deliver a potentially usable increment at the end of each Sprint.
Adapt to changes and continuously improves their processes to increase efficiency.
There is a lot more to say about the Scrum roles, their interdependencies, their interaction among each other and with the world outside the team.
One typical question about the Scrum roles is e.g. “If there are only these three roles, what about specialist functions such as test manager, UX designer, business analyst etc.?” – The ingeniously simple answer Scrum gives is: Everyone who is not either a PO or Scrum Master counts as a developer.
This enforces what was mentioned as cross-functionality: experts across specializations work together on a daily basis to accomplish the common goal.
Contrary to common belief cross-functionality may go beyond the developers. Nothing prohibits a Scrum Master from doing some coding now and then (if the developers allow it), and noone keeps the PO from delegating basically all their tasks to others. What is set in stone is that no matter what happens, each role keeps their clear accountabilities.
Artifacts
There are three defined artifacts in Scrum. They are:
The Product Backlog is an ordered list of things that are needed to add value to the product bringing it closer to the Product Goal.
The Sprint Backlog is a combination of a Sprint Goal and a selection of items from the Product Backlog along with a plan how to achieve the goal.
The Increment (known as “Product Increment” in earlier versions of the Scrum Guide) is defined as “a concrete stepping stone toward the Product Goal”. Its measure of quality is the Definition of Done.
Events
In Scrum, there are five defined events that help the team work together, plan, and get better. Here’s a breakdown of the four events apart from the Sprint which is considered the fifth (the event in which the other events happen):
| Event | Participants | Meeting Focus | Expected Results |
|---|---|---|---|
| Sprint Planning | Scrum Team (Scrum Master, Product Owner, Developers) | Plan the work for the upcoming Sprint. Discuss what to work on, how to do it, and set Sprint goals. | Defined Sprint Goal, Detailed Sprint Tasks (Sprint Backlog) |
| Daily Scrum | Developers | Share progress, discuss what’s being done, any obstacles. | Updated Task Status, Identified Issues, Plans. |
| Sprint Review | Scrum Team, Stakeholders, Customers | Review work completed during the Sprint. Demonstrate the product increment. Collect feedback and discuss potential changes. | Reviewed work (Increment), Feedback, Updated Product Backlog. |
| Sprint Retrospective | Scrum Team | Reflect on the Sprint, discuss what went well, what didn’t, and how to improve. Identify actions for the next Sprint. | Action items for improvement, Adjusted team processes. |
The Sprint, an event of events
Sprints in Scrum are short periods, usually lasting 1-4 weeks, where a team works intensely on specific goals. They’re like focused work cycles. Sprints enable iterative development, promoting adaptability, transparency, and continuous delivery of valuable work increments, following the principles of agility.
During a Sprint, the team picks tasks from their to-do list, plans how to do them, and works together to finish them. The team only works on these chosen tasks, trying to complete them by the Sprint’s end. They have daily check-ins to track progress and solve any problems that come up.
At the end of the Sprint1, a potentially releasable product increment is showed during the Sprint Review to collect feedback and ensure alignment with stakeholder expectations.
Take care, subscribe to our newsletter and stay tuned for more updates and tips from The Pragmatic Agilist:
References
- https://www.atlassian.com/agile/scrum/sprints Sprints in Scrum ↩︎