The Spotify Model
This two-part series of articles is about the so-called Spotify Model. In the first part we briefly discuss the naming and the Scrum Framework used as a basis. The second part is about the concrete structure, the roles, as well as the advantages and disadvantages of the model.
What is behind “Spotify”?
Spotify is the main product of the Swedish startup company Spotify Technologies S.A. It is a music streaming service that enables customers to play or listen to music, podcasts or audio books on various devices (like PC / Smartphone / AV receiver). The product Spotify currently (2020) has approximately 299 million users from 92 countries, of which 138 million customers have a subscription.
The basic functions of Spotify, as well as all content, are free for all users and are financed by advertising for the company. Once the customer chooses a premium subscription, all and thus also the advanced features of the product are available to him.
The Spotify Model – Definition
The name of the model comes from the company Spotify Technologies S.A. or the product Spotify. This is because the product was developed and released in an adapted form of the Scrum or SAFe Framework. In addition, the model used for this purpose was first developed and released by Spotify Technologies S.A. (hereinafter “Spotify”) for the first time. Thus, the Spotify model is an adapted form of the above mentioned agile frameworks. The special feature of the model is that it can be implemented quickly and successfully in larger organizations, provided that the basic requirements are met.
The Scrum Framework
Before the structure of the Spotify model is explained, we will first go into the most important points of the Scrum Framework, since this is the foundation for Spotify. This should help to develop a better understanding of the Spotify model. A complete explanation of the Scrum Framework can be found in the official Scrum Guide.
Roles within Scrum
A Scrum Team consists of the Product Owner, the Scrum Master and a development team of six to nine people. The Scrum Team is a multidisciplinary and self-sufficient team without a dedicated leader.
The Product Owner is responsible for the product vision and its technical requirement description. By prioritizing the user stories in the Product Backlog he gives the rest of the team the right direction of product development and discusses the progress with all relevant stakeholders. Budget management also falls within the product owner’s remit.
The Scrum Master has an advisory function within the Scrum Team. He is also called a facilitator. He plans and moderates e.g. the sprint retrospective, identifies and removes obstacles early on and protects the team from external influences that can have a negative impact on team effectiveness. Furthermore, he continuously analyzes the team’s working methods and suggests improvements that can be tested by the team. If the measures are successful, they will be continued.
The development team is a multidisciplinary group of people with the necessary knowledge and expertise for the product implementation. In the area of software development, this includes front-end developers, back-end developers, database specialists, UX designers and test experts.
Ceremonies within Scrum
Within Scrum there are different meetings that are held during a sprint. These meetings are called “ceremonies” in Scrum. The following table gives an overview of all official ceremonies, their description, goal and desired group of participants.
Name | Description | Goal | Participants |
Sprint | one to four weeks development phase including the Scrum ceremonies | – Implementation of the User Stories – Further development of the product – Execution of the Scrum ceremonies | Scrum Team |
Sprint Planning 1 | The PO presents his desired scope for the next sprint and the whole team appreciates the complexity of the user stories. | – Estimated user stories (complexity) – Sprintbacklog (suggestion) | Scrum Team |
Sprint Planning 2 | The development team creates the Sub Tasks and performs the time estimation per Sub Task. Afterwards the team gives a forecast if the desired scope is feasible in the next scope. If not, a coordination with the PO takes place. | – Sub Tasks per User Story – Time estimation of the Sub Tasks – Teamforecast for the next sprint – Sprintbacklog (estimated) | development team + Scrum Master optional |
Daily Meeting | 15-minute daily meeting to discuss the user stories currently being implemented. | – Transparency over the course of the sprint – Clarification of possible open questions regarding the development – Identification of impediments | development team + Scrum Master, PO optional |
Sprint Review | Content review regarding the scope of the current sprint. | – Transparency about the achievement of the forecasted goal – Content update for all relevant stakeholders | Scrum Team + all relevant stakeholders |
Sprint Retrospektive | Reflection meeting regarding the cooperation within the Scrum Team. | – concrete action items to improve work within the team | Scrum Team |
Artifacts within Scrum
Besides ceremonies, Scrum also speaks of artifacts. Artifacts are objects or results that arise during a sprint. Within the Scrum framework artifacts increase transparency about the work done and the work to come.
The following table shows all official Scrum artifacts including a short description and their responsible persons.
Name | Description | Accountable |
Product Backlog | Prioritized list of product requirement descriptions in the form of epics and user stories. The Product Backlog is a living artifact. This means that it is never complete once the product is on the market, as the product is constantly being expanded or bug fixes are made. | Product Owner |
Sprint Backlog | Prioritized list of product requirement descriptions in the form of epics and user stories for each sprint The Sprint Backlog is thus an excerpt from the Product Backlog. | Scrum Team |
Increment | Implemented user stories or the specifically developed product / service. | Scrum Team |
Definition of Done | Mandatory criteria for the completion of user stories. The DOD creates a uniform understanding of when the work on the respective user story is successfully completed. This minimizes misunderstandings and prevents potential blame. | Scrum Team |
Procedure of a Sprint
At the beginning of each Sprint, Sprint Planning 1 and Sprint Planning 2 are performed. After the sprint backlog has been created from the product backlog and the team has submitted a forecast on the feasibility of the sprint, the sprint is officially launched.
From now on the daily development work and the daily meetings (“dailies”) will start. The sprint is concluded with the Sprint Review and the team internal Sprint Retrospective.
Afterwards the new sprint is planned and executed.
At best, a backlog refinement (meeting for iterative refinement of the user stories with the entire team) takes place during the current sprint, so that future sprints can be roughly outlined and initial questions clarified parallel to the sprint implementation.
A more detailed description of the Scrum framework is described within the official Scrum Guide.
The second part of the series of articles will be published in about a week in the News section.