E-Scrum implies team working, so the teacher must divide the students into teams, up to five members in each team (Scrum Teams). If teacher knows students, it is easy for him to create balanced groups. These groups should contain, at least, the following characters:

•  Scrum master: a person with leadership skills. He coordinates the team and is the contact person for the Product Owner (the teacher, as explained below).

•  Secretary: a person with organizational skills who will be responsible of reporting the meetings, following up the work and keeping the team tools updated.

•  Innovator: a creative person able to introduce lateral thinking in the teamwork.

•  Technician: a person with high digital competences, who should be able to learn how to use new software quickly.

Regardless to each member´s character, all of them have to work in the implementation of the product. Unfortunately, it may not always be possible to create such a balanced team, so the teacher shall do his best.

E-Scrum teams are self-organized; this means that they can choose the tools to perform their work, such as the collaborative software to keep the work updated. Some interesting tools are available in the market, such as those included in Office365 (OneDrive, Word, Excel, Planner, Calendar…), those provided by google (GoogleDrive, Docs, Sheets, Jamboard, Calendar…) or other included in Altassian package (Jira, Trello, Bitbucket…). In any way, it is important to use collaborative tools in order to maintain transparency in the ongoing work. These tools should include at least:

• A canva or table where the project status is always updated

• A repository where all the files are available

• A calendar where events are marked

We use an example to better understand some scenarios in which podcasts can be developed to narrate territories. In this example, we work with a teacher of a secondary school who wants to develop with her students a series of podcasts presenting different information and data about the history and cultural heritage of the city of Matera.

With the aim of making the work more realistic, the teacher takes on the role of curator of an event in Matera, called "Silent City".  The teacher would like to create a series of podcasts telling about certain places in the city and historical events in order to attract more visitors.

The first step is to present the project to the class in the form of a story, to show the context, needs and expectations:

"Silent city is a time game in which two generations, yesterday's and today's, are told. It is the story of three boys who, on a school day, escape to the lowest and oldest part of their city, the most silent part, among the centuries-old rocks.

Due to an unforeseen event, the boys will meet a boy who cannot speak and whom they will call the boy of silence. This boy will lead them into an underground memory: the story of the forgotten city. A story about the process of discovery... not only of a city, but of a collective memory".

In order to spread this knowledge and attract more visitors, the teacher wants to spread some information, curiosities and tips about Silent City online. In order to better highlight the different aspects of the event and the different places narrated, a series of podcasts is to be produced and published on the event's website and social media. The series of podcasts should present characteristic places in the city, or popular stories concerning folk traditions, with the intention of creating interest in the event, promoting the festival and therefore the city of Matera, telling it as a City of Silence, choosing stories and protagonists that highlight this topic.

After presenting the epic, it is time to create the Product Backlog, this is the list of features that the product must fulfil. This task is developed by the Product Owner (the teacher) in collaboration with the Scrum Team (the students). 

The Product Backlog is composed by a sheet for each feature (called User Story) and each one contains the following fields:

• An identifier (this is a number to identify every user story)
• A description of the user story. This description must follow the template “As a < type of user >, I want < some goal > so that < some reason >”.
• The priority of the user story, this informs about how important this feature is for the Product Owner. It is a number, the higher its value the higher its priority.
•  Time estimation, how much time does it take to complete this user story
• Checklist to validate the user story

Next table shows an example of product backlog. We have included only two user stories, but it could contain more. A good practice could be that every team will develop only one user story. The priority informs us about the importance of each user story so teams should choose the most important in the first place.

Table 14. Example of product backlog for a multimedia based on podcast

Some recommendations about the Product Backlog:

• It has to be leaded by the Product Owner in order to assure that the validation checklist contains the main items that should appear in the multimedia. It is a way to focus the work of the students.
• This validation checklist is not a rubric for the evaluation. In the rubric the teacher will include all the technical aspects that he considers important to evaluate, meanwhile in the validation checklist the features of the product are included, without detailing the quality.

The implementation of the multimedia content of the podcast can be divided into four sprints, as can be seen in Figure 1. The teacher proposes each sprint and gives the students all the materials they need to develop its outcome, which are detailed in Table 15. Rubrics for the evaluation of each sprint (Tables 16 - 21) are also shared with the students so that they know where to put the focus of their work. Teachers can continue with their programme in the classroom, while students can work on the project on their own at home.

The events of each Sprint are:

1. Sprint Planning: this is the first meeting of every sprint. In this meeting, the team decides what to do during the sprint and how to organize tasks, including who is responsible of each task. It is very important to define when the team considers a task as done, and this definition is stablished following the criteria given in the validation checklist. A minute report has to be done in order to highlight the tasks to do, the responsibility of each member and the planning. This minute report has to be available for the teacher revision.
2. Daily Sprint: every day of the sprint, the team meets five minutes in order to revise the work done and plan the work to do. A minute report has to be done and it has to be available for the teacher revision.
3. Sprint Review: once the sprint has finished, the team presents to the Product Owner and others stakeholders the result of the Sprint in form of viable minimum product. They review the product in order to demonstrate that it accomplishes the validation checklist. The teacher and other stakeholders are spectators, but they can ask any question and propose modifications.
4.  Sprint Retrospective: after the sprint review, the teacher meets the team and helps them to think about how they have managed the work. This is a meeting in which the team reflects about their way of working. For this, the teacher can:
   1. revise the minute reports in order to detect misconducts or problems in the organization of the group;
   2. ask about the roles and propose changes if he considers it is necessary;
   3. ask about the tasks done for each member;
   4. ask if there are some problems in the group; try to detect if some member is not working enough;
   5. propose some changes in the organization, way of working etc.

This meeting can also be used to revise the product technically; the teacher utilizes the rubrics to assess the work and give feedback to the team. 

Next figure shows the Scrum events, detailing the roles that are involved in each one.

Next table includes the description of each sprint, its outcome, the resources to be used by students, where to find these resources and where to find the rubrics to evaluate the sprint.

Next folders include the rubrics to evaluate sprint 1 to 7.  Teachers must rate each specific criteria of a rubric on a scale from 1 to 5, according to the degree of compliance in which 5 corresponds to full compliance and 1 indicates non-compliance. To get the final assessment, the rate of each criteria is converted to points and all points are added, getting a final number of points.  Students must get more than a certain number of points for their work in the sprint to be acceptable.