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/her 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 (Google Drive, 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

In order to clarify the development of the methodology, we are going to use a fictitious example. In this example, we work with an art teacher of a secondary school who wants to develop, with his/her students, an infographic series (i.e. a group of 4 or 5 related infographics per team) that presents different information and data about a museum and the heritage it exhibits and promotes.

With the aim of making the work more realistic, the teacher takes the role of a museum curator that needs an infographic series to improve the user experience of the museum by giving additional information to people who want to visit it. In this case, the Product Owner will be the teacher, taking the role of the museum curator.

First step consists on presenting the project to the class in form of epic. This is a story that shows the context of the project, the needs and the expectations. In our example, the epic could be the following:

“The Fallas Museum of Gandia (Spain) is the main museum about the Fallas Festival in Valencia. One of its main goal is to give the opportunity to experience the Festival also to those who cannot visit the city during these holidays. Through well distinct spaces, the museum shows all the different details of this event, declared Intangible Heritage of Humanity by UNESCO in 2016.

In order to spread this knowledge and attract more visitors, our museum want to disseminate some information, curiosities and tips online about the Fallas museum and festival. To better highlight the different aspects of the event and the different resources of the museum, we have decided to realize an infographic series to publish on websites and social media. The infographic series should present photos, maps, statistics and other information helping to contextualize the tradition, discover its history, create interest in the event, promote the museum and possibly plan an itinerary”.

After presenting the epic, it is time to create the Product Backlog, this is the list of features that the product must fulfill. 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 (that means creating an infographic series for each user story). The priority informs us about the importance of each user story so teams should choose the most important in the first place.

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 infographic series can be divided in six Sprints, as can be seen in the next figure.

Each sprint has a duration of two weeks. The teacher proposes each sprint and give students all the materials that they need to develop its outcome. Rubrics for the evaluation of each sprint are also shared with students so they know where to put the focus of their work. Teachers can continue with their own program in the classroom, while students can work in the project by 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 established 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 6.  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 12 points for their work in the sprint to be acceptable.