Content begins here

Course II.4 Comic

Contenido de la página principal

Pulsa para colapsar

In this section more details about the use of E-Scrum are given. This chapter is divided into three sections:

  • The team: this section describes how to form a balanced team and proposes some tools to work collaboratively.
  • The methodology: this section presents a use case in which we applied the E-Scrum methodology with the aim of implementing a comics concept multimedia.
  • The evaluation rubrics: this section shows some rubrics that can be used to evaluate each sprint of the E-Scrum methodology.

The TeamPulsa para colapsar

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

 

The methodologyPulsa para colapsar

In order to clarify the development of the methodology, we are going to use a fictitious example. In this example, we work with a teacher from a secondary school who wants to develop with her students a series of comics 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 editor of a comic strip with talk about Matera, called "The Mysteries of Hydra".  The teacher would like to create a series of comics that talk about certain places in the city and historical events in order to attract more visitors. In this case the Product Owner is the teacher, taking the role of the comic editor.

The first step is to present the project to the class in the form of epic. This is a story to show the context, needs and expectations. In our example, the epic could be the following:

"The comic should tell about some places in the city of Matera, and should be a continuation of the comic "The Mysteries of Hydra". This comic tells about a young boy Teo who is going to experience not only a trip to Matera with his family, but a real journey of discovery through time. In fact, the boy, in order to chase a drop of water, risks being trapped in the centuries of this city, but his encounter with a mysterious girl, who will be his travelling companion, will help him unravel mysteries and face daring trials. At their side is Hidrya, a water spirit, and a monster to defeat."

To raise awareness of this comic and to attract more visitors to the city of Matera, the teacher wants to create a sequel to the comic.

Each student should create a comic strip, which should present a story related to the comic "The Mysteries of Hydra", keeping in mind that it should tell about a characteristic place in the city.

 

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

The Product Backlog consists of one sheet for each feature (called User Story) and each contains the following fields:

- An identifier (this is a number to identify each user story).

- A description of the user story. This description must follow the pattern "As < user type >, I want < some goal > so < some reason >".

- The priority of the user story, this informs how important this feature is to the product owner. It is a number, the higher its value the higher its priority.

- Time estimate, how long it takes to complete this user story

- Checklist to validate the user story

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

 

Identifier

 Description

Priority

Time

 Validation checklist

 01

 As a comic editor I want a comic to present some cultural places in Matera

100

30 h

Does the comic show the main features of the  story "The Mysteries of Hydra"?

Does the narration highlight the main features of the places where the story  takes place?

Does the narration present the social context in which the story  takes place?

Table 11. 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 next figure.

                                                                                    

Each sprint has a duration of two weeks. The teacher proposes each sprint and gives the students all the materials they need to develop its outcome. Rubrics for the evaluation of each sprint 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.

 

                                                                                           

 

 

 

ResourcesPulsa para colapsar

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.

 

Sprint

Description

Outcome

Resources

Rubric

1

Identify the topic and research about it

Document, it should contain:

- a description of the topic;

- a description of the conflict;

- a description of the characters;

A T2.L1.1 - Identify the characteristics of the cultural or natural good that must be transmitted and write a story

A T2.L2.1 - Who are the characters in the story

Rubric S1

2

Storyboard

Storyboard (first draft)

A T2.L3.L1 - Create a Storyboard

Rubric S2

3

Comic drawing

Draw details and dialogues

A T3.L1.1- Draw in details your settings

Rubric S3

A T3.L2.1- How to compose all the elements

A T3.L3.1. Finalise the work 

4

Revision

Classroom revision

EA T3.L3.1-Look at student’s comics projects with the students, so

that they are the ones who

analyse the different parts and can recognize the mistakes and successes. Group revision

 

Rubric S4

 

Rubrics for assessmentPulsa para colapsar

Next folders include the rubrics to evaluate sprint 1 to 4.  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.

Actualmente no existen anuncios

Detalles

Anuncios

Adjuntos:

Añadir comentario

Editar comentario

Cancelar

Borrar comentario

Guardar

Editor, pulse ALT-0 para la ayuda

Actualmente no existen conversaciones que mostrar.

Error al añadir el resumen del foro:

Últimas conversaciones de foros

Pulsa para expandir

Pulsa para colapsar

Por favor, introduzca un nombre de usuario.

Solamente números

Finalizada

Error al añadir anuncios

Anuncios

por

Click here to exit full screen mode.